A Full-Fledged Guide to Product Feature Prioritization

A great feature idea for a software product is something every product manager is eagerly looking forward to. But only until the moment these ideas start flooding and there are just too many for you to keep track of them. You start putting them down – and you’ve got yourself a backlog. Which means that now you have to choose the features that need to be implemented first and the ones that should or can wait.

From the 33 years of outsourced software product development, we’ve learned that the complexity and importance of feature prioritization stems not only from the fact that the resources are limited. The truth is that not all the ideas you have in the backlog may be in line with your product strategy. Still, tossing ideas aside is understandably hard: behind every suggested feature is a person or a piece of data, and to turn down or ignore either of those you have to present sensible reasons. The many product feature prioritization methods were coined exactly with the intention to help you find these reasons.

In our full-fledged guide on how to prioritize features, we explain why you should do the following things and how you should do them effectively:

• Organize your feature backlog (if you have it)
• Use product roadmap themes
• Resist the ‘noise’
• Choose the prioritization model that fits your goal
• Use special techniques for final screening or overcoming choice paralysis

Starting Out

Before choosing and applying any feature prioritization technique, you should properly sort out your current list of ideas, group them into ‘themes’, and learn to collect opinions instead of catering to them. Here are some strategic tips on performing these tasks.

Tidy up your backlog

If you already have a backlog, chances are the feature ideas in it came from different sources: some from you or people in your product team, some from your colleagues outside the team, others – from your existing or potential users. All these people have different views of the product and thus formulate their ideas differently. For the prioritization process to go easier, make sure the ideas are phrased as explicitly as possible and aren’t reiterated.

The thing is, behind two differently formulated ideas there can be a single feature concept. For instance, what your users may phrase as ‘possibility to share software data online’, your product team sees as ‘introducing email and social network integration’. And vice versa: while your team has a vague plan to ‘expand comment functionality’, users may phrase the idea more clearly by asking to ‘allow to attach images in comments’. Strive to have an uncluttered and detailed feature backlog before you start prioritization.

Consider grouping ideas into roadmap themes

Unlike features that you should formulate as explicitly as possible, themes often sound blurry, because every theme is simply a motto for reflecting your specific goals in the product roadmap. For instance, ‘enabling push-notifications’ and ‘add gamification to certain existing features’ can be united into an ‘increasing user retention’ roadmap theme.

It isn’t necessary to single out themes, but they give you a high-level look at your ideas and remind you to keep to a long-term product strategy. Moreover, since roadmap themes naturally create a convenient structure in your backlog, they may be especially useful when you have a very large list of suggested ideas.

Don’t give in to the noise

As soon as you start your feature prioritization process, you often face ‘noise’ – the voices that tell you to make a certain choice without bothering with deeper analysis. To make a well-thought decision, you need to collect different insights and opinions instead of giving in to only one of them in the form of:

• Expert opinions

Whether an opinion comes from a person on the product team or not, from your coworker or an executive, don’t zero in on it. You should certainly take note of what a sales manager thinks would sell the product better or what, according to a customer support specialist, would make the product perform better. But even though such opinions are valuable, they are often biased. Don’t let yourself get sidetracked and focus on collecting input rather than rushing into making a decision.

• Market Data

Although market data is indispensable for an objective decision, don’t let it be the only factor to govern your choice. Market predictions and evaluations are always approximate and can lead to wrong conclusions. Give chances to features with various market data background and mind not only the figures, but also the voices of your clients.

• Hunch

No matter how powerful you believe your gut feeling is, don’t trust it with making feature prioritization decisions and always make sure to get more tangible proof before making any decision regarding your product strategy.

You shouldn’t disregard your intuition entirely but avoid basing your decisions on them before trying to see the full picture with the help of any of the 9 feature prioritization models that we describe below.

Models for Forming Product Vision

The prioritization models below require no backlog or existing user feedback. They help you to visualize your product from scratch and ensure its feasibility and viability, which makes them a perfect fit for planning MVP development.

Story Mapping

Participants: Product manager or team

