One of the natural laws of product management: The product backlog (opens new window) never becomes empty. Especially product managers in a new position often face the challenge of an overflowing, "historically grown" backlog.
With so many requirements, nobody knows exactly how and why they got into the backlog. It is now your job to decide which of them should be implemented initially, which ones later and which ones don't make it into your planning at all.
For years now, requirements have been prioritized by you according to familiar patterns:
- First-in-first-out
- Whoever shouts the loudest is right
- According to effort and feasibility
You know these aren't very good prioritization methods. But to prioritize suddenly in a different way, to change something would mean getting into conflicts and getting into resistance.
So don't you rather try to develop more features even faster, so that everyone is happy? Absolutely not! This is the direct path to failure for your product - and your career.
You have to expect these bad consequences if you make wrong or no prioritization of requirements and feature requests
# Prioritising the Product Backlog: 7 Pitfalls
# 1. You can't satisfy anyone
You are still unable to implement nine out of ten requirements, or cannot do so in the short term because you lack the resources to do so. A normal thing, actually. The problem: You are allowed to send a message that a feature will not be implemented. No matter what you decide: You make one happy, you disappoint nine. Because you can't explain your prioritization in a comprehensible way, you will always be held personally responsible for any rejection.
# 2. You do not meet your release dates
Without clear prioritization, without a defined goal for your release, the motto is: pack in as many features as possible. After all, the requirements are all prio 1 and needed as soon as possible. During the development time, new, super-important requirements are constantly being added: "We can still add that quickly, can't we?". The release date shifts further and further back, you can forget your planning, the calculated revenues are missing. Who do you think will be responsible for the delay?
# 3. You burn a lot of resources
If your release consists of a colorful mix of features, you are wasting a lot of resources. Rather than your developers being able to build a consistent user story, they have to work on many unrelated features. This makes development very inefficient. You have to write many small-scale briefings. And even the requirements that are not implemented cost you a lot of time. For every requirement, no matter how insignificant, you have to estimate the effort and check the feasibility.
# 4. The value proposition of your product becomes fuzzy
Without clear prioritization, your product grows into a random collection of functions. Instead of solving one big problem of one buyer/user per release, each of your releases has a little bit for everyone. In doing so, you dilute the value proposition of your product beyond recognition.
# 5. The marketing of your product becomes expensive and ineffective
Without a clear value proposition you cannot send clear messages in your communication. Your releases are not aimed at a specific target group or persona. So you have to spread your budget broadly across different channels and campaigns - hoping that someone will feel addressed. Efficient, targeted marketing looks different.
# 6. You miss your goals and the product targets
Where your product will develop in the mid- and long-term is up to chance or to those who dictate their priorities to you. However, you will be personally measured by whether you achieve your goals as a product manager and the strategic goals set by management. If you don't take the wheel and set priorities that support your goals, this is very unlikely.
# 7. You wear yourself out unsuccessfully as a product manager
In product management it's like in all other areas of life: without clear priorities you won't get anywhere. You give a lot, get involved and yet fail to achieve results. You wear yourself out for the goals of others. Taking on the wrong priorities and simply waving requirements through may save you conflicts in the short term, but in the end everyone loses.
# How to start prioritizing
In order to build the best possible solution, a product manager needs to understand WHY they are building. Once the problem and stakeholders have been identified, how does a PM tackle solving it? Jeff Betts, a Product Manager at Google, covered this problem-solving framework and share insights and anecdotes from his user-first approach to product development and prioritization strategy.
When you start a new job as a product manager or have decided to finally make a change, you are faced with a big challenge:
On the one hand, you lack the experience and data to prioritize requirements in a meaningful way. On the other hand, you lack the support within the company to introduce radical innovations overnight.
What can you do?
I recommend to start with a pragmatic method for prioritization:
# Select one target person per release
Sort all requests and feature requests in the backlog by personas to which they are directed. Agree with stakeholders for which personas the next release should be specific. Find the requirements for this particular persona in the backlog. If your company has not yet defined buyer or user personas, you can temporarily work with target groups or market segments that your sales department uses.
# Let the stakeholders vote
By prioritizing the selected features you let the circle of stakeholders vote. For example, you can include a contact person from each department and management; all have an equal vote.
Depending on the effort and feasibility, you plan the requirements in the next release in the order of prioritization.
In this way you give the next release a clear direction. At the same time, you make sure that the most important, urgent requirements are covered.
You get backing and time. Now start gathering market data and knowledge about your customers and gradually introduce a customer-centric method of prioritization.