Too many product managers are demoted to backlog managers without even noticing it. I’ve ranted a lot about it because it drives me nuts.

Most of the time that happens because companies don’t know other ways of working, but we’re here to change the world. Bowing to the status quo isn’t for us; we’re the game-changers.

Let’s set expectations for this episode:

• We will explore 33 anti-patterns and provide an alternative to overcome them (20 minutes reading)

Shall we rock it?

You may ask yourselves, “Why is David the best person to talk about such anti-patterns?” Honesty is the word.

Before we jump into the anti-patterns, I have something for you. I’ve compiled a 5-day free e-mail course to give you actionable insights most product people miss. Ultimately, it will help you become a robust product manager.

Confessions from a Former Backlog Manager

When I started my product adventure, I didn’t know exactly what the job was about, so I followed others. I invested most of my time into:

• Bridging communication between business and development
• Writing user stories
• Pushing teams to accelerate delivery

I was pretty good at doing the above.

After 18 months, I got promoted. Reason: I increased the team’s velocity by 30%. Result: we created more features nobody used, yet I ensured the feature factory ran at full speed.

My ultimate realization came when booking.com contacted me. They invited me for a product manager interview. Guess what happened? I nailed that, as you can imagine, but not. I realized I sucked at product management. I didn’t know half of their questions:

• How do you measure the outcome?
• How do you uncover problems worth solving?
• How do you run product experiments?
• How do you set goals?

Painfully, I learned that I wasn’t a Product Manager. I was a Backlog Manager. No worries if you’re one, too. I will help you understand it and give you a way out of this trap.

From Product Manager to Backlog Manager

33 Anti-Patterns will set you and product management apart.

33 Anti-Patterns of Product Management by David Pereira

Let me share dreadful product management anti-patterns with you.

To simplify, I categorized them:

Strategy → Confusion over guidance

• Nobody knows what success looks like
• Prioritization takes forever
• The one shouting the loudest gets it all

Discovery → Output over outcome

• Requirement engineering becomes a discovery
• Validation solutions with the wrong audience are normal
• Falling in love with solutions doesn’t take long

Stakeholder → Pleasing over satisfying

• Obey your master
• Business tells what; teams deliver on their wishes
• Us versus them

Backlog Management → Bloated backlogs instead of lean ones

• A big list with everything that nobody understands
• The longer, the better
• Promises over learning

Planning → Project management instead of product management

• Time for capacity planning
• Divide and conquer
• Group of people instead of teams

Daily → Micromanaging instead of empowering

• Monitoring output closely
• Changing directions daily
• Command & control

Refinement → Solutions over problems

• Give me an estimate, and I will hold you accountable for that
• Perfect solution understanding without knowing the problem

Review → Status report instead of collaboration

• Presenting what was created without knowing the impact
• The most boring meeting in the whole company

Sadly, all the above are more common than we imagine.

I’ve been playing this game for a while now. No matter where I’ve been, I observe the same circus of madness. Yet, I don’t want to leave you powerless, but I want to equip you to overcome this nonsense.

Let’s explore each anti-pattern and analyze what you can do today for a better tomorrow.

Strategy

5 Strategy Anti-Patterns by David Pereira

1. No Vision

Nobody knows where to go, and the team continuously discusses what to do next. This is a classic situation with a sales-led approach. To close deals, sales make promises, and teams have no choice but to deliver, though nobody knows where they are going.

It’s unlikely that a product manager can change this alone because it requires alignment with multiple areas and teams, but you can ask some questions:

• Why does the product exist?
• What’s our differentiation from the competition?

That will help you develop characteristics that enable you to prioritize and say no to what doesn’t contribute to them.

Here are some product vision examples:

• LinkedIn → To create economic opportunity for every member of the global workforce
• Airbnb → Creating a world where anyone can belong anywhere through unique travel experiences
• Netflix → Revolutionizing entertainment by making personalized, on-demand streaming accessible globally

A compelling vision empowers you to decide what to do and what not to do.

2. We Serve Everyone

No clear target audience.

When you lack clarity on whom you serve, you start doing everything for everyone, and it doesn’t take long to get a cluttered product that serves nobody.

To avoid this trap, you need to define your primary audience and prioritize your work for them. Then, you can define your secondary audience and ensure the experience for your primary is solid, and you make no compromises.

