How to Prioritize Product Features: Popular Strategies and Prioritization Frameworks

Have you ever been to an all-you-can-eat buffet? If you have, most likely you've seen how the endless variety of dishes makes many people's eyes diverge. It seems as though they want to taste everything. One too often, they end up having tables crowded with plates of food that's impossible to consume in one sitting. And if a person does somehow manage to eat it all, a stomach ache probably won't be long in coming.

If we transfer this analogy to a project and think of its features as the dishes available in the buffet, we should aim for the "healthy eating" way of thinking. You can have a good and filling "meal" if you choose several decent options without stressing your "body".

This is especially true for early-stage projects that are on their way from idea initiation to MVP development. So, how do you single out the must-have functionality that should be present in your product first of all? On this page, we outline how to prioritize features for your product roadmap and give tips on the available models and methods to help make up your mind.

Selecting the features that you should focus on first may be tricky. After all, they must bring the utmost value to your users and highlight the product’s uniqueness. Here are several steps that you can follow to get things going in this respect during your project discovery phase.

Step 1: Define the Problem Your Product Is Solving

For starters, you have to figure out which main problem your product will solve. Why are you even planning to create this solution in the first place? This is a vital proof of concept (POC) point to determine as it can really dot the i's regarding your overall mission, vision, and goals, setting the development direction.

Based on what you decide, you'll have to do your research and start putting down ideas on how to make it happen most optimally.

POC vs Prototype vs MVP: Explaining the Difference

Article by

Maria Arinkina

Step 2: Create a Feature Backlog and Organize It for Clarity

As a rule, you'll end up with quite an extensive list of feature suggestions and things you want to bring to life. But you probably won't develop them all (at least not straight away).

You don't have to give up on your ideas, though. That is, it doesn't mean that if you don't work on them now, you'll never do so. It's more about deciding where you're putting efforts at the moment. So, get a feature backlog to store the ideas you came up with during brainstorming sessions. This way, they won't get lost or forgotten.

Next, do your best to "clean up" your backlog, grouping ideas and structuring them in themes, goals, your product development roadmap, or request source (where the idea came from). Maybe some ideas are duplicated or regard similar things? You'd be surprised how much you can learn by taking the time to do this activity. 

Step 3: Make Informed Decisions as You Begin Prioritizing Features

When your scope of features is well-organized, it's time to move on to product feature prioritization. Weigh the pros and cons of keeping a feature, prioritizing it, or putting it off for after MVP release or the upcoming product update. Honestly, it's also possible that as you start developing a product (or as it grows step by step), at some point, you'll discover that it may not seem reasonable to develop some of the selected features anymore. For instance, they might no longer align with your strategy.

So, how do you choose what to develop? To avoid common startup mistakes, make sure to:

• hear out the opinions of various team members (don't leave decision-making to just one person, try to be unbiased and collaborative);
• not rely merely on your intuition (doing something just because "you feel that it'll become a big hit" can be risky);
• keep an eye on data (startup analytics can serve as an excellent basis to see trends and make predictions about the value of a given feature);
• mind your budget and resources (whether the idea's value justifies the needed investment);
• use proven methods and techniques to simplify your product prioritization process (we'll go over the ones you can use a bit later in the article). 

What Is a Minimum Lovable Product? Comparing and Contrasting MVP vs MLP vs MMP

Article by

Maria Arinkina

Is This the Only Way to Go?

No, but it is considered a best practice. Sure, ideally, you'd want your audience to see your product in full force right from day one. You'd want it to be fitted with the entire functionality spectrum straight away from the first launch. But such projects require a lot of resources, including time and investment. And speeding things up means spending extra on team expansion or hiring an additional workforce. Can you handle everything you're putting on your plate in this case? This is one of the crucial product development questions, which you should take the time to answer.

The thing is that even if you do have the time and money to spare, working on rolling out all features at once isn't always reasonable. For starters, if you invest in creating something that no one needs before you find product-market fit, you're up for a considerable risk. Why else? Well, there's always a chance that:

• a competitor will land on the market with something similar before you do;
• or your product might not be received by the audience how you expected it, paving the way for lost funding and many do-overs.

Hence, less is more here, and the alternative is to build things gradually. You just have to finalize what should be done first and what you can save for later. There are multiple ways to approach feature prioritization and there are numerous product and MVP tools created for that. So, let's review the possible models, methods, and techniques that you can find helpful.

There's so much to decide at the very start of the project. How do you pin down the cream of the top features when you attempt to form your product vision and concept? The following three models can clear many things up.

Story Mapping

Try to look at your product with your user's eyes. What problems do your customers have, and how can your product solve them? Which obstacles can a user face as they carry out an action?

First of all, story mapping implies creating user personas. Define who these people are, what their aims are, and how they'll interact with the product. User experience is key here.

Let's say you're thinking through a convenient solution for a car service CRM. Jane, a reception manager, might receive a service booking request from a client via a phone call. How many clicks could creating such a booking record in the CRM take? Which fields should she fill out? And how will Paul, a car mechanic, see this booking record and continue working with it?

When mapping such a story, you'll need to jot down:

• the personas (various types of users);
• the cases they can encounter;
• the possible task options;
• the activities with detailed descriptions of the actions they'll perform step-by-step.

Based on that, you get a mapped workflow, so you can think about how to prioritize features and determine what has to be taken care of for your first launch and which features can be added as your product evolves. Of course, you can supplement your product with additional personas, use cases, and stages later on.

Product Tree

Picture an apple tree. You can reach the lower part of the trunk and the low-hanging fruit with your hands, while the higher rest requires ladders or additional tools.

You can use a schematic representation of your project via the Product Tree method to prioritize features. It helps visualize the importance of the planned functionality, so you can use a template or draw the tree on a whiteboard during brainstorming. Optionally, make use of sticky notes, giving every team member about five, so they can pitch their feature ideas and place them on the tree according to where they believe it belongs in terms of priority.

The must-have features go on the trunk, the ones you plan for the early release go on the lower branches, and put the less prioritized ones higher. Mind that the tree trunk represents your product's foundation and essence. Then, analyze the result, discussing which features were mentioned more often than others and how to prioritize them.

Quality Function Deployment

Short for QFD, quality function deployment is a product prioritization framework that was introduced by Japanese manufacturers. It emphasizes quality assurance, user satisfaction, and client requirements during product development.

The method allows for getting a better understanding of what to prioritize and what brings value. I.e., you can determine the customers' preferences, expectations, challenges, requests, needs, and demands by hearing out their points of view. Then such obtained insights are converted into a plan of future features in a clear and structured way.

How does it work?

1. Obtain client feedback (referred to as "Client Voice"). QFD implies running surveys, interviewing potential buyers, and communicating with focus groups. You should ask five to ten questions about the features they need.
2. The collected client data is then put in a matrix that's sometimes called "House of Quality".
3. Analyze the answers and evaluate the ideas to rank them in priority.
4. Assess competitive solutions and create technical requirements that should ideally be tied to the information given by those surveyed. That is, try to figure out how to bring these ideas to life.
5. Then, pass on such features for further design, development, QA testing, and release.

Why should you consider this method? Mainly because it gives you the chance to build a product that'll live up to the customer expectations, keeping their needs in the spotlight. If your team's ideas correlate with your customer needs, you're surely on the right track.

Is there a product feature prioritization framework for simplifying release planning and MVP product launch? Sure. Here are a few more models you may consider implementing for your project.

MoSCoW

The MoSCoW method is a very effective and quick way for you and the team to sort your features. Imagine going through your closet and putting your stuff into four boxes. Similarly, you can place your features into four groups based on how important they are as follows:

• Must have
  These are the obligatory first-priority features that have to be present in your product no matter what. Usually, this is the key functionality that allows the product to solve its most important problem. Put down features that significantly impact the product's success and are thus very valuable to the users and the project. I.e., without these features, your product will definitely give in to competitors and fail to satisfy users.
  
  
• Should have
  These are important features, but they don't influence the core product much. They could improve metrics, make the product better, and enhance it overall. That is, such functionality isn't critical for the product (for instance, if it isn't present, users won't face any challenges).
  
  
• Could have
  Put the ideas you toss aside (something you might work on someday) in this box. These can be ways to boost user engagement or some extra features that may be of hand as additional perks for customers.

• Won't have
  This is where the ideas you've turned down go. If you've come to find that some features aren't doable at the moment or aren't worth developing, place them in an out-of-scope archive, noting the reasons for rejection.

Kano Model

This model is a product prioritization framework based on a questionnaire technique. It is applied to see the likelihood of users enjoying a feature (be it basic functionality, for boosting performance and customer satisfaction, or an exciting feature to delight your clients).

To achieve Kano results, provide your surveyed audience with a list of carefully selected questions on their attitude towards specific product functionality or its absence. I.e., you'll have to ask how they feel if this or that feature would or wouldn't be present by giving a choice, for instance:

• I like it
• I expect it
• I'm indifferent (have a neutral opinion)
• It doesn't bother me too much 
• I don't like it 

Put the answers on a matrix and make conclusions according to the collected answers. It can signal the importance of having a feature or, on the contrary, that it isn’t worth the time.

Scorecard

The scorecard method is commonly used for feature screening. It implies:

• lining out features of a single theme;
• scoring them based on specific criteria that you and the decision-makers agree upon;
• and then setting priorities.

The criteria can include business value, development complexity, urgency, user experience, or anything you believe matters.

For instance, you can have three relevant features listed in the "boosting mobile conversion" theme. How do you decide which of them to put in production first? Think about the criteria that can help you evaluate the given features and put them in columns in a table. Then assign each feature a score based on the maximum weight it can get per every category according to its impact. The weight can reflect how important a category is overall. Finally, calculate the resulting priority score, ranking your features (in this example, from 1st to 3rd place).

Opportunity Scoring

Opportunity scoring is another feature prioritization technique. It evaluates features according to user opinions, highlighting the user experience. In essence, you reach out to your audience to get their feedback and then assess the features based on customer satisfaction and on how important the users think the feature is.

Generally, you have a specific user problem in the spotlight, and you try to determine the users' satisfaction extent with how competitor solutions (or your existing solution's current version) are solving this problem. You can ask the surveyed users to rate your list of features by importance and satisfaction from 1 to 10. Then put the results on a matrix to discover which features are overserved, appropriately served, or underserved. The features in the latter category present business opportunities and should be put higher in priority. 

RICE Method

RICE scoring is also commonly used for prioritizing product features. This method looks at a feature from a more objective and data-backed perspective, omitting many biased opinions and underlining facts during decision-making.

You'll have to rank your features and ideas against four criteria:

• Reach is among the often-tracked product performance metrics. And in this case, you can estimate how many users your product might get in an expected time period based on data (say, 100 free trial sign-ups in 1 month).
• Impact can be either a quantitative or a qualitative measure, such as the number of expected conversions. But you can try to intuitively estimate whether developing a feature will influence the result, ranking it with a 3 (massive impact), 2 (high), 1 (medium), 0.5 (low), or 0.25 (minimal).
• Confidence is marked as a percentage based on how sure you are that a feature should be developed: 100% (high confidence), 80% (medium), 50% (low).
• Unlike the first three points that are more about possible gains, Effort represents the required input to develop a feature. Hence, you need a rough estimate of the resources you'll need to invest in bringing the feature to life.

The final RICE score can be calculated using the following feature evaluation formula:
(Reach x Impact x Confidence) ÷ Effort = RICE Score

Buy a Feature

Perhaps, this is one of the most entertaining methods of prioritizing features as it's done in a game format.

Present each of your features on separate cards with a description and development cost. Importantly, the cost estimate has to be more or less realistic, taking into account the time and resources you have to spend on a feature's creation.

Then, gather the participants (ideally, your potential customers, but your team members can be involved too) and give them a limited amount of money they can hypothetically spend on buying one or more features. Jot down the arguments people make in favor or against their investment choices. Then, analyze the results, selecting and ranking those features people spent money on most often.

It might be so that even after applying the models mentioned earlier, you may still face difficulty when making up your mind. For instance, you end up with several equally valuable features to develop but can only afford one or two. What do you do when you can't determine which shortlisted features are more important? How do you choose one over the other? Here are a few tips to help you rationally pick sides as you make your final choice.

Impact vs. Effort

Comparing impact and effort is one of the ways to look at the problem. Yes, there are multiple things that your customers expect and want, but how hard will it be to develop them on your end?

Try to analyze the features and align the user needs with the required development effort (not invested money). Effort can, for example, be calculated in working hours and team size. You'll likely find out that your listed features fall into one of the four categories:

1. Has a high impact and is simple to create
2. Has a high impact but is hard to create
3. Has a low impact but is simple to create
4. Has a low impact and is hard to create

From this perspective, the features in the first and second categories are more important, the ones in the third category can possibly be put aside for some time, while the fourth category features might not be worth it at all.

Value vs. Risk

Now, let's evaluate the features in terms of risks. In this case, you should think about the following things when prioritizing features:

• how expensive it'll be to develop a feature (whether it's in line with your budget, especially if you're keeping an eye on your MVP development cost);
• how long it can take to develop a feature (whether you'll meet your expected deadlines and run on schedule);
• how sure you are that you'll deliver a quality product and that it’'l be in demand.

Value vs. Complexity

Once again, putting business value and development complexity on the scale is crucial. Value can be presented by your potential revenue.

For example, you may want to create a neat side feature that some of your users may enjoy, yet it doesn't directly aid in solving the main user problem and is difficult to bring to life in terms of development. 

By giving features a technical assessment, you can better understand the development complexity, the appropriate tech stack, required team size, insights on lack of expertise, the possible timeline, etc. Will supporting and expanding the feature as your product grows become harder? These and many more questions may get answers.

The bottom line is that complex feature creation is usually feasible when you're building your product's core functionality and can afford a team to make it happen. Otherwise, you may consider setting it aside.

Top MVP Development Companies to Work With

Article by

Maria Arinkina

Choosing and prioritizing features is an integral part of product development. It's a tough choice, but you have to be realistic. Try to find the middle ground, emphasizing functionality that'll really matter, bring your company and customers value, and be tied to your overall business strategy and long-term goals.

This isn't a one-time task, though. To be successful, you'll have to review your priorities and possibly go over the process from time to time to stay on track. But it can be a simpler task to tackle if you use one or more product prioritization frameworks described above and cross-examine the received results.

If you need assistance, Upsilon has ample experience in development projects and provides various web development services. So don't be shy to browse Upsilon's dedicated team pricing or contact us to discuss your project needs, we'll be glad to provide a consultation and help!