Required: Paper/Whiteboard and sticky notes

Specifics: Focus on user experience

The essence of Story Mapping is to put yourself in the shoes of future users of your product and think about what tasks they would like to perform with the help of your software. This prioritization framework encourages you to come up with a list of user personas, their goals, and detailed action scenarios. When united, all maps for different personas create a product vision.

For example, you’re planning out a document management software. One of the tasks to consider is approval workflow management. Possible user personas, who will be performing this task, are an account manager and a lawyer. List each of the two persona’s actions taken to perform the task as main stories and then break each of those down into detailed activities by describing step-by-step actions. While doing it, you’ll notice that some activities can be done differently: you can select people who should approve the document from a given list or search for them by typing in the names. Write all the options and include the easiest to implement (‘choose from the given list’, in our case) in your first MVP release, leaving the other option for later. As a result, you get the following map design:

Story mapping is especially great for MVP development projects because it works best when your entire product is yet a concept, and you are trying to build it from scratch. If you start creating a story map of your product at this stage, you can always keep track of your ideas, important for product evolution strategy, and expand the vision further by adding new personas and stories to the existing map.

Product Tree

Participants: Product manager and team

Required: Whiteboard, sticky notes

Specifics: Visualization tool for product team discussions

Similar to Story Mapping, the Product Tree framework is great for pushing a product forward from its fledgling stage. For this method, you need to draw a big tree on a whiteboard, leaving some free space in its trunk – the place for the core of your product. The lower branches of the tree are meant for the features you are going to introduce in one of the first releases. The higher branches are, as you may guess, for the features that should come later.

Give out 5-10 sticky notes – ‘leaves’ – to your product team, ask everyone to write down features on them and then let them place each leaf where they think it belongs: trunk, lower branch or higher branch. After your team fills the tree with sticky notes, you can collectively discuss the vision of your product and analyze how many times one and the same feature was put on the same place by different people.

Quality Function Deployment (QFD)

Participants: Product manager and team; potential customers

Required: Paper / Whiteboard

Specifics: Focus on user experience

QFD method has Japanese roots and its main purpose was to introduce quality assurance that would ensure customer satisfaction with a product before its implementation. Feature idea elicitation is a part of this technique, so QFD is especially useful for MVP planning.

Here, you’ll need help from the people outside the product team. In the ideal case, they should be your potential customers, who are interested in the solution you’re going to provide. But of course you can involve anyone who can easily get the gist of what your product idea is.

First, collect the ‘Whats’: ask your potential customers what 5-10 features they need and expect to be in a type of product like yours. Then get the ‘Hows’: start a brainstorming session in your development team and describe their picture of how your product should work in a list of ideas. In theory, as you compare both lists, every ‘What’ should directly coincide with a ‘How’, but in practice this is a rare case. The QFD method helps to uncover this imbalance and analyze the relations (‘strong’, ‘moderate’, ‘weak’ or ‘no relation’ ) between the ‘What’s and ‘How’s.

The creators of the QFD method suggest paying more attention to customers’ expectations and prioritizing them above the features generated by product management. The features that were mentioned by both the customers and your team are, naturally, the core of your MVP.

Models for Release Planning

Models for release planning are most fitting for lean and agile product evolution project as they tend to take advantage of the fact that you already have a customer base.

MoSCoW

Participants: Product team

Required: Feature backlog, user feedback

Specifics: Simple and self-explanatory categorization

We’ve covered this model in our guide to product development, because it’s a very simple yet quite effective release planning method. Its advantage is in clearly defined buckets that you should distribute your list of features into: ‘Must have’, ‘Should have’, ‘Could have’ and ‘Won’t have’ – hence MoSCoW.

• ‘Must-haves’ – functionality that can significantly impact your user-experience and/or economy. Often these are features, the lack of which frustrates your users or even hampers your software’s performance. They have the biggest value for enhancing your metrics and should be planned for the soonest release.
• ‘Should-haves’ are features that can tangibly improve your metrics, but their absence doesn’t pose any major inconveniences to users.
• ‘Could haves’ – functionality that can raise user engagement or attract new audience; they aren’t critical, but you might start working on them later, when your product is stable.
• ‘Won’t-haves’ aren’t necessarily features that you don’t plan to add at all, rather – not any time soon.

