MVP Feature Selection: Scope Planning for Startups

MVP scope planning happens at two levels: higher-level and day-to-day techniques. First, the MVP scope depends on the type of MVP development. There are:

1. Fixed-budget MVP, where a founder or a small team develops an app with a lean & limited budget.
2. Discovery-driven MVP, where a startup or corporate department focuses on developing an innovative product.
3. Funding-constrained MVPs, such as in industries like healthcare, IoT, govtech, fintech, etc, where MVP development serves as a proof of concept and aims for larger investment rounds to build a fully-fledged product and scale. 

These MVP Development types differ in priorities when it comes to defining the scope. 

Once the bigger goals and constraints are known, startups utilize MVP feature prioritization techniques. They guide the day-to-day decisions of whether to include the feature in the roadmap or not. There are many of those, and in this article, we’ll talk about the most popular ones. 

For instance, the Feature Prioritization Matrix is the backbone of Amazon’s internal prioritization culture. Other techniques include Feature Buckets, Kano Model, Numerical Assignment, and User Story Mapping. Keep on reading to learn:

• which one helps to avoid critical UX mistakes,
• which one is ideal for a discovery-driven MVP and easily narrows the scope to core MVP features, and 
• which one or ones are great for metric-driven startups.

MVP Scope Planning for Three Major MVP Types

MVPs are not created the same way. In practice, there are fundamental differences in how teams approach MVP scope planning. 

• For some, constraints are budget and time-to-market, 
• for others, learning drives their development, 
• and finally, some shape their MVP roadmap milestones around funding rounds and regulatory compliance. 

Before looking into prioritization methods like Kano or Numerical Assignment, it is vital to understand the key business objectives. 

Fixed Budget MVPs 

Let’s start with a scenario. A small team consisting of a founder or a small team decides to launch a local cleaning services marketplace. They might have a budget for development of $10k to $15k. The startup team will focus on the product side of things while sourcing an MVP development agency to build the marketplace app. They also need to launch within 6 to 8 weeks. 

At the start of development, a startup defines and the development agency jots down ‘candidate features’. That will always include the value layer and the learning layer (analytics, tracking on pricing, and usability testing). At this moment, MVP scope planning generally gets cut to fit the budget first across both value and feedback features. To implement feedback loops, you can check out our article on tracking real usage patterns.

Then, further pivoting and changes are done utilizing one of the MVP feature prioritization frameworks, but still within the budget. The MVP development agency works in sprints, usually – weekly. Every Friday, for example, there is a demo of work in progress. MVP learning happens when the startup team gives feedback and adds revisions. In addition, they might choose to test some of the work in progress with real users and add, change or remove MVP features based on that, too. 

As a result, while having the fixed budget and timeline, MVP follows its original meaning – the learning and assumptions testing happen; the development is not fixed, and changes based on the feedback are introduced. It is also user-centered: work in progress is delivered weekly. So,  a startup can test and retest flows and request changes based on their findings. The MVP also foresees gathering analytics to inform further decision-making. 

Scope Planning for Discovery-Driven MVPs

Here too, let’s imagine a scenario, from the public sector, for instance. An NGO, in collaboration with city representatives, wants to tackle the problem of urban waste management in an innovative way. They hire the MVP development agency for a more open-ended discovery-based MVP project. 

This type of MVP development is likely to have an extensive user research stage. The development agency and stakeholders will do in-person interviews with residents of the city, maybe do some observations, and pull statistical data. There is likely to be affinity mapping sessions to make sense of all that qualitative data. At this stage, combined efforts will outline several possible ideas of what to build. These can be:

• recycling app,
• scheduling tool,
• gamified tracker.

Each of the options targets different user behaviors. The first one assumes that users do not know which items are recyclable and how to do that. The scheduling tool assumes the problem is in the logistics of things. Finally, the last one seeks the problem in people’s motivation. 

So, initial MVP scope planning is rather uncertain. It gets defined throughout the research phase. Once the startup decides which assumption is most important and impactful, they proceed to day-to-day MVP prioritization techniques.

It is likely that the development scope might be larger and the frequency of user testing higher than the fixed budget MVP above. Still, it will be hard to measure or test anything in a bloated app. So, the MVP scope needs to be narrow to ensure clarity of insight and to correctly test the value of the solution. 

Funding-Constrained MVPs

Here, let’s draw a scenario from the healthcare industry. A group of doctors decides to build a healthcare app to monitor a chronic condition for a clinical pilot. The initial financial funding starts out with:

• research grants, 
• government initiatives like SBIR, 
• medical angel investors, or 
• in collaboration with pharmaceutical companies (if this is an app for a drug or device). 

When the clinical pilot is successful, the startup team of doctors plans to get a new major round of funding. While it assumes app rework, it is mainly targeting integration, and higher compliance and security considerations. So, the initial pilot app still has to be reliable, data-backed, and compliant enough to even be considered for scaling in the medical field. 

Two major questions will define MVP planning right off the bat:

• What requirements should the app meet to be eligible for larger funding?
• What data points should the small-scale clinical pilot reliably gather?

These two questions will determine the ‘candidate’ features. While MVP feature prioritization still applies, there will be quite a few non-negotiables. 

In less regulated sectors, the type of MVP development also occurs in startups that adopt a milestone-based approach. These are for those who consider IPO, acquisition, or are preparing for larger funding. In terms of examples, it can be B2B SaaS with proprietary AI/ML algorithms, an open-world or high-fidelity gaming project, an AI-heavy video editing platform, etc. The uniting factor is that external requirements shape MVP planning at the outset.   

