Take the blame for product problems

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.

13 thoughts on “Take the blame for product problems

  1. I actually disagree, slightly.

    As I argued in my latest blog entry, as a general rule, I don’t think it’s helpful to assign blame or ownership for product successes or failures to any single person.

    So while I agree a product manager shouldn’t focus on blaming individual members of the team for problems, I don’t think the product manager should unilaterally “own” the product or problems, either.

    The healthiest teams feel a shared accountability for the successes and failures of the product, and the best leaders cultivate this shared sense of ownership.

  2. Agree wholeheartedly… this is also a good strategy for depersonalizing problems in order to focus on analysis and action plans. After all, very few folks will actually take you at your word that “it’s my fault that sales are below target”.

    See an old piece of mine on Leadership, Trust and Pronouns { http://mironov.com/pronouns/ } that makes a similar point.

  3. Hi

    I agree with Roger. The issue is not really blame. If it’s not good to blame others, then one should not blame oneself either.

    I think that instead of taking the blame, a good product manager takes responsibility for addressing the situation, and leads others in a constructive manner to address the issues.

  4. Good comments. I agree that the goal is shared accountability and responsibility. What often happens (and Rich provides classic examples of this in the “defensive” and “aggressive” responses in Leadership, Trust and Pronouns) is that product managers try to deflect blame rather than accepting it.

    In retrospect maybe “Don’t blame others” would have been a better post title, though it’s certainly not as catchy nor would it probably have inspired as good of a discussion…

  5. “Don’t blame others” – Instead of pointing fingers on an individual, it’s always better to revisit the workflow process to identify the flaws.

    For example: If an engineer gives a buggy component, instead of blaming the engineer, we need to examine the process flow and find out where the real problem is.

    The problems can be:
    1) Specification document is not self explanatory / clear
    2) Code review is not done by the senior engineer
    3) Adequate initial testing is not done
    4) Time constraints / poor time management/ scheduling
    5) Communication gap between the concerned departments

    Once we narrow down to a problem, we can always come up with various feasible solutions. If a person is blamed, it will affect the morale of that person; instead this is a good solution.

  6. This article is right on. I’ve been working at a company where the Product Management team provides hardly any specifications but likes to blame members of the project team (mostly in hindsight) for not knowing the business needs and what the software should do. It is demoralizing indeed.

  7. Another stellar blog from Jeff.

    I agree wholeheartedly with not assigning blame, I would like to have seen something about how Product Managers can learn from these situations and in the future be more proactive. Maybe it’s a future blog.

    As Product Managers we can always play the victim, but I am a big proponent of turning the finger inwards before pointing it outward.

    If sales is the problem, what could I as a Product Manager to include them in the product design to ensure the product was attractive to the consumer base. What could I have done to communicate and “sell” the new product to the sales team better – to get them excited about it and understand the product features and how that aligns to consumer needs to make it easier to sell.

    I disagree with one of the comments about the Product Manager not “owning”. Jeff is spot on with his statement of having all of the responsibility and none of the authority. If we assume “ownership” then we partner more effectively with all the different people and areas that have a stake in product success, to ensure they have what they need to be successful.

    It is my experience, if you get involved early and often with your product partners, your chances of success are greatly increased.

  8. I have now, good article that.

    I particularly like these couple of lines
    “The most successful product teams possess a culture in which the team owns the product.”

    My question to you would be this. Who is responsible for getting teams fired up, to giving teams the tools they need, being the glue that binds the team and partners together and the individual the team trusts and looks to provides that day to day leadership?

    Behind every successful sports team there is a manager, a leader responsible for these tasks, and plays a different role to the team owner.

    One throat to choke is a dangerous game I agree, shared ownership is desired, but that is a flame in my experience that needs kindling, and often.

    Thank you for sharing your site though, something else to read now over a cup of tea.

  9. David, I agree that teams need enabled, leaders, and “glue”. A product manager plays a critical role in enabling the team by providing the market knowledge and marketing and strategic expertise.

    A product manager may also play a team lead or team management role. Depending on the team and the individuals that comprise it, others may play that role more effectively.

Comments are closed.