How to decide what features should be in MVP? [closed]

Question

Is there any technique to make a decision whether to include the feature in MVP or not?

Answer 1

I use MoSCoW prioritisation with clients (Must, Should, Could, Won't) and build developments around that. If the client would cancel the release if 'X' feature wasn't delivered, or if there is no workaround, then 'X' feature is a must.

Therefore the MVP is then defined by the list of 'Musts' in the prioritisation.

Answer 2

In order to reduce waste and build an efficient MVP, you want to attack outcome they value the most. Something that important but they aren’t satisfied yet with current solution. This is how you filter down what matters and what is not before allocate more resources to actually build the thing. There is no point to solve / test something they already satisfied with or something that they feel not important. You don't want to waste your time, budget and resource.

Example.

Let’s say you want to solve a job of “Get a ride to my destination”

1. Talk to people and draw Customer Value model to Map their current process.
2. Talk to people, analyze and define specific unit of measurement that they value.

3. Throw survey / interview ask people to rate each unit of measurement by importance and satisfaction using a scale 1 to 5. (1 means not important / satisfied while 5 is totally important / satisfied.
4. Use Opportunity Algorithm to discover the most important outcome but they are not satisfied yet.

**

Opportunity = importance + max (Importance-Satisfaction,0)

**

Result:

How to read this result?

For outcome #1, 90% of those interviewed rated 4 or 5 on the importance of outcome and only 40% of them are satisfied (rated 4 or 5) with current solution. Resulting in 14.0 opportunity score. Otherwise for outcome #2—they see it as something that not really important but actually already well served with current solution. You don't want to focus on #2 for now. As for #3, it has the highest opportunity score. It means, to "Minimize the chance of my ride to arrive in wrong location" is highly important for them but they are not really satisfied with current solution. This is your opportunity—thus, you have to include solution for it in your MVP. You could have hundreds of outcome, this technique help you prioritise them.

Answer 3

The simplest way to determine the feature set of an MVP is by asking yourself of EVERY feature, "is this required in order to provide the minimum amount of value to the end user?". The whole concept of MVP is to get something out as quickly as possible to start validating your hypotheses by learning with real user data. Therefore you should only include the MOST minimum amount of things that are required to validate those hypotheses. Anything additional you include will delay the amount of time it takes to prove or disprove your hypotheses and therefore could be wasted time.

If you are trying to make a decision about MVP features and you don't yet know what overall hypotheses you are trying to prove or disprove with your MVP then you are already doomed to choose the MVP feature set based on personal opinion, consensus and whoever has the loudest voice. So you need to ensure you are starting with a clear idea of what are the goal learnings of the MVP before you can do anything else.

It's hard to be rigorous about MVP decisions - especially with clients & stakeholders who are almost always going to fall on the side of "yes that's required" - but it's the best way to ensure you make the most of you & your engineers time in the long-run by building products that are based in reality rather than based on you and your teams assumptions of reality.

Answer 4

Generally the way to determine a MVP would be to sit down with the Client and put together a list of the requirements. Once the list is gathered, it is best to then rank them based on priority.

There are many methods to do this, assigning numbers (1-10, 1-100), MOSCOW, Fibonacci etc. it depends on the client as to what they prefer.

I would then examine the top priority requirements and determine their dependencies, and then go from there.

Answer 5

Quite tricky question given that MVP depends on what users might like or not in a product which does not exist yet. We are playing with the future, that is, we do not have hard data at the moment to base our decision on.

In that case, we could research case studies of the past, closest to your value proposition intentions. Let's say you are after an MVP for a flying car. You must ask yourself: what similar product developments have we seen in the past in terms of target audience, industry, projected price, positioning, presumed innovation adoption curve, etc?

Once you come up with a few suggestions, you can start thinking about them "back in time" - if you were to develop them back in time (with your present knowledge about them), what would you strip away so as to reach the basic stage of an MVP?

Such speculations would not give you a straightforward answer, but they might inspire your creativity on the subject.

Other than that, strive to make your MVP as flexible to modify as possible. This would allow you to respond to market feedback. Mind you this is counter-intuitive - usually by MVP we understand a stripped-down version (which also means cheapest one) and not most flexible one (which may come quite expensive).