4 great feature prioritization methods for an MVP

In this article, I will talk about four common methods of prioritizing features for an MVP. But first, let me get the basics out of the way. 

What is an MVP?

MVP stands for Minimum Viable Product, which to me always sounded like the crappiest possible version of something you can sell. But it’s not that. An MVP is a version of a product with just enough features to satisfy early customers and provide feedback for future product development.

Let me stress “satisfy” and “provide feedback”. Firstly, the user experience should still be good, even with this minimum set of features. Secondly, it’s the feedback that holds the critical value, providing the product team with validation about features and assumptions and thus guidance for the product’s future direction. We all need validation from time to time.

What is MVP Features Prioritization?

Before work on an MVP begins, the product team will have created a full list of all the features they want their product to eventually have. Such a list may be extremely long—long enough that deciding where to start is a puzzle in itself.

Thankfully, various methods have been developed by various people to solve that puzzle. I will be discussing methods called MoSCoW, FP Matrix, Story Mapping, and Kano. Features Prioritization helps to define boundaries between wants and needs. It helps designers think dispassionately about which features are core and which aren’t. It’s like an editing process for your features—kill your darlings and all that.

Each method of prioritization has its own set of use-cases and pros and cons. Some methods are intended to provide rapid orientation for the design team; others are more involved, bringing in decision-makers and taking into account effort, user flows, and even cold, hard cash considerations. There is a method for teams of every size and budget.

How does MVP Features Prioritization fit within development processes?

Most design teams work under a broad framework that starts with an idea and ends with a market-ready product. Examples include NPD (new product development) process and Design Thinking, which is the method I am most familiar with. The design thinking framework is structured thus: empathize, design, ideate, prototype, test. Alternatively, the NPD process follows the structure ideation, product definition, prototyping, detailed design, validation/testing, commercialization.

In both cases, MVP Features Prioritization occurs in the definition phase, after research but before Information Architecture (if you’re doing it) and before you start building specific user journeys.

Research is vital to successfully prioritizing MVP features. Research provides the data on which to base decisions. Without it, prioritization is just a matter of opinion, which is no good and will cause arguments. Indeed, even after research it is possible that members of a design team will have a clash of opinion over which features to prioritize. In the case of deadlock, the best approach is to conduct additional research, which could be further interviews or user flow testing. Windmill has done a three-part series on how to get the best data from your user research, which I recommend reading.

Common Feature Prioritization methods

Now that the scene has been set, it’s time to dig into the four most commonly used methods: MoSCoW, FP Matrix, Story Mapping, and Kano. I have ordered the five roughly in order of increasing complexity.

MoSCoW

MoSCoW is a straightforward method of prioritizing features. It allows for four classifications of features: Must-haves (Mo), Should-haves (S), Could-haves (Co), and Won’t-haves (W). But how do you tell a should-have from a must-have or a not-needed?

Must Have category is used for features that are critical to the current delivery timebox in order for it to be a success. These are features that form what is sometimes known as a “walking skeleton” – the barest bones that will form a product that’s functional and meets legal/regulatory requirements, but not one that would be competitive in the marketplace.

Should Have are the features that make your product worthwhile existing, that make it competitive. 

Could Have is a category for features with uncertain revenue potential and which aren’t so crucial for market visibility. These most likely won’t make it into the MVP unless the product is very well-funded.

Won’t Have are the features that are not critical and won’t be in the MVP. Features like alternative colors.

MoSCoW Method Pros and Cons

Pros: MoSCoW can be a quick process, orienting the design team in as little as thirty minutes or within a single workshop.

Cons: MoSCoW does not take into consideration non-design points of view, such as effort and cost/time, or involve technical representation.

Feature Priority Matrix

Feature Priority Matrix is similar to MoSCoW in that it has four priority categories. Where it differs is that it introduces effort as a second axis of decision-making.

The second axis allows for the categorization of features that are both useful and easy (or useless and difficult). As such, the four buckets differ somewhat from their MoSCoW equivalents.

Big Bets are features that add great value to the product but take considerable time and effort to develop. Quick Wins also add great value but are relatively easy to accomplish.

Maybes are roughly analogous to the “could-haves”: features that are easy to develop but of limited usefulness. And Time Sinks are low-impact features that are nevertheless high-effort.

The inclusion of effort increases applicability to real-world situations that a team might encounter. For instance, when discussing priorities with a client, it is easier to make the argument that a certain feature they want is considered a time sink, and thus should be excluded from the MVP. Or, with two weeks until launch, you can prioritize high-impact features with a short development time.

On the downside, without technical representation, effort estimates can be inaccurate.

Story Mapping

Story Mapping is my favorite method and the one I’ve used most frequently. The method introduces User Journey into prioritization. Features are added under their respective activities and ranked according to necessity. Story Mapping provides a broader perspective on the product while allowing for more granular features than in prior methods. 

The topmost features are designated as the Walking Skeleton. A line is then drawn between the columns that designates features for inclusion in the MVP.

One advantage of Story Mapping is that, thanks to clear representation of user activities, it’s easier to spot missing steps. A short list of features under one User Journey indicates that that journey might not have been mapped out fully. 

On the downside, an example story map is one thing, but a real-world story map can be a huge, evolving thing. Duplicates will be common and the map will require dedicated effort just to keep it up-to-date.

Kano

Named after the Japanese professor who invented it, Kano is the last method of Features Prioritization I’m going to discuss. It’s the most complex of the methods and the first to include money in the prioritization equation. And as you may well know, there are no short conversations when money is concerned.

Kano maps satisfaction against effort/money, and identifies four types of product features.

Basic features are similar to the Must-have MoSCoW features, but basic does not necessarily mean cheap. You will be spending a lot of money on things that are so expected that they do not contribute positively to satisfaction. That’s why the Basic curve does not even touch the neutral satisfaction line. A car, for instance, has a huge number of expensive, basic features that have to be included as given.

Neutral features don’t add much value. Perhaps they have limited use-cases, such as the extremely niche features that can be found in Excel that barely anyone uses. 

Performance is where we plot features whose quality can be a differentiator. Common examples include screen resolution and fuel consumption/battery life—high resolution and battery life would be great; low resolution and battery life would be unacceptable. 

Lastly, Delighters are features that provide a key competitive advantage and make up your Unique Value Proposition. They are novel features that people want to show their friends. Every phone needs a screen, but a really high-quality screen can be a major selling point. For instance, color, high-definition, touch, ultra-HD, and foldable screens have been delighter features at one point or another over the last 20 years. But screens also demonstrate how delighter features drift towards basic over time: the even ultra-HD is pretty much a given on modern mobile phones, leaving folding screens as the only one that people might want to show off to their friends. 

MVP Feature Prioritization takeaways

Each of the methods has its own use-cases and pros and cons.

• Features prioritization frameworks help design teams know what to include in the MVP.
• For smaller teams with lower budgets, MoSCoW might be the best option.
• Features Priority Matrix accounts for effort and can be used to manage stakeholder relationships.
• Story Mapping groups features according to User Journey, providing a big picture of your product.
• Kano accounts for cost plotted against satisfaction.

Features prioritization is a key part of Windmill’s product design, development and strategy services. Find out how Windmill can bring your ideas to life.

Bio: Yuliia Kharkhota is a Senior Designer at Windmill. Qualified in UX discovery and synthesizing research results, Yuliia earned her stripes working on product start-ups in e-commerce and healthcare. Since the start of 2020, she has been part of a Windmill design team working on developing new fintech products.