Are You Doing Product Management or Bullshit Management?

Something strikes me; many companies hire experienced product professionals in the hope of scaling up their products. However, what happens in practice is frightening; such product professionals become powerless because they are not the ones calling the shots. Top management believes in knowing best what to do and expecting product people to follow their orders. In reality, you start doing bullshit management instead of product management.

Without decision power, Product Managers cannot thrive. 

Be careful! What companies say and do often go in opposite directions. They may say they have flat hierarchies, but you will stumble upon extensive decision-making processes and ultimately fall into analysis paralysis. You may be empowered to make decisions, but that won’t go beyond a specific context, e.g., you may decide how best to implement a solution but not which problem to solve. 

I’m shocked by how opinions and hierarchy drive business. I wonder if leaders hire Product Managers to do product management or bullshit management. Allow me to illustrate what I call bullshit management and how you can escape from such a horrible trap.

Companies Often Misunderstand Product Management

As companies grow, it gets more political and less Agile. Sometimes instead of figuring out which end-users problems are worth solving, it matters most to please critical stakeholders. That’s the moment you may descend from a Product Manager to a Backlog Owner or Story Writer. In such scenarios, pleasing stakeholders is more advantageous to your career than improving end-users lives.

Now and then, I look at job advertisements to understand how companies perceive product management. It’s sad to see many misconceptions already in the job ads. Here are some weird requirements I found recently:

“You work with your stakeholders in the organization to gather their support and deliver on their needs.” 

I thought Product Managers had to deliver on the needs of end-users instead of internal stakeholders.

“Develop business plans and product introduction plans on a global/regional basis.” 

Seriously? Most business plans mean a waterfall mindset; you create a plan, beautiful presentations, and a spreadsheet. That will only fool you. Bet high and fail big.

Good product management is about having a vision and testing many small ideas with little funds and gradually increasing them as you get objective evidence. The goal is to reach your vision but embrace experiments to uncover hidden opportunities.

“Establish tools & processes aimed to increase development efficiency.”

This one puzzles me. I’ve never expected Product Managers to define processes to increase development efficiency. This requirement is a sign of output orientation instead of the outcome.

“You plan the activities and resources for your product group, coordinating with cross-functional teams from engineering, marketing, quality, or sales”

Product Managers do not plan activities but set goals to pursue and empower teams to make decisions. That sounds more like project management instead of product management. Great Product Managers lead by context and not by control.

“Specify epics and user stories with comprehensive acceptance criteria”

It’s a common trap to perceive Product Managers as requirement engineers. Some companies expect you to bridge communication between business and tech. That was the case for the waterfall, which we all know doesn’t work well. 

Outstanding Product Managers create an environment where great ideas can happen instead of setting requirements to implement.

“You will ensure strong collaboration and communication across the company and build consensus on the product roadmap”

Beyond being ultra-slow, aiming for consensus is the perfect way of generating mediocrity. Product Managers fight for commitment instead of consensus. It’s OK to agree to disagree. Experience and evidence should always talk louder than opinions and job titles.

When I read Product Managers’ job descriptions with requirements like these, I know we have a lot of opportunities. It may be challenging to help companies implement sound product management practices but rewarding. It’s a matter of knowing what to expect and adapting how you can help such companies evolve with product management. You may need to pick some fights, but that can be pretty motivating. 

Bullshit Management

I call bullshit management when you spend your time doing things unrelated to product management. Before I describe what I mean by that, let me share my perspective on what makes great Product Managers.

Leading teams to create value for end-users and businesses by identifying significant problems to solve and uncovering unexplored potential.

For me, an excellent Product Manager is an inspiring person. She motivates people to do what they didn’t even know they could. She also sets inspiring goals and empowers teams to decide how to reach them. She is not a boss but a leader the team follows.

If your daily activities are related to what I’ve just mentioned, I believe you’re doing product management. However, if you’re doing something unrelated, you are potentially doing bullshit management. Here are some common signs:

• Gathering requirements from stakeholders to solve their wants instead of establishing relationships with them to deliver on end-users needs.
• Keeping an extensive Product Backlog just to tell stakeholders their requests are registered instead of removing items unrelated to your current goals.
• Preparing frequent performance reports for management instead of evaluating the impact of your deliverables.
• Striving for consensus to please all stakeholders instead of seeking the best option for the product.
• Signing off all items delivered by the team to ensure it matches your quality control instead of empowering them to reach goals.
• Attending several meetings just to avoid pissing off critical stakeholders.
• Fear of saying no to pointless requests because your boss may get an e-mail.
• Bridging communication between business stakeholders and developers instead of being a catalyst and fostering collaboration.
• Prioritizing features based on opinions instead of learning from end-users.
• Focusing on delivering features over maximizing the value.
• Spending time explaining why an initiative failed instead of sharing what you learned from your failure.

Whenever you see one of these signs, you better take a stand and help the organization move from dysfunctional product management to a solid one. As a Product Manager, you should not bow to anti-patterns but fight against them.

Escaping from Bullshit Management

I named a few anti-patterns you will eventually face in your journey, but I don’t want to leave you feeling powerless. Let me give you some tips on how to fight common anti-patterns.

Moving from opinion to evidence

Stakeholders will push you to implement the features they want. Before making any decision, you can ask some questions, for example:

• Could you help me understand how this feature relates to our goal?
• Which evidence would you have this feature solves our users’ problems?
• Which problem do you want to solve with this feature?
• Let’s say we implement this feature. How do we measure its success?
• If we wouldn’t do it, what would happen?

The answers to these questions can surprise you and your stakeholders. They may refrain from progressing with their request. If they insist without evidence, it’s your role to insist on objective evidence. Opinions shouldn’t drive product teams.

Product Managers need to lead teams in creating solutions for end-users. We build products and services to make their lives better. To succeed, you need to move from pleasing stakeholders to helping end-users progress.

Avoid bridging communication

It’s a common mistake to perceive Product Managers as bridges between business and tech teams. A better way is to provide the correct context to tech teams and empower to make decisions, and encourage them to talk to business stakeholders whenever needed.

You may think it’s dangerous to let developers exchange directly with stakeholders because they may try to hijack requests into your Sprints. That can happen, but it’s way more dangerous to have a team of rule followers instead of problem-solvers. If stakeholders try hijacking something, provide feedback and encourage developers to redirect such discussions to you as they may not feel comfortable handling it.

Focus on learning instead of planning

Everyone loves security, and nothing better than having a step-by-step plan for everything ahead of you. Stakeholders will push for prescriptive plans and commitment to deadlines. Don’t fall into this trap. No plan will survive contact with end-users. Instead of creating a plan, make an assumptions list of what must happen for your idea to fly. Find fast ways of validating your assumptions. The faster you learn, the sooner you succeed.

Solid product management has little to do with plans. Don’t focus on plans; put your energy into defining where to land and your first step towards it. You don’t need anything beyond that to start. After that, adapt your actions according to your learnings. Here are some signs you’re focused on learning instead of planning:

• Your Product Backlog is lean, with no more than a couple of months of work.
• You delete items from your Product Backlog because they don’t relate to your learnings.
• You discontinue features because they prove to create no or unsatisfactory value.

Final Thoughts

The market for Product Managers is getting hotter than ever. Companies are fighting for outstanding professionals. If you want to join the club, there’s no better opportunity than now. However, be ready to face many anti-patterns and setbacks. Even though companies will hunt great professionals down, it doesn’t mean they offer you a great environment to thrive; you must fight the anti-patterns and help them overcome their dysfunctions.

Great Product Managers will never bow to anti-patterns. They will always fight back to ensure they can change the end-users lives for the better.