Feature Prioritization – 5 Methods To Help You Choose the Best Features for Your Product

Does this scenario sound familiar? You released the first version of your product some months ago and watched on with excitement as new users started to roll in. Things looked good - after all the long days and hard work, seeing the rising numbers of users visiting your homepage feels validating. But one month on, the picture looks much less promising. Perhaps only 20% of visitors sign up for your service, and after 30 days, maybe you're left with a measly 20 daily active users.

But you don't lose hope. Instead, you think, "This is a long game. I'm probably only one cool new feature away from making this product a resounding success". This is the Next Feature Fallacy - the idea that your next feature will suddenly make users want to use your entire product. If you've fallen into this trap, then you're not alone. However, it's critical to understand that your next feature won't save your product. This belief almost always fails.

To avoid falling victim to the next feature fallacy, SaaS product managers need to focus on a more strategic approach to feature prioritization. Luckily, there's an abundance of proven product prioritization frameworks to choose from. And that's what we're going to be getting into today. So without further delay, let's look at the 5 product prioritization frameworks that will empower you to create more impactful and engaging products.

Top 5 Feature Prioritization Methods

1. RICE Scoring Model

Source

Developed by Intercom, the RICE model uses four distinct factors for assessing priority and is particularly useful for sorting the feature requests from your users.

Reach: This is an estimate of how many people the feature will affect in a given time period. You can decide your own timeframe, for example, one month or one quarter. For example, if you estimate that 1000 users will reach your free-trial download page, and 20% will sign up, your reach score will be 200.

Impact: This is an estimate of how the feature will impact each person who uses it. You estimate impact using a 5 point scale, where 3 = massive impact, 2 = high impact, 1 = medium impact, .5 = low impact, and .25 = minimal impact.

Confidence: This is about assessing how confident you are in your reach and impact estimates. Essentially, confidence helps you account for the difference between evidence-backed estimates where you might have high confidence and "gut feeling" conclusions. Confidence is a multiple-choice score where 100%= high confidence (you have robust quantitative metrics), 80%= medium, 50%= low confidence, and 20%= moonshot (you should shift your priorities).

Effort: This is a measure of how much time the goal will require from the entire team (product, engineering, design). It's measured in "person-months," meaning the amount of work a team member can do in a month. For example, if the project will take a total of 2 person-months, your effort score will be 2. You're encouraged to use whole numbers here to keep it simple, but a minimum of 0.5 months is acceptable.

To calculate your RICE score, you use this equation:

Reach x Impact x Confidence / Effort

RICE scores are an excellent way to choose between competing ideas.

Pros of RICE Scoring Model
  • It's a framework SaaS product managers can use consistently to evaluate the relative value of different features objectively.
  • It helps limit team biases in decision-making (reduces subjectivity as much as humanly possible).
  • It takes into account the impact and reach of features.
Cons of RICE Scoring Model
  • Impact may include quantitative and qualitative estimates, injecting increased subjectivity into the equation.
  • Since RICE scores don't take dependencies into account, they can sometimes point you towards developing a feature that isn't feasible right now.

MoSCoW

Source

MoSCoW is a popular prioritization technique for SaaS product management and has absolutely nothing to do with the Russian capital. The acronym represents four unique categories and the product team is tasked with classifying features into these categories:

Must Have: These are non-negotiable features that the product/project can't do without.

Should Have: Features that add significant value but aren't vital to the product's functioning at launch. The absence of "should haves" shouldn't cause a project failure, but they're still considered important.

Could Have: These are less important but still wanted features. Could haves will have a lesser impact than should-haves if omitted from the project. They're the "nice-to-haves."

Will Not Have: Features that add little to no value or have some value but shouldn't be a priority to this specific release.

Pros of MoSCoW Prioritization
  • It focuses on collective knowledge, allowing you to incorporate stakeholders and representatives from the whole organization. This enables you to gain a broader perspective for your decision-making.
  • It encourages you to factor in effort and resource allocation when classifying features into different buckets. This can help you achieve a good variety of features for each release.
  • It's quick, easy, and intuitive.
Cons of MoSCoW Prioritization
  • Different people may have different ideas about what constitutes a "must-have" initiative.
  • Stakeholders and non-technical staff may not have a strong enough familiarity with product features to classify them accurately.

