3 Product Management Anti-Patterns

In this post I’d like to talk about 3 very common product management anti-patterns that I see a lot of teams struggling with. It will do wonders for the quality of your product as well as the morale of your team if you can spot and avoid them.

Arbitrary Deadlines

Deadlines do have their value. They act as reminders. Often deadlines are related to a certain event – “If we can ship this feature in time for the holiday season our sales will skyrocket”. They are also a pragmatic tool for managing scope and making trade-offs – “What can we get in until April 5th, is there something we can leave out …?”. Unfortunately deadlines are not all unicorns and rainbows. They can cause a lot of harm – especially when they are arbitrary.

Arbitrary deadlines usually are hard to explain to the product team. Sometimes they even get converted into unnecessary real deadlines by poor management – “We’ve already announced feature X will be ready by March 12th, so we need to follow suit”.

It gets worse – when you race to meet a deadline technical debt accumulates. Usually there is not much time after the deadline is met to clean up the mess that it caused. High technical debt becomes a maintenance nightmare. If you are not careful you are going to spend most of the time fixing things. Product innovation grinds to a halt.

Try to avoid arbitrary deadlines at all costs.

If you want to learn more about how to go beyond deadlines there is a great talk on the topic by Jabe Bloom – thanks to Steve Rogalsky for the tip.

Zombie Features

Over time features that once seemed essential might become redundant or even harmful. The market changes, technology changes, expectations change. You probably know the needs of your customers way better now than when you started out. If you would start from scratch, which of the features would you leave out?

Every feature adds complexity that needs to be maintained. Whether it is related to your code base, the user experience or your positioning on the market – every feature comes at a price. If you want to build a great product – ask yourself what you could get rid of.

“Perfection is achieved not when there is nothing left to add, but when there is nothing left to take away” – Antoine de Saint-Exupery

Removing or de-emphasising features that are no longer important can be one of the best things you can do to improve your product. Be bold, remove cruft.

Lukas Mathis, the author of Designed for Use wrote a brilliant article on removing features if you are interested in learning more about this topic.

The Backlog Fire Hose

In theory the product backlog is a list of requirements that you’ve committed to do. That said, I’ve only seen very few product teams that manage to protect the backlog in that spirit. More often it gets abused as an “everything bucket” where things get pushed into “until later, when we have the time to get to it …”.

The backlog often acts as a convenient excuse “thanks for your feedback, we’ve just added it to the backlog …”. What’s convenient at one point gets really ugly once your team is drinking from the backlog fire hose, where one feature is more urgent than the other and everyone feeling miserable because of tickets that take years to be completed. Once you have a backlog fire hose, staying calm and making the right product decisions for right now becomes a huge challenge.

While fighting with a backlog fire hose items slip through that shouldn’t have, you commit to do more things in parallel than is effective. It’s a constant struggle to shield your product team from requirements that are expected to be shipped “real soon now”.

Fortunately there’s an easy way to prevent a backlog fire hose scenario. Be pragmatic. The amount of work you can get done is limited by your team’s throughput. It doesn’t make a lot of sense to commit to more work than can get done in the immediate future.

• Throw the backlog out of the window or at least rename it to what it is – a pool of ideas & suggestions.
• Set a work in progress limit – Don’t work on too many things at the same time.
• Carefully decide what to work on next – just in time.

This solves a lot of problems. You are no longer drinking from the backlog fire hose. It’s not even a backlog anymore. Instead you stir in a pool of ideas. You pick the gems that make most sense to implement right now. You decide just in time, maybe the best thing to do for the product just sprang into your mind, it never was in the backlog to begin with.

The following two tweets by Stephan Schmidt really capture the essence of how I feel about backlogs.

Also make sure to check out his blog. He has a ton of tips and lessons learned on agile software development.

Product development is a creative process, stress caused by a backlog fire hose is the last thing you need when you decide about the future of your product.