Too much to do
As a product manager, one of your fundamental challenges is prioritization. You have a lot of features, enhancements, and new products you want to deliver, and not enough resources.
And it’s not just features and capabilities, it’s your time. You need to visit customers to get market insights. You should be doing continuous product discovery in your market or the market you want to get into. You need to work with the sales and marketing teams to keep them on message. Each of these is important, and will help move the needle.
And you cannot do it all.
What’s most important?
This means prioritization. You have to prioritize what you ask from your developers (i.e., in terms of features). You have to prioritize your time. And you have to be able to defend and justify your priorities to your supervisors, to the business, and to the people who are executing the work you have specified.
The basic frameworks
There are some well-known frameworks for prioritization like MoSCoW – Must, Should, Could, Won’t. And RICE – Reach, Impact, Confidence, and Effort. And of course there’s the old standby – High, Medium, Low.
The problem with these techniques is that, let’s face it, by the time I have a feature in my backlog, I already know it’s high priority. If I’m doing my job right, I don’t spend any time on low priority activities or features or ideas.
What’s the most important most important thing I could do?
I need prioritization techniques that understand I’m choosing between high priority alternatives, any of which would move my business in a positive direction.
Over the years I’ve come up with a few approaches that I use – typically in combination – to help me navigate the situation we all find ourselves in.
These techniques will help you make better decisions.These techniques will help you make better prioritization decisions. Click To Tweet
Of course, results are not guaranteed. As many a product manager has discovered before me, you can make the best decisions in the world and your product may still fail for reasons beyond your control. But to have the best shot, here are techniques to try.
Techniques of prioritization
I’m going to write this as though the priorities were new features for your product, but the same ideas work for other things you might need to prioritize.
Trust your instinct
As a product manager, it’s likely you have specific expertise. About the product, or the space, or about decision-making per se. So your gut feelings are likely to be decent.
On the other hand, if you’re like me, you want something more concrete to backup your gut-level decisions.
Quantitative analytics are great, but don’t forget qualitative analysis. The types of analytics you can use to support your decisions varies widely. For example, maybe you have talked to several customers about a new feature. They’ve all said it would be highly valuable to them. And (referring back to “Trust your instinct”) your gut says most customers would get value from it. That might be enough “analytics” to move forward. In fact, it might be all the analytics you’ll get! This is especially true if your product is enterprise software and you have a relatively small number of customers. You might not be able to get a statistically significant sample from such a small group.
You can get a lot more sophisticated – and statistically valid – if you have more customers, or are testing smaller features, such as in a consumer product.
And of course, you can create a spreadsheet comparing the revenue outcomes for different combinations of features. Tools that graphically illustrate how well a set of requirements satisfies a set of prioritization criteria based on a market model can be very valuable to give you insight into your best investment choices. There are even tools that use “option pricing” and other advanced financial techniques to give you a numeric priority value.
Analytics are the best tool in your toolbox for defending and justifying your decisions.
(And ignoring features at the bottom of the stack.)
Part of being a good prioritizer is not getting weighed down by the features you can’t work on, no matter how desirable. One way to achieve this clarity of mind is to stack rank your list of desired features. The most important ones – determined, perhaps using your gut instincts backed up with some analytics – are at the top.
Then just ignore everything in that list after the first ten items. This is a fundamental technique from agile software development. Once you have decided what is the most important feature, concentrate on delivering that feature and ignore anything else lower in priority.
Once the most important feature is delivered (or complete and ready for delivery), you can revisit the stack-ranked list. Review the ranking, make any changes necessary, and then focus again just on the top items.
This ensures you’re always delivering the highest value you can, and your team is never working on low value features.
Doing tests with a “minimum viable product” or MVP
Sometimes you have an idea for a valuable new feature but you need validation from the market that your instinct – which we can call a hypothesis in this case – is correct. As in real science, you test a hypothesis with an experiment. In the world of lean software development this experiment is called an MVP – a “minimum viable product.” The phrase “minimum viable” means “the minimum amount of development needed to test the hypothesis.”
Sometimes an MVP is as simple as a webpage. Sometimes it’s a complete development project in itself. It completely depends on the hypothesis you’re testing.
The point is to do the minimum work to find out if your hypothesis is correct or not.
What’s the worst thing that could possibly happen?
The process of prioritization always has winners and losers. You can test your prioritization with a simple thought experiment.
For each of the candidate features, ask yourself, what is the worst thing that can possibly happen if we don’t deliver the feature? Use the answers to this question for each feature to minimize the worst possible outcome.
It’s possible that not delivering a new feature won’t have a bad outcome, but delivering it would have a very positive outcome, so you can’t use this as your sole decision-making criterion.
Make sure that your boss’s pet feature is handled
This may sound cynical, but most of the time you’re not just optimizing your development team’s efforts to deliver value, but you’re also optimizing your own career.
Your success depends on you delivering good products and on staying employed and keeping your boss happy. If your boss has a feature that he or she really wants to see in the product, then that feature has extra weight in your prioritization. You might still cut it, but you need to have an especially strong justification for nuking it.
How to sell your decisions
With these techniques you should be able to come up with a well-prioritized list of features to deliver. Now you might ask – how do I convince my team and my executives that my priorities are correct?
Of course, these techniques contain much of their own justification and rationale. But as we know, decision-making is not just about rationality. In fact, the fundamental rule of persuasion is that “people make decisions emotionally and justify them rationally.” For more on getting your team’s and executives’ buy-in, check out my series on persuasion, starting with Persuasion Tips for Product Managers.
What prioritization techniques do you use?
That’s a few quick ideas on how to do effective prioritization of features into a release. You can also use these tips for prioritizing anything in your career (or life). Let me know in the comments if you make use of these techniques. Or if you have other prioritization tools you like to use.