How to Fail as a Product Manager

The three common instances that ensure you’ll fail as a Product?Manager

An interesting aspect is how companies misinterpret the Product Manager’s job. I’ve been a Product Manager in seven different places; each had a different set of expectations. The vast differences among companies make it harder to thrive as a Product Manager; many mutations within the role separate us from our mission of maximizing the product value.

What is a Product Manager?

Ask ten different companies, and you may get ten distinct answers. But let me try my version; my understanding of a Product Manager is straightforward, uncovering opportunities to create value. What do I mean by that? Simple. Finding the nuggets between client problems, business viability, and technical feasibility. It’s a three-step method:

• Problem: which problems stop clients from progressing? Clients don’t care about all issues they have. Therefore, we need to identify the ones that are worth solving.
• Business: once we know what to solve. How could we create business value out of it? If the problem is important for clients but would yield no business value, that can be a trap if you are not conscious.
• Technology: do you have the technology to solve the problem while creating value for the business? Would the investment pay off?

Sounds simple, right? Yet, that's often not the case what you will see in practice.

Another tricky aspect; the name Product Manager is misleading, in my option, because within this role, we don’t manage anyone; on the contrary, we lead teams to create value for end-users and businesses. Great Product Managers set meaningful goals to pursue while empowering teams to decide how to get there.

“Product manager, you are responsible for defining the right product, and your engineering counterpart is responsible for building the product right.” ―?Marty?Cagan

The Product Manager’s?Mutations

So let’s go now to the anti-patterns. What are the most common mutations I have ever seen?

1. Waiter: receives orders and sends them to the team directly. The waiter behavior results in low-business value and many feature factory anti-patterns.
2. Boss: micromanage the team and behave like the boss of the developers, UX, UI, and any other member of a Product Team.
3. Architect: defines all the solutions alone. The development team does not have a voice on how to solve problems.

1. Waiter

Picture the following. You go to a restaurant, the waiter comes and asks you, “What would you like to eat?” then you say you want the best burger they offer, and the waiter suggests you add French fries and homemade lemonade. You’re happy, the waiter served you and even made a suggestion. However, the waiter didn’t know you are on a diet and need to lose weight. Although you got what you wanted, it’s not what you needed.

Some Product Managers are no different from waiters. They collect the wants from stakeholders, add them to the Product Backlog, and then throw requests over the fence to developers. The team implements solutions meeting the wishes of the stakeholders, which may not deliver on their actual needs.

Without knowing the needs behind the wants, Product Managers become order takers.

Be careful with this anti-pattern. If you fall into this, you may?notice:

• Delivering tasks instead of maximizing the value.
• Focus doesn’t exist.
• Unhappy stakeholders because no real value is delivered.
• The team doesn’t know what they are fighting for.

2. Boss

It’s 09.17 a.m. the Daily Stand-up Starts.

Product Manager:?The search improvement task has already been lying on the To-Do lane for three days. Bj?rn, can you take care of that today? Please. I want to test it by tomorrow. Ah! Also, Harold, I need something from you; I will tell you later.

I experienced Dailies like that. Of course, that’s an anti-pattern. The crucial understanding is that the Product Manager isn’t the boss of anyone. You cannot demand people to do what you want.

How can you identify this dangerous behavior?

• The Product Manager starts doing command and control, monitoring the team’s daily progress, and pressuring them during the sprint.
• One-on-one between Product Manager and Developers.
• Stakeholders see the Product Manager as responsible for the team.
• Individual performance matters.

3. Architect

“We’ve got to review our APIs implementation urgently!”?First comes the solutions, and maybe the problem. That’s how a massive problem starts.

The Product Manager is responsible for the What, while the software engineers are responsible for the How. Once the Product Manager crosses the dangerous line of?How the software engineers won’t receive this with open arms. It’s a thin line, and when it’s crossed, collaboration suffers.

Product Managers should focus on identifying problems worthwhile solving while the team figures out the best way of solving them.?The team defines the solution for the?What?presented by the Product Manager.

How can you identify?that?

• The Product Manager comes to the backlog refinement session with clear solutions, and the team has no room to explore options.
• The developers are frustrated because they are not thinking; they are only executing.
• Nobody knows which problem the solution aims to solve.

Be careful with this behavior because it can demoralize the team and bring no results. Bear in mind; the team is bigger than the sum of its individual.

Summary

Being a Product Manager means slaying at least a monster a day. We must embrace a continuous learning mindset, and we cannot be in our comfort zone. Every day we need to get a better understanding of how we can maximize the value for the business and end-users

To rock as a Product Manager, one should:

• Have solid product management competencies.
• Focus on maximizing value while saying?no?to what doesn’t contribute to it.
• Be part of the Product Team instead of behaving like a boss.
• Inspire teams with a compelling vision and empower them.