The Classification Ranking technique is very similar to this model, but instead of modal verbs you use numbers from 1 to 5 to rank feature importance from high to low. Also, unlike the MoSCoW technique, Classification Ranking implies that a product manager ranks the features on their own and without referring to user data, which creates the risk of bias. Still, it can be effective enough for small or internal projects since it’s extremely time-efficient and easy.

Score Card

Participants: Product team, Customer/Investor

Required: Feature backlog

Specifics: Best for discussions with the decision-making party

The Score Card technique can use original criteria, which makes it very convenient in the talks with a client, investor or someone else, who has the right and reasons to approve or decline the launch of certain functionality implementation. By listing this party’s custom criteria and then giving an estimate of how each feature in the list impacts each criterion, you can single out the most fitting ideas.

You can make prioritization even more strategic by weighing each feature against a certain roadmap theme that the team and the decision-making party have agreed to focus on. Let’s say, you all chose to concentrate on the ‘raising conversion’ theme. Then, even though ‘introducing cloud storage backup’ can have high value according to the investor’s/customer’s criteria, it will have a ‘no theme match‘ mark in the theme screening and get a lower priority than the ‘facilitate e-invoice payment’ feature.

Opportunity Score

Participants: Existing customers

Required: Feature backlog

Specifics: Focus on user experience

Opportunity Scoring is an elegant scoring technique than implies close cooperation with end users. Antony Ulwick, the creator of the method, suggests using two major parameters for assessing features: Importance of a feature that would solve a certain problem (otherwise can be considered ‘Acuteness of a problem’) and Satisfaction with how this very problem is currently solved with the help of your or your competitors’ products.

After you reach out to your user base, offer them the list of your features/solutions and ask them to rate each of them by Importance and Satisfaction on a scale from 1 to 10. Once you collect the data, you can create a product prioritization matrix to see which features belong to the highest importance + lowest satisfaction ‘underserved’ sector that you should focus on.

Kano Model

Participants: Existing or potential customers

Requirements: Feature backlog, questionnaire

Specifics: Extremely detailed user experience results

Coined by Noriaki Kano, the Kano model implies the use of a questionnaire – a list of carefully formulated questions that you address to your users. While drafting the questionnaire, make sure you cover all the functionality you want and dedicate a pair of questions to every feature. One question should ask about a user’s attitude to having a feature in the product (‘How do you feel if you can customize all types of notifications‘) and the other – about not having the same feature (‘How do you feel if you can’t customize notifications’). Ask your clients to choose an answer that would best reflect their experience:

• I enjoy it
• It’s basic essential
• I am neutral
• I can live with it
• I can’t accept it

For each feature you offered, group the answers related to a feature’s presence into a ‘functional’ group and those related to its absence into a ‘dysfunctional’ group. Count the average amount of each answer option you collected (this is your answer score) and fill in the matrix below. Any cell in either of the two highlighted sectors having a high answer score indicates the importance of the feature in question. High score in the second sector signifies that the feature can introduce too much complexity of use, causing controversial feelings and appearing excessive or unwanted.

Although it may be time-consuming, the Kano model produces detailed and useful results. The ability to see the functionality that can be considered excessive has extreme value, since it helps to avoid feature creep.

Buy a Feature

Participants: Potential or existing customers

Required: Feature backlog

Specifics: Gamification elements that produce less biased results

This feature prioritization method livens the tedious process up with gamification elements similar to Monopoly. This is an important aspect, because when you need to get the most effective data from your clients, you should strive to raise their interest and involvement. Moreover, the gamified process lets the participants express their opinions more freely and makes the results less biased.

Start by giving each feature in your backlog a financial estimate: the amount of money a feature would cost you to develop is the amount of money it could be bought for. Then assemble a group of 5-10 customers, appoint equal ‘budget score’ to each of them, and ask to spend this virtual money on features. As your participants will be making their purchases, ask them to explain their choices. As a result, you’ll be able to see in practice what functionality your user base is willing to pay for.

