Take the blame for product problems

December 12, 2011 by Jeff Lash

If you want to be a bad product manager, blame others for your product’s problems. 

The reason it’s not selling is because you have bad salespeople. The reason customers are complaining about bugs is because QA didn’t do a good job testing it. The reason it’s getting bad reviews is because marketing didn’t promote the product correctly. The reason it doesn’t include the key features customers want is because the engineers got behind and couldn’t fit them in to the schedule. Whatever the reason for the product not being successful, it’s not your fault, so make sure everyone else knows that.

If you want to be a good product manager, take the blame for problems with your product.

  Blaming others is never productive — it ruins relationships, decreases morale, makes others less likely to help in the future, and, most importantly, does not do anything to correct any problems which might exist.

Product managers may complain about having all of the responsibility and none of the authority and may argue that blame is an appropriate response when something goes wrong and it is outside of their control. Unfortunately, this is destructive behavior which may provide a temporary reprieve but will inevitably make the problem worse.

Blaming others is dangerous not just because it is counterproductive, but also because it delays — and likely amplifies — the fallout related to the problem. For example, maybe a product is not selling well, and you blame the salespeople, whom you claim are just not good at their job. In reality, the problem may be that the salespeople were not trained appropriately on it, or that they do not have enough support from sales engineers, or that they do not have high quality leads on which to follow up. There could be a whole myriad of reasons why the product is not selling beyond just the skills and ability of the sales team.

Blaming the salespeople in this example does not fix the problem. Replacing the salespeople does not fix the problem either — a different sales group would likely have similar (lack of) results if the underlying and related issues are not addressed. Imagine that you blame sales and succeed in getting a replacement sales team, but do not address the root causes of the slow sales. If that new sales team is not successful, you not only have alienated a large group of people within (and now outside of) your organization, but you have put your credibility and career in serious jeopardy.

Ultimately, even if your problems are the result of another person or group, it still does no good to blame them. In fact, it is usually counterproductive. You will need their help to fix the problem, and blaming them means they will feel more insecure and will be more likely to put energy into defending themselves rather than improving what is wrong.

So why do product managers blame others? There are probably a myriad of reasons, though most frequently it is to avoid looking weak. There is a mistaken belief that by deflecting problems on to others, you look infallible. The irony is that most people are smart enough to see through this, and when you attempt to deflect the blame off yourself, people lose respect for you and you end up looking weaker. Accepting responsibility is a sign of a strong leader — one for whom a single problem is not going to cause a downfall.

There are certainly times when others make mistakes and they need to be held responsible. A good product manager does not let obvious or intentional mistakes go unnoticed; a good product manager addresses them professionally and works towards a solution. More importantly, a good product manager seeks to get to the root of the problem and address it so that the problem goes away; even better, a good product manager learns from the issue and institutionalizes a solution so similar problems do not come up again.

Take the earlier examples: If customers are complaining about bugs, is that a QA problem? It could be that QA was understaffed, or that they were pressured to push the release out the door before they felt it was ready. It could be that the engineers did not do adequate initial testing before handing off to QA. It could be because the developers did not get clear and complete specifications, so they made decisions about how the product should function; absent of proper direction, this results in an classic example of “It’s not a bug, it’s a feature.” It could be (and often is) that a combination of various forces which, when combined, created the problem of a buggy product being sold to customers.

Rather than finger-pointing, product managers need to step up and accept the blame when a product is having problems. By definition, they manage the product, and with that position and title comes the responsibility to own the success of the product. Do not sweep problems under the rug or blame others — acknowledge the issues and take the lead in fixing them. The product development team and other internal stakeholders will respect you more for taking ownership and not “throwing them under the bus,” making those groups and individuals more likely to put in the extra effort to lend a hand this time and in the future. Then, when you address the issues and things start to get on track, share the credit, and you will end up being not just a successful product manager but a well-regarded product leader.