Value vs Effort

Source

Value vs Effort is a simple prioritization method that helps you quickly visualize your initiatives and make decisions at a glance.

It works like this: you give each feature a score for value (how important it is in helping you achieve your goals) and effort (how difficult it is to build). For example, you might decide to use a 1-5 or 1-10 scale, where the higher the number, the more value created or, the more effort required. To get your final Value vs Effort priority score for each feature, you use the equation value/effort.

For example, let's suppose you want to allow customers to pay using cryptocurrency. You might determine this will have an impact/value of 2 because this feature won't appeal to most of your customer base but may be very attractive to one customer segment (tech-savvy high spenders). You might already have the in-house skills to pull this off but need additional resources, so give it an effort score of 3. Your final value vs effort score for this feature will be 0.67.

Pros of Value vs Effort
  • It's popular due to its simplicity. Essentially, it allows you to structure your ideas visually and easily identify quick wins.
  • It encourages you to focus on the features (and even the bug reports) that will significantly impact your users while factoring in limited resources. In other words, it enables you to do the best you can with what you have.
Cons of Value vs Effort
  • Tons of variables are involved in determining value or effort, which can complicate or confuse the scoring process. There's a lot of guesswork.
  • Finalizing scores may take time due to competing opinions on value vs effort.

Kano Model

Source

The Kano Model helps you prioritize your software feature requests based on how likely they are to satisfy or even delight customers. The idea behind the Kano Model is that you shelve other priorities like revenue potential and instead focus entirely on customer satisfaction. Essentially, you plot the features on a graph with the horizontal axis representing the implementation values (the degree to which customer need is met) and the vertical axis representing the level of customer satisfaction.

You categorize features into five categories, basic/must-have, performance, delighters, indifferent, and dissatisfaction. However, only the first three should make it onto your roadmap (indifferent and dissatisfaction represent features to avoid).

Basic/must-have: The features your customer expects and will take for granted. Your product won't be a viable option without these features.

Performance: Investment in these features leads to a proportionate increase in customer satisfaction. For example, increasing file storage capacity in your app might have a linear impact on satisfaction levels.

Delighters: Also called excitement features, delighters significantly impact customer delight but aren't features your customers expect. They foster an outsized positive response.

You determine customer satisfaction by creating a dedicated Kano questionnaire.

Pros of the Kano Model
  • It's a helpful framework for teams with limited time and resources because it promotes prioritizing a healthy mix of features to include in the next release.
  • The Kano questionnaire provides a realistic snapshot of satisfaction levels and encourages teams not to over-prioritize excitement features over must-haves.
Cons of the Kano Model
  • Like all scientific approaches, the accuracy of your results is dependent on your sample size, which means multiple surveys and a large number of customers need to be given the questionnaire.
  • You can't guarantee that all customers will have a solid understanding of the features you're questioning them on.

Buy a Feature

Source

Buy a Feature is both a feature prioritization method and a fun little game. Essentially, you gather your list of features and assign a monetary value to each one. The value will depend on the time, resources, and effort required to implement each feature. You then ask your team members (or customers) to "spend" money on the features on the list. Some people will naturally give all their money to a feature they feel strongly about, while others will divide their money between features. Finally, you arrange your list based on which features amassed the highest monetary value.

Pros of Buy a Feature
  • It encourages people to think about why they want certain features over others.
  • It's fun and engaging, so people are less likely to come up with poor estimates to close out the task.
Cons of Buy a Feature
  • If you do the exercise with customers, it can be difficult to coordinate getting everyone in one place.
  • It may include features you've already implemented, which doesn't tell you anything about what to implement next.

Final Thoughts

There's often a buzz of excitement in the air when product managers talk about what they want to build next. However, this excitement can cloud your judgment and lead to less than exciting features. Likewise, the Next Feature Fallacy can lead you down the wrong path. With this in mind, feature prioritization methods are a great way to ensure you're focusing on the right features - the ones that will have a meaningful impact on your customers.

Need to collect feature requests from your users? Userback’s visual feedback software makes it easy to collect and manage product feedback in one place. Get started with a free account and collect user feedback in your web application today!

Try it!

Contact Us

Thank you!
We will get back to you as soon as possible
at .