Every product exists to service a target audience. Without knowing that, it’s unlikely you can create a product that matters.

You can create a persona to make it clear to everyone who your audience is.

3. No Focus

You will always have more to do than you possibly can, always.

When teams focus on everything, they create low-quality results and cannot benefit from collaboration. Ultimately, everyone suffers.

Prioritizing multiple goals means failing to prioritize what matters most.

Successful product teams pursue one goal at a time. Once they reach that goal, they can move to the next one.

4. Output Roadmap

Whenever I consult companies, I ask them to show me their roadmaps. That helps me understand how empowered product teams are.

The more prescriptive a roadmap is, the less empowered the team becomes.

Executives want a return on investment but struggle to renounce command and control behaviors. In such a situation, output roadmaps come to exist, and teams become executors instead of value drivers.

This is one of the most detrimental traps one can face. To overcome it, you need to help others see what you face.

Create a report of all features delivered over the last six months and make a correlation between usage and value created. It’s easy to realize that most outputs create little to no value. Then, you ask the question: “Should we continue creating something nobody cares about?”

Position yourself as a guide, but I must tell you meeting your audience where they are is necessary. You will move the needle once you’re willing to experiment with a combination of output and outcome-oriented roadmap and then prove it’s worth making the change in scale.

Start small and justify scaling up with results.

5. Everything Is a Priority

Who’s in charge of prioritization? When you leave that for business stakeholders, you’re troubled. Everyone wants everything by yesterday.

You may try a divide-and-conquer strategy by doing a bit of everything for everyone, but soon, your teams are stretched too thin.

“To succeed today, you have to set priorities, decide what you stand for.”

- Lee Iacocca

Prioritization means alignment on what matters most. It’s about accepting that some things will happen later, not now.

My recommendation is to create a Now, Next, Later Roadmap by Janna Bastow. This helps stakeholders make peace that something happens later. Yet, that’s not a plan but alignment, which should continuously occur. Based on what you learn, you can adapt your future.

Discovery

Product Discovery Anti-Patterns by David Pereira

6. Validate Features

Most of our ideas will fail. It’s hard to accept that because we don’t like being wrong. That’s a huge problem.

In most places I worked, stakeholders were firmly convinced that their feature requests would transform the game. Most of the time, features added nothing to customers and the business, yet we implemented them.

Product discovery is about uncovering opportunities, not proving yourself right.

Be careful with the word validate because it often leads to confirmation bias. Instead of validating features, try understanding:

• How customers would benefit from the feature?
• How often would they use it?
• How well do they understand how to use it?
• How much does it matter to them?
• How many customers does the feature impact?

It’s about learning, adapting, deciding, and having the guts to drop bad ideas soon enough.

7. Perfection

When teams start experimenting with discovery, they sometimes move to the extreme of striving for perfection. They struggle to commit to delivery because the evidence isn’t enough. That’s a trap.

Open-ended discovery leads to creating no value.

You need to continuously test ideas and scale gradually. When you research for the sake of it, you will have too much investment and too little return.

Finding the balance between discovery and delivery is mandatory.

8. Assumptions, huh?

Confidence is good, but excess of it is dangerous. I’m against the obsession with risk management, but I’m also not in favor of neglecting assumptions.

We always have assumptions. Some are important, others irrelevant.

Here are some examples:

• We assume customers want something (desirability)
• We expect customers to understand how to use it (usability)
• We believe we can deliver a valuable solution (feasibility)
• We’re confident the business can collect value (viability)
• We know that it’s ethical to do it (integrity)

The problem with assumptions is that we don’t know whether they’re true. The first thing is to identify critical ones and then run experiments. But be sure, once you ignore the assumption, you will swallow the bitter taste of a hard failure.

9. Lack of Collaboration

Who’s running Product Discovery?

Sometimes, that happens outside the team that gets things done. The result is always the same: lack of accountability. When one team hands over to another, nobody is accountable from end to end.

The only way I’ve ever seen working is an end-to-end responsibility. Yet, that’s not a given; you need to earn it.

Most teams I worked with received precise solutions to implement, and we had to coordinate instead of collaborate. To change that, we started naming assumptions behind features, testing them, and discussing experiment results, which empowered us to advance this game.

Stakeholder

Stakeholder Management Anti Patterns by David Pereira

10. Puppet

