Getting over an error

Resources for product managers Tools and pro-tips
, ,
1

I caved to sales pressure and included a roadmap item that hadn’t been well reviewed and was probably a bad idea. I’m getting a lot of opposition from other departments about how it will affect implementations now that we’re ready to launch it.

How can I bounce back in this circumstance? I can choose to remove the feature, postpone it till we add more to it, or simply push it out.

More importantly, how should I respond to the fact that I added something to the roadmap that wasn’t thoroughly vetted? This seems like a major error, and I want to handle it as graciously as I can.

Thank you in advance for any suggestions!

15 Likes
2

Why didn’t the other departments or IT experts object when the feature was added to the roadmap is all I’m thinking. Why did they now change their minds? Why did they wait till launch to push back if it’s a terrible feature? Additionally, there are significant differences between sales input and a salesperson wanting to design a feature just for one of his customers. This implementation is flawed if there is a real cause for it, and that is the case. Gather evidence to show why the feature has gotten difficult at this point. Consider the feature spin off to recoup the sunk cost if you decide to delete the functionality.

15 Likes
3

A few months ago, it was being promoted as a temporary, reactionary solution to a problem. I added it to the roadmap nevertheless to appease the yelling people even though I was unable to take it on at the time. People who were initially on board no longer want it now that we are out of that emergency.

There was relatively little development effort invested because it was built so quickly. In order to enhance the experience, I also believe it would be a good idea to include a few more settings. But we are unable to accomplish that by the year’s end.

14 Likes
4

“Quick to create,” “excellent idea,” and “additional settings” bring back bitter memories for an engineering boss like me.

You might include the cost of maintenance in your calculation by, for instance:

  • more tests—possibly for every release—test maintenance, code maintenance, logging and monitoring, and more debugging options (increasing time to fix)

  • Non-technical maintenance includes updating customer service, anticipating prospective increases in support queries for you and the development team, taking other departments’ needs for data and support into account when planning the upcoming features, and so on.

It might be more harder to remove after the functionality is released. For instance, even though it only represents a small percentage of the total number of consumers, you could need to carry the added complexity with you indefinitely if only two of the larger clients begin using it.

Make certain that the feature’s entire lifespan has been considered before launch.

14 Likes
5

The fact that a problem needs to be fixed is a plus point in this situation. Instead of canning the feature, I would study the problem and solution space a little bit further. It can be described as a deviation from the initial plan brought on by a shift in priorities. The other option is to launch it and make it available as a free upgrade to a select group of customers (I’m not aware what the product is or the business model is), with the choice to utilize it or not being entirely up to the user. Additionally, you will be able to gather more information in this manner to enhance the function.

13 Likes
6

You erred, you know that. Everybody does. Honest mistakes may, in my experience, be overcome, but how you respond to them is crucial. I once committed an error that cost my employer, a very sizable international corporation, roughly $400k. While everything was being worked out, I experienced some days of nausea, but thanks to my boss’s wise counsel and assistance, I was able to get through it without losing my reputation. At that organisation, I eventually received a promotion to director.

Even though it’s terrible, if it were me, I would attack this head-on and not offer any justifications.

If it were up to me, I’d choose the best course of action and provide a compelling argument for why it should be taken—which seems like you’ve done already. In addition, I would write it up as clearly as I could in a location that is available across the organisation but difficult to stumble onto and won’t immediately send out a signal to anyone - like a Google doc, Confluence page, or whatever technology is similar in your business.

Before putting together a plan to spread the word, I would first get my manager’s approval on the best course of action. I would then reach out to the leaders of the relevant functions, then down the organisational chart of each other function, to ensure that no one is taken aback when peers reach out to them.

I wouldn’t spread the word about the strategy until you and your leadership have agreed on how to do it. When you are aligned, you could make the document more public afterward.

The document will provide you a consistent message to refer back to in all encounters. I’d decide with my manager who needs a face-to-face/Zoom call, who needs a slack message, who can get by with an email, etc.

I would provide a sincere apologies at each stage and throughout the document. That will consist of three components, in brief:

I apologise.

Absolutely my responsibility

Will not occur again

More on apology in this post on reddit.com