Speed Boat

Participants: Existing product users

Required: Whiteboard, sticky notes

Specifics: Best for uncovering product weak points

Speed boat is another gamification-based technique, but its purpose is not direct feature prioritization. The method helps to reveal the existing weak points in the product that you should target in order to introduce impactful improvements.

After you assemble a group of existing customers, draw a boat with a few anchors on a whiteboard. The anchors are what holds the boat back from going full speed. Give each user a sticky note, ask them to write some issue with your software – an existing or lacking functionality – on it and then place a note on an anchor. Let users explain how fast, they think the boat will be able to go when the issue they pointed out is resolved.

Once you collect the anchor-notes, you can analyze what, according to your users, is in the way of your product’s success. Refer to this input while going through your backlog and zero in on the features that address the uncovered weak points.

Techniques for Final Screening and Overcoming Choice Paralysis

In some cases, following a product feature prioritization model can still leave you uncertain. This happens if, for instance, the results point out too many product features that have almost equal value for your clients or you and your team.

To overcome this choice paralysis and make your feature prioritization choice more confident and balanced, you should step back and look at your ideas and product from a different angle. The techniques below help you to do this final screening.

Impact vs. Effort

This method suggests comparing the customer needs with the development efforts necessary to satisfy them. First, analyze each feature’s user feedback that you’ve gained via some other prioritization technique, then estimate its implementation costs, and place the feature on the Impact/Effort feature prioritization matrix. In the end, you’ll have four areas: ‘quick and easy win’, ‘meaningful strategic goal’, ‘lowly craft’ and ‘a fool’s errand’. Needless to say, it makes sense to cast the functionality that belongs to the two low quadrants aside.

Value vs. Risk

It is always insightful to measure each feature’s value against implementation risks. Value, in this case, equals the current priority level that you’ve assigned to a feature during the prioritization process. The risks may be the following:

• Budget risks – when feature implementation may cost too much
• Schedule risks – when developing a feature may take too long
• Resources/feasibility risks – when quality implementation of a feature is questionable

Even if you ended up with numerous features having similar values, the budget, schedule and competency risks of their implementation will be different, which will help you with prioritization.

Cost of Delay

The Cost of Delay model offers to look at the risks of postponing the implementation of the features, even when many or all of them are considered critical or must-have. Although the time estimations are, of course, approximate, the change of focus from feature ROI to the possible consequences of delay can have a refreshing impact.

Take each feature you narrowed your backlog down to and give an approximate man-hour estimate to its development when answering the following questions:

• How much will this feature cost if we develop it now?
• How much would this feature have cost if we implemented it earlier?
• How much will it cost if we develop it later?

Once you have all your answers, you’ll be able to single out the product features with the highest risks of growing costs – for instance, the ones that require more and more effort and time to develop as your software keeps evolving.

Final Tips

Here are some final tips for your feature prioritization process:

• Some techniques (e.g. Story Mapping, QFD, Kano model) may require more time and effort than the others. This sort of investment will help you to build a confident product release strategy, so don’t cut corners.
• Consider leveraging apps from this guide to product management software. The listed solutions help you conveniently organize and prioritize product features, assist your team in testing out prototypes, as well as provide valuable input for product decisions by letting you monitor users' interaction with your MVPs.
• Some models (mostly those meant for lean and agile release planning) require not just user feedback data, but direct involvement of your clients. Gathering even 10 users in one place may be a challenging task, especially for startups. In that case, consider reaching out to your users over the Internet and make sure to get them interested in answering your survey by offering them a reward (e.g. a free week of using your services or a discount). Sure, you can always involve your product team members instead of customers, but you should understand that this will significantly skew the results, so make this your last resort.
• Don’t disregard final screening. Even if you are confident in your choice, take some time to look at your decision from another perspective. You may find some important aspect that you overlooked in your previous analysis and discussions.