For a long time, business stakeholders have defined what other areas do, which include product teams. Stakeholders say what needs to be done, and teams get it done. What’s the result?

Teams build solutions stakeholders want without understanding why that matters.

Despite delivering on promises, customers are unhappy, the business cannot thrive, and teams are frustrated.

Product teams don’t exist to do what stakeholders demand but to create value for the business and customers. It’s impossible to reach such a challenging purpose, and following orders is how teams work.

Collaboration over coordination is fundamental to moving away from this trap. Get closer to your stakeholders and talk about challenges objectives, and partner to solve it together.

11. Whatever They Want

In my first job as a product manager, I was more like a waiter. I’d ask what stakeholders wanted, take notes, and suggest something on top of that. Then, I’d hand the request over to software engineers and get it done.

What I later realized is that the wants of business stakeholders are often unrelated to customers’ needs.

As a product manager, you must understand the needs beyond wants because that’s where you create value. That requires asking ten times more questions than giving answers.

12. Service Provider

Who’s your customer?

It’s easy to treat business people as customers because you’ll probably see them more often than actual customers. Yet, that’s a problem. Let me be as clear as I can be.

Business stakeholders aren’t your customers (unless you have an internal product).

Business stakeholders aren’t your enemies either.

Business stakeholders are your partners.

Establishing a service provider relationship is detrimental to creating value, but developing partnerships with business people is a way of boosting value creation.

I don’t know any product manager who can do everything alone, but I know successful product managers who reach the top by partnering with multiple business stakeholders.

Backlog Management

5 Backlog Management Anti-Patterns by David Pereira

13. Perfect Items

How much time do you spend with your product backlog? If you spend more than four hours a week, you’re probably endangered by the backlog manager traps.

Managing the backlog is important, but that’s only part of the job. Sadly, it’s common that product managers tend to spend too much time with their backlogs. The reasons vary, but none are good ones.

• Writing perfect items so developers don’t ask questions → This demotes software engineers into coders.
• Writing over communicating → The source of miscommunication. What’s written can easily be interpreted differently.
• It’s not written, it’s not done → It’s the perfect way of ignoring learning and blindly following requirements.

Great product managers write broken backlog items. It’s about creating an invitation for conversation and leading by context, not control.

14. Everything In

When you look at your product backlog, what does it tell you?

Can you tell me where you’re going, or does it reflect a 6-year-old Christmas wishlist? The first is the desired, and the second is the typical situation.

The backlog should reflect your learning based on the goal you’re pursuing — new learnings in, outdated items out.

It’s not because Jira or whatever tool you use offers unlimited space that you should accept a bloated product backlog. The leaner, the better.

With a confusing product backlog, you cannot expect clarity from teams.

15. Long Live Dinosaurs

How long do backlog items live? The longer they live, the more irrelevant they become.

When was the last time you removed outdated items from your product backlog?

Do you have the guts to delete what doesn’t matter now?

The above are tough questions because most of us don’t want to trash our work, and your tool has unlimited space to keep everything there. So why should you bother removing outdated items? Maybe they become relevant someday. Well, they usually won’t and will get you trapped with pointless discussions.

Imagine you’re driving on the highway. Unless you want to crash your car, you drive forward, looking forward, not backward.

Backlog items age like milk, not wine.

Product Backlog Items Age by David Pereira

16. Restricted

Transparency is a pillar of all successful teams I’ve worked with. Yet, it’s common to see ordinary teams working with hidden backlogs. Stakeholders don’t know what teams are working on or what their backlogs contain.

You may say, “We’re empowered. Stakeholders must trust us instead of micromanaging our work.” You’d be correct, but restricting the product backlog creates mistrust.

Funny enough, when you make the product backlog open for everyone, almost no one looks at it. When you block it, everyone complains. It seems like a simple choice to me.

17. Multiple Backlogs

How many backlogs do you have? I’ve seen scenarios like the following:

• Tech → Software engineers backlog.
• UX → Designers backlog.
• Product → Team’s backlog.
• Ideas → A bucket with everything nobody wants to address now.

If you want to work in silos and continuously get into discussions that contribute to conflicts but not progress, create multiple product backlogs.

Remember, product teams exist to create value for customers and the business. For that, collaboration is fundamental, and teams should self-manage and organize their work collaboratively instead of a coordinative one.

One product, one backlog.

Planning

5 Planning Anti-Patterns by David Pereira

18. Capacity

How many stories can we deliver? What’s the capacity for this development cycle?

Unless you want to become a project manager, ask the above questions.

Let me be honest: I dislike the name planning because it leads directly to creating a plan, which quickly becomes the goal. We all know that plans don’t work. No plan can survive contact with customers.

It doesn’t matter which framework you use. You will need to align with your team on what to do next. That’s usually called planning, and it often happens weekly or bi-weekly.

What I prefer doing is calling alignment. Teams must align on what matters achieving during the development cycle. It’s about clarity on what to reach and not what to deliver.

19. No Goal

As a backlog manager, I had a standard goal for my teams: deliver all backlog items by the end of the Sprint. Guess what usually happens? Most teams miss the goal.

Worse than missing the goal is not knowing what success looks like. This is a sign of poor product management and lack of prioritization.

Great Product Managers have the guts to say no to what matters less now, and they can define what to focus on right now. That’s the goal.

The outcome of any planning should be clarity on what to reach. I don’t know any better way to do that than defining a goal.

20. Output

Unfortunately, the reality is harsh. Most teams work to create features, and delivering more features is the ultimate success metric. This is dangerous because teams focus on delivery without measuring results.

I’m not saying that talking about outputs is wrong, but I’m saying that focusing on features without knowing why they exist is nonsense.

Planning should leave room for adapting the course of action based on learning.

It’s natural that as teams advance, they discover better ways of reaching desired outcomes, but if they are held accountable for outputs, they will ignore learning on the way.

21. Control

I attended and contributed to planning sessions where we defined who would be in charge of each task. As a result, I heard team members saying, “I’m finishing my sprint so that I will have capacity left.” Where’s self-managing in this situation? It was absent as I applied the most unsuccessful command and control practices.

In a better way, product managers bring the context and why something matters, and then teams are accountable for developing the what together.

Product managers should never define who does what but should always provide enough context so team members can make decisions during their daily work.

22. Fragmented Plan

“David, our team divides our capacity like this: 20% tech debt, 20% bug fixing, 50% features, and 10% buffer.”

When I heard that, I froze. How can you plan how long will it take to fix bugs? Or how can a team be a team when responsibilities are so fragmented?

Sadly, this situation is quite common, though pretty nonsense. It lacks empowerment and isn’t helpful for collaboration. If you want to fall victim to excessive speculation and planning, that’s the way to go. The result is time wasted for everyone involved because the plan will be wrong.

Daily Stand-Up

Daily Stand-up Anti-Patterns by David Pereira

23. Follow-Up

It’s common to work in a product team without a Scrum Master or an Agile Coach. Within this scenario, product managers tend to become quite dominant, which is wrong.

With a dominant product manager, the daily stand-up descends into a follow-up, where each team member reports to the god what they did yesterday, what they will do today, and if they need any help. It’s a mechanical exchange with low energy — the most horrible way of starting a day.

The problem is that the team doesn’t discuss their goal for the cycle or their confidence in reaching it. Everyone is on their own, and the product manager is watching them.

If the product manager’s intention isn’t to help, it’s better to skip the daily stand-up and let the team do it without her.

24. Disempowerment

Who’s the boss?

Sometimes, product managers behave as the team’s boss and try to decide who should do what. For example, a bug pops in, and the product manager uses the daily stand-up to define which software engineer will fix it.

When the product manager acts like the boss, the team has no empowerment, and the relationship with the product manager quickly deteriorates.

In a better scenario, the product manager understands the team is self-managing and acts as part of the team and not at a higher level than anyone.

25. Approval

Have you ever stumbled upon the “PM/PO Approval” workflow step? That’s one of the most disempowering things for a team — if you have this step, delete it now, thank me later :)

With the approval process, the product manager becomes the gatekeeper, and the team takes care exclusively of execution. That’s not how teams should be working in our knowledge era.

Remember, teams should be accountable for reaching goals, not delivering output.

26. Constant Change

Today, I want a chatbot, a change in the checkout, and, next week, a new recommendation engine. Sometimes, product managers don’t know how to handle the pressure from stakeholders, and then they continuously change what the team should be working on next.

Confusion dominates, and teams can barely focus because the product manager changes daily what matters most. Trust evaporates, and the relationship becomes horrible. Failure becomes inevitable.

Change is a constant fact, but it needs to have a foundation. If you change priority abruptly, something is dramatically wrong. To solve that, review your strategy because it’s probably weak or absent.

Refinement

Refinement Anti-Patterns by David Pereira

27. Solutions over problems

Many people perceive refinement sessions as the moment to discuss and estimate solutions. Sorry, but that’s wrong. I also had this perception. When you focus on solutions, you:

• Lead teams to implement solutions without understanding the problem they solve
• Miss the benefit of finding better solutions together
• Diminish software engineers to coders

I know it’s unnatural for most to use refinement sessions to explore the problem space, yet that’s a better use of the time.

The best refinement sessions I had were related to building a shared problem understanding so we could find a fitting solution together.

28. Estimate

Give me a number, and I’ll hold you accountable. That’s the motto of many backlog managers. You pressure the team to give an estimate, then complain they were wrong, stakeholders get annoyed that everything is often delayed, and nobody benefits from this situation.

Estimates will always be wrong.

The point isn’t to predict when something gets done but to understand how each team member perceives the complexity of solving problems. When you treat an estimate as a means to build shared understanding, everyone can benefit from it.

Another tip is to change the estimate to forecast.

I love this analogy by Maarten Dalmijn. The weatherman predicts the weather based on available information. As that changes, the forecast shifts, and everyone understands. Software development is the same; the more you get into something, the more precise your forecast becomes.

29. High-frequency

How often do you have refinement sessions?

Once, I coached a team, and I heard software engineers complaining they had too many meetings and couldn’t code. I strived to understand that and quickly uncovered the problem: four weekly refinement sessions.

When you overload teams with refinement, you continuously distract them from getting things done to think about the future. That’s unsustainable.

One hour of refinement per week tends to work pretty well. Alternatively, you can also use two hours every second week. These scenarios have worked well for me and many other teams.

You need to find the rhythm that works best for you, but please don’t force teams to switch contexts every day; that kills productivity.

Review

Product Review Anti-Patterns by David Pereira

30. Status Report

No matter how you work, now and then, you present to certain business people what the team delivered. This session is sometimes called product review or sprint review. The name doesn’t matter; what matters is what happens.

A bad review becomes a status report. The product manager opens Jira, or the backlog management tool, and walks business people through what happens item by item. It doesn’t take long for people to fall asleep. It becomes the most boring meeting ever.

A good product review focuses on elaborating how the team achieved the goal. It’s more collaborative, interactive, and not a status report. Stakeholders participate in discussions instead of passively consuming whatever product managers say.

31. Output

Most product reviews focus the presentation on what the team created. Product teams present the new shiny features, and stakeholders ask questions and give feedback. Then, the team moves on.

No mystery the team feels pressured to deliver more features while addressing the received feedback. Ultimately, product teams become feature teams. Sadly, the result is more features that end-users ignore, and the business cannot collect value.

Without a story behind it, a feature is like a body without a soul.

32. No Outcome

Similar to the previous anti-pattern is the lack of outcome discussions.

When the product review explores only what was created during the last development cycle, the team has little to no information regarding the outcome generated. But product reviews don’t need to be that limiting.

I like exploring the results of features released two or three cycles ago and elaborating on how they drive customer and business value. The conversation gets more exciting because stakeholders care about the value created. Then, you can align on what to do based on your learnings instead of mindlessly following a plan.

Bad product reviews ignore outcomes and have a narrow discussion.

Good product reviews combine outcomes and outputs and go beyond the current development cycle.

33. The Star

For a long time, I moderated product reviews, though software engineers and designers were part of the sessions. As I had no trouble presenting and communicating, team members insisted I should run the sessions.

Within time, I realized that stakeholders would only talk to me and would even perceive me as “the boss” because I was the only one talking — shame on me. I didn’t want to claim the credits or limit team members.

After noticing how business treated me as the star, I stepped back and got more people on stage to shine. As a product manager, I would still set the stage for product reviews and hand it to software engineers and designers to present our achievements and discoveries. I changed my role from the start to a facilitator. It didn’t take long to unburden myself and notice a higher engagement within the team.

Bad product managers put team members in the shadows.

Great product managers ensure that every team member shines.

Together, everyone creates value, and stakeholders know that.

Let’s defeat the anti-patterns and rock the product world!

Written by David Pereira