Always acting morally is the right thing to do. If you attempt to ignore it in any way, it will almost certainly backfire and make you appear worse in the eyes of your coworkers. You might actually increase your overall credibility if you take it on head-on, own it, and lead the charge back to the appropriate course for the product and business (for reasons explained in the thread I liked to above).

Of course, it’s up to you; you are the expert on the issue. However, I’ve had nothing but success using this strategy.

Good luck, my friend!

12 Likes
7

@AnushkaGarg, this encouragement and support is, just what I needed. I greatly appreciate it. Really grateful. I apologize for taking your time. and I sincerely hope it wasn’t a hassle.

12 Likes
8

@SamanthaYuan, It’s not at all a hassle. I’m glad I could provide some comfort. Please don’t hesitate to ask if you have any more questions.

12 Likes
9

Failing, fixing it, and moving on. You dwelt too long on the section where you “beat myself.” It is unhealthy. It doesn’t benefit your business. Then, move on. It’s not a serious error. As a PM, you do well. Stay positive. They require you for further features.

11 Likes
10

As others have said, think through it. My gut says park it but find more prospects for it and validate in the background. After you think thorough it, and still decide to park it, admit you got excited and drove it and you were wrong about it.

10 Likes
11

If you didn’t release it, what would happen?

9 Likes
12

I suppose my main concern is losing my credibility as a leader in the company. When I give it some thought, I realize that pulling it is the smart thing to do. But even if it’s the right decision, I know my vice president will be upset that I made a commitment and then changed my mind.

9 Likes
13

My department has a motto of “we reserve the right to be smarter today than we were in the past” which means our roadmaps are going to change. As you’ve stated, the circumstances now are different compared to when you first put that feature in the roadmap so pat yourself on the back for being keeping an ear on the ground to understand the current landscape and adapting.

9 Likes
14

Every organization and person is unique, but I like to be open and honest with everyone. I’ll admit that the decision was incorrect and explain why, what I learned as a result, and what I’ll do differently in the future. Then I continue.

I’ve discovered that when I’m honest with my staff, they reciprocate in kind. Since mistakes are inevitable, it lessens the stress of the job. I think what matters more is how you deal with mistakes.

8 Likes
15

Does releasing this feature have any positive benefits to you, the product, or the business? Can you approach this as an experiment and draw some conclusions? If so, start the launch. If not, then withdraw it. Consider the extra operational expenses that would arise if you implemented this functionality as well.

If you decide to drop it, you can argue that it is no longer useful because the original pain point and objectives have changed.

You should talk about your fantastic experience in your upcoming interviews.

7 Likes
16

I love thinking about this as interview fodder.

6 Likes
17

This is an appropriate response. If there is any way this can give you more strategy, go for it. I love to sell crap, especially if it pays for my strategy. Win-win situations in sales build confidence, reducing the need for further instances of this.

Kill it if you can’t sell it for enough to cover your marketing costs.

6 Likes
18

I’m not entirely sure, in fact, am confused.

What is the issue? Is it one of the listed below?

  • You created a feature specifically for one client, but you’re concerned that it won’t be used by other clients.

  • You constructed it in such a way that other departments are worried about its execution and how to sustainably support it. (So, it needs additional feature development to be truly supported and usable?)

  • You created a feature that actually works against your overall strategy or that other departments are worried about for tactical reasons.

  • Anything else?

Simply said, why are you and other departments worried? Did sales truly push for it because there was a problem with the product that several customers needed to be fixed?

5 Likes
19

@CarolynMiles, The second bullet point. Although it is consistent with our general approach, only the largest/most complex customers will benefit from it, which will cause some friction during onboarding.

We must deliver something along these lines in the end, but I realize that it needs a little more development to be viable. Without checking to see if it was actually feasible, I caved to pressure and committed to the minimal concept.

We can get there with a few more development cycles, but due to team capacity issues and other priorities, it won’t be finished in the allotted amount of time.

5 Likes
20

@SamanthaYuan, well, how severe is the interim situation? How much harm did your original version cause to other customers?

If the impact is high, I would postpone the release until you could make it better; if the damage is small, I would release and then iterate.

Release of less-than-perfect features is OK as long as you refine and enhance them. It sounds like you’re a little concentrated on just releasing really high-level features from the way you talk about it, but it’s unclear whether the extra polish is actually worthwhile (unless you already have hard data that the initial version is damaging)

5 Likes