MVP Feature Prioritization Techniques

After the higher-level MVP scope planning, there are several techniques that manage day-to-day MVP feature decisions. 

Feature Priority Matrix

Every MVP feature gets two criteria:

• How much value will it add?
• How much effort will it take?

Based on these two questions, every MVP feature goes into one of the 4 quadrants:

1. Low value, high effort – generally considered a waste of time. For instance, in our cleaning services marketplace example, this can be: ‘real-time provider availability’ feature. It is complex in implementation, but gives very little value for the users and the MVP learning.
2. High value, high effort – these would be nice-to-have features. For instance, in our medical MVP scenario, real-time alerts for abnormal patient data is exactly the feature. It adds great value to the product by increasing patient safety and giving doctors the opportunity to respond timely to changes in patients’ health indicators. However, it will require complex logic, certain reliability adherence, considerations for edge cases, and possibly compliance.
3. High value, low effort – these are the backbone features in the MVP. In our cleaning services marketplace, this is a booking form. It supports core user action and is pretty easy to implement – simple standard form and a backend endpoint.
4. Low value, low effort – this is something the product can have. Features here are often the history of bookings or orders. For MVP, it does not really change the core behavior, but it may make sense to implement later on.

This prioritization framework is quite popular. In fact, it is the core of Amazon’s internal prioritization culture. Whenever they consider any new projects, this matrix is the way they map ‘high-impact, low-complexity wins’ to reach the highest ROI and tangible benefits. 

Feature Buckets

This MVP feature prioritization technique gets its popularity because it does not require a thorough evaluation of every MVP feature, and allows for a balanced approach. For instance, startup founders can decide to spend defined proportions of the budget on each bucket, which will create a balanced product roadmap. 

A startup can use the traditional ‘buckets’, such as features that are:

• Metric movers, 
• Customer requests,
• Delights.

However, startups often create purpose-oriented buckets as well, such as:

• Metric-specific: conversion drivers, engagement boosters, etc.
• Supporting features,
• Analytics tools,
• Compliance-critical, etc.

The one potential drawback of MVP scope planning with this prioritization technique is that startups tend to overvalue certain buckets. For instance, budget-constrained MVPs will tend to focus on metric movers. Discovery-driven MVPs might overvalue customer requests or observation tools. Finally, funding-constrained startups will put too great an emphasis on future bets or strategic features.

Kano Model

Similar to how a feature prioritization matrix works, this model is also about a 2-axis setup and visual representation. Unlike the feature prioritization matrix that prioritizes startups’ effort, the Kano model focuses on user satisfaction, expectations, and perceptions. Moreover, the Kano model is non-linear. As such, according to the Kano model, even if the feature does not add to user excitement, but it is a basic feature that will erode customer trust, it must be implemented. In contrast, in a feature prioritization matrix, such a feature might be cut due to high effort or low value.

The Kano model is probably the most go-to MVP scope planning technique for Discovery-driven MVPs. This model helps to avoid critical UX mistakes and is quite user-centered.

Numerical Assignment

This one is great for facilitating team discussions and reasoning. There are usually multiple criteria, such as:

• value, 
• effort, 
• risk, and 
• confidence. 

Often, for a budget-constrained MVP, you can discard the risk criterion and use the 3 remaining ones. Similarly, for funding-driven MVPs, you can add a 5th criterion – evidence impact.

Basically, the team assigns each MVP feature a score from 1 to 5. The discussion happens when one person rates a criterion as 2 and someone else as 5. It fosters collaboration and brings everyone on the same page when it comes to implementation. 

For instance, for our healthcare scenario above, let’s break down an MVP feature such as ‘AI-enabled recommendations’:

• Value: 4 – It is a high score, but not 5. The maximum score would be given to a core feature. This MVP aims to validate the assumption that patients will submit their data on chronic disease, and doctors will act on it. However, it can potentially be a product differentiator and contributor to longer-term success. 
• Effort: 5  – very high. In healthcare, AI is generally more complex due to testing requirements, data modelling, and validation of outputs.
• Confidence: 1 – there is little prior validation and trust, there is no reliable way to know if doctors will rely on it, and how patients will perceive it over time.
• Risk: 5 – AI medical recommendations have legal implications, and the downside of failure is potentially harmful. Risk can be lowered only via medical studies.  
• Evidence impact: 2 – not high. This feature does not prove the basic assumptions, which is what investors will want. However, creating an AI-powered app might contribute to a long-term vision for investors as well as investor storytelling.

An overall verdict is that this MVP feature will be cut from the scope at this stage of product development. 

User Story Mapping

While all previous MVP feature prioritization techniques work with feature lists, this one is qualitatively different. It shifts the view from the list to a user narrative. The MVP feature accompanies the user behavior in the completion of the core task. 

In the scenario of an NGO initiative for a waste management app, let’s assume the team chooses to go with the option of a recycling app. So, the team asks, “What is the user journey when recycling an item?” By answering this question, the team gets a list of activities:

1. Realize the need (not inside an app, a user finishes a product and needs to recycle it).
2. Identify the item in the system (MVP feature options: barcode scanning, manual search, image recognition).
3. Understand the recycling option (MVP feature options: instructions, category labels, explanations).
4. Recycling location (map, directions).
5. Disposal complete (‘mark as recycled’).

This provides a core and minimal list of features for the MVP. The team can add feedback loops or community features. However, there will always be a clear view of the core user journey and connected MVP features, which is perfect for MVP scope planning.

FAQ: MVP Feature Selection: Scope Planning for Startups