How to Prioritize: Top 6 Techniques

Too much to do

As a product manager, one of the fundamental issues you will have in your life is that you will have a lot of things to do, and you won’t be able to do them all. Whether it’s the list of features and capabilities you want to implement in your product, or the customers you want to visit and get insights from, or the anthropological studies you should be doing with prospects in your market or the market you want to get into, you will not be able to do everything you want. This means you have to prioritize your activities, and what you ask from your developers (i.e., in terms of features), but you also 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.

Priority!

Prioritization is a critical capability for product managers

In this post I outline some of the basic concepts of prioritization, which we will explore in more detail in future posts. I’m not going to cover everything there is to know about prioritization, but give a number of techniques that (typically in combination) you can use to help you make better decisions about what to do. Better, at any rate, than simply flipping a coin. Of course, nothing is 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 if you want to have the best shot, here are some of the things you should think about.

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:

  1. Trust your instinct – more on this in a future post, but remember that one of the reasons you are a product manager is that 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 decisions.
  2. Analytics – either qualitative or quantitative. The types of analytics you can use to support your decisions varies widely. For example, if you have talked to several customers about a new feature, and they’ve all said it would be highly valuable to them, and your gut says most customers would get value from it, that might be enough “analytics” to move forward. Analytics can get a lot more sophisticated, of course – people use spreadsheets comparing the revenue outcomes for different combinations of features, and tools that graphically illustrate how well a set of requirements satisfies a set of prioritization criteria based on a market model, to 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.
  3. Stack ranking, and ignoring things at the bottom of the stack. Part of being a good prioritizer is not getting weighed down by the stuff you’re not going to be able to do, no matter how desirable it is. One way to help you achieve this clarity of mind is to stack rank your new features, with the most important ones – determined, perhaps using your gut instincts backed up with some analytics – and then 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 to deliver, concentrate on delivering that feature and ignore anything else that’s lower in priority. Once the most important feature is delivered (or complete and ready for delivery), then you can revisit the stack-ranked list, review the ranking, make any changes necessary, and then focus again just on the top items.
  4. Doing tests with a “minimum viable product” or MVP – sometimes you have an idea of whether a feature or a tactic will be valuable, 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, which in the world of lean software development has come to be 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, while sometimes it can be a complete development project in itself – it completely depends on the hypothesis you’re testing. The point is that you are not doing any more work than you have to in order to find out if your hypothesis is correct or not.
  5. What’s the worst thing that could possibly happen? The process of prioritization always has winners and losers, and one way to test whether your prioritization is correct is to do a 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? You can use the answers to this question for each feature to minimize the worst possible outcome. Of course, it’s very possible that not delivering a new feature won’t have a bad outcome, but delivering it would have an very positive outcome, so you can’t use this as your sole decision-making criterion.
  6. Make sure that your boss’s pet feature is handled. This may sound a bit cynical, but remember that 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 story for why that had to happen.

What prioritization techniques do you use?

That’s a few quick ideas on how to do effective prioritization of features into a release, or in general how to prioritize 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.

Tags: , , , , , ,

5 comments

  1. Going with your gut seems like it could be a risky endeavor, does it not? Perhaps not for a seasoned professional, but you have to get there first. Prioritization is a skill that people constantly struggle with in their work and home lives, and they very often make poor decisions. I would be interested in hearing how you might hone your prioritization skills to make sure that when you go with your gut, you can trust yourself.

    • This is a good and accurate concern, which is why I provide a lot of ways of prioritizing. I should perhaps make more clear that I expect to use all of these techniques in conjunction, letting the strengths of each manage the weaknesses of each. Each of them can result in a bad decision, so you really want checks and balances.

      For example, if I do analytic prioritization and it comes up with a different answer than my gut feeling, I need to do some due diligence to figure out whether the analysis is wrong or I'm wrong. It could be either (or both, actually).

  2. Prioritization is one of my favorite subjects! You make some excellent points here that I think bear repeating:

    * You've got to be able to defend and justify your priorities. I find two things help with this: 1 is to use objective data to help set priorities. A little data resolves a lot of arguments. 2 is to involve your key stakeholders early and often so they feel they're involved in the planning, that it is THEIR plan as well.

    * Most of these techniques can be used for prioritizing everything from bugs to features to product lines to what to have for dinner. Product people's decisions have a great effect on the success of their organizations, though, so getting decisions right is critical for them.

    * A balance must be struck between analysis of data and instinct. A spreadsheet-driven left-brained approach will put you in the right neighborhood, but the final decisions must be made by humans.

    * I'm a big believer in analytical techniques like relative ROI (ranking features as to how much contribution to business goals they will make vs. how much effort they require) and budget allocation exercises. Option pricing sounds interesting and I'd like to learn more about it. I've detailed more on this in my ProductCamp presentation on prioritization on Slideshare: http://www.slideshare.net/ProductCampBoston/prior

    * I'm also a big believer that testing an offer is the best way to get the real data for use in any analytical framework. This might be in the form of an MVP, dry test, beta, charter customer program or other means. Anything other than a customer order is a bit theoretical.

    I'm not sure that handling your boss' pet idea is a prioritization technique, exactly, but it does remind me of the point about getting buy-in on your priorities by involving key people (including your boss) early. That way all of the key stakeholders get a chance to at least weigh in on their pet ideas.

  3. […] a better approach, check my post on prioritization schemes. Or stay tuned to this blog – I’m sure I’ll be following up. Because to enable my […]

Leave a Reply