Are You Doing Product Management or Bullshit Management?
Something in digital product management continuously strikes me.
Companies hire experienced product professionals hoping to scale up their products. However, what happens in practice is frightening.
Such product professionals are powerless because they lack decision power.
Top management believes in knowing best what to do and expects product professionals to follow their orders.
When you hit the corporate firewall, your fate is sad. You end up in a situation you’re doing anything but product management. Ultimately, you get stuck with bullshit 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.
Let me illustrate what I call bullshit management and how you can escape 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 when you may descend from a Product Manager to a Backlog Manager 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:
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 end-users needs instead of internal stakeholders.
Develop business plans and product introduction plans on a global/regional basis.
Should I comment on it?
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 involves having a vision, testing many small ideas with little funds, and gradually increasing them as you get objective evidence. The goal is to reach your vision, not to follow a pointless plan.
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.
This job description sounds more like classic 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 implementation requirements.
You will ensure strong collaboration and communication across the company and build consensus on the product roadmap
Beyond being the slowest decision-making option, aiming for consensus is the perfect way of generating mediocrity. Great 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.
I know we have many opportunities when I read Product Managers’ job descriptions with requirements like these. It may be challenging to help companies implement sound product management practices but rewarding.
Knowing what to expect and adapting how you can help such companies evolve with product management is a matter of knowing what to expect. You may need to pick some fights, but that can be motivating.
Bullshit Management
I call bullshit management when you spend 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 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 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 shouldn’t 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 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 that 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, empower them to make decisions, and encourage them to talk to business stakeholders whenever needed.
You may think letting developers exchange directly with stakeholders is dangerous because they may try to hijack requests into your Sprints. That can happen, but having a team of rule followers instead of problem-solvers is way more dangerous.
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. Don’t fall into this trap. Stakeholders will push for prescriptive plans and commitment to deadlines.
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 testing 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 toward 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
Despite our economic situation, the market for Product Managers is still hot. Companies are fighting for outstanding professionals. If you want to join the club, plenty of open positions await you. 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.