Product management anti-patterns and how to avoid them

There are good product managers and bad product managers. The best way to distinguish the two is to look out for common product management anti-patterns.

I’d say that 90 percent of issues with lousy product management practices come down to the same, overly familiar set of anti-patterns.

Avoid them at all costs.

In this article, we’ll talk about common product management anti-patterns and how to avoid them.

Lack of a product vision and strategy

A cohesive product vision is like a north star to the team. It tells if you are heading in the right direction and helps prioritize objectives and goals.

Without a clear vision and corresponding strategy, there’s no decision-making framework on what to do next. The product roadmap becomes a manifestation of stakeholders’ wishes that often doesn’t lead to any meaningful outcomes:

This anti-pattern often happens when a product manager doesn’t have the time or authority to establish and maintain a product direction.

Lack of time is a dangerous loop. PMs don’t have time to establish a vision because they are too busy doing work that doesn’t bring outcomes…because there’s no vision in place. Do whatever you can to break the cycle. In the long run, a clear vision saves you time.

Lack of authority is an even more severe problem. If you are just a backlog manager handling requests from various stakeholders, there are two options for you.

The first option is to evangelize proper product culture in the organization. As cool as it sounds, it’s often very difficult and, in many cases, impossible. Changing organizational culture is a feat that requires all hands on deck, especially the C-suite.

However, there’s a more reasonable option — run, Forrest, run! There are better places to be.

Everything is a top priority

Great product managers always know their top priorities and keep them small. You can’t expect the team to work on 20 things at once.

If everything is a priority, nothing is:

Contrary to popular belief, setting priorities isn’t about deciding what is important. Calling something important or high-priority is just too easy. A five-year-old could do it. Being able to say out loud that something is irrelevant and shouldn’t be prioritized is what matters.

Focus on your objectives and ruthlessly deprioritize irrelevant features.

Listening to customers too much

Customer feedback is critical, but it can’t be the main input to the product roadmap. This is another extremely common anti-pattern in product management:

Accepting every customer’s wish and solving their every problem is a one-way street to a Frankenstein type of product that serves no one.

The brutal truth is that most products don’t exist to solve user problems. Products exist to drive business outcomes by solving user problems. It’s a subtle but significant difference.

Accept only the customer requests that genuinely align with your product vision and contribute to the goals you are trying to achieve. And even if something aligns with both your vision and objectives, never take the request at face value. Dig deeper and understand the “why” behind the proposal — what problem does it solve? — and only then figure out if you want to address the problems and in which way.

Treat customers’ wishes as insights, not as requirements you must ship ASAP.

Ignoring technical debt

It’s tempting to rush into building new and shiny features, but speed comes at a cost. This anti-pattern can cost your organization lots of money in the long run if you’re not careful.

Monitor the levels of technical debt and keep them within reasonable boundaries. It’s okay to accumulate more debt when building an MVP or trying to meet some external deadline, but it needs to be paid off. Do it sooner rather than later.

In the long run, the more debt you accumulate, the more it slows you down. It also opens you up to additional risks:

Give the team adequate space to maintain the codebase and infrastructure. It will bite you in the ass otherwise.

Unclear product requirements

Whether it takes the form of user stories, product requirement documents, or roadmap items, the direction must be crystal clear for everyone on the team.

Product managers that give vague directions get vague results. Even worse. In the long run, it leads to scope changes, reworks, and team conflicts.

Never assume that if something is clear to you, it’s clear to everyone else. It’s rarely true:

Make sure to capture every important detail in the requirements you provide. It doesn’t mean you have to be prescriptive. Your team is more than capable of finding solutions to problems. But if you absolutely need something to work in a specific way, write it down.

That’s not enough, though. The fact that something is written down doesn’t guarantee everyone is on the same page. Ask teammates to describe the requirement in their own words or use visualizations. Always double-check for understanding.

It’s better to spend the effort on aligning everyone than on the rework down the road.

Keeping a wishlist backlog

It’s quite common to put a new item in the backlog whenever a stakeholder comes up with an idea or request. There’s even some sound logic behind it, right? After all, the idea does seem interesting and is worth revising at a later time. You don’t want to lose valuable insight.

The problem? There’ll ALWAYS be more ideas than development team capacity:

I’ve seen teams with “idea backlogs” dated two to three years back. People who proposed these ideas no longer worked in the company! And when some ideas were implemented, it wasn’t because they made it to the top of the idea backlog — someone else just proposed the same idea at a more optimal time.

Maintaining wishlist backlogs takes time, adds to organizational complexity, and rarely brings meaningful results.

If an idea is worth implementing in the near future, plan it on the roadmap. Otherwise, just drop it. If it was a truly great idea, it will come back to you one way or another.

A backlog is supposed to help the team plan and organize the work. Don’t make it a trash bin. Keep it clean.

Lack of guts

Since there are always more ideas than capacity, a product manager must be great at saying no.

This is often the most challenging part. When someone superior to you brings a super-duper-uber important feature request, our human nature often wants to please that person. But being a people-pleaser won’t get the product far:

Only features that align with product vision and current business objectives should make the cut. Period.

Great product managers know how to decline the request so that the requester understands and respects the decision. Keeping everyone on the same page regarding product direction is a great start.

Reality check: if someone comes to you with a request that doesn’t fit the product vision, it’s often a sign that the product strategy is poorly communicated. And it’s on you. Alignment is key.

Way too many features

There’s this false belief that more means better. Product features are no exceptions:

It’s understandable. Product features are tangible. Delivering fancy features comes with more bragging rights than discovering new insights from user research or paying off some technical debt.

But in the long run, the number of features doesn’t matter. It all comes down to business outcomes.

Would you rather be a PM that delivered 20 features and grew revenue by 20 percent or one that delivered two features that boosted revenue by 50 percent? The revenue seems like a more robust argument when negotiating a raise or a promotion.

Not empowering the team

Product managers often work with incredible teams of skilled professionals. Bummer that many treat them like execution machines:

While giving the team prescribed requirement documents and expecting them to deliver them is some way of working, it’s a huge waste. Experts in your team are more than well-equipped to solve even the most complex user problems and find solutions to unsolvable issues. Give them a seat at the table and let them contribute to product direction.

Great products are born from a collaboration of empowered and skilled teams, not from overly detailed product requirement documents.

Conclusion

I hope this article on anti-patterns in product management was informative for you. We discussed a lot of important points, many of which are more common than we often remember.

Take care!

Featured image source: IconScout