Quibi was the biggest video streaming app you’ve (probably) never heard of. They folded within 6 months of their April 2020 launch, losing investors $1.4 billion. You may not have $1.4 billion to lose. Even so, there’s a valuable lesson here.
Consumers didn’t care about having content that could be watched in portrait or landscape. If Quibi had instead built a minimum viable product (MVP) with only the features and content needed to test their core idea, they could have saved a ton of time and money.
It can be hard to draw the line between which features need to be in your MVP and which should be put off for future releases. I’ve put together two short case studies which show how you can make the right choices about what makes it into your MVP features list.
What do you need to solve the problem?
“The first step [in developing an MVP] is figuring out the problem that needs to be solved”
Eric Ries, The Lean Startup Principles
First, talk to your target users and understand what problem your product would be solving for them. Then for each feature, ask yourself: “is this feature necessary for the product to solve the user’s problem?” Your MVP should only include features that are needed for solving that problem.
If you’re unsure whether a feature is needed to solve a problem, it may be a sign that you need to have more conversations with your target users and better understand their needs.
Airbnb are a great example. Their MVP launched with the bare minimum list of features needed to solve their target user’s problem.
Problem: booking affordable accommodation is time-consuming.
Every feature in their MVP was necessary to solve this problem. They released their MVP, proved their idea solved the problem and that there was demand for it.
Only then did they add features which improved their product. After all, giving users the ability to filter on properties with pools would be irrelevant if nobody wanted to book accommodation in a stranger’s home.
You need to take a similarly clear view of your features to separate the ‘must-have’ from the ‘nice-to-have’. You can only do this well if you fully understand your users and the problem you are solving for them.
What about my competitor’s features?
If you’re entering a competitive market, you should include the features you need to set yourself apart. If your bet is that you can grab market share with one or more differentiating features, your MVP needs to validate the value of those features with real users.
Aiming for feature parity with competitors isn’t a good use of your time. Why? If the feature(s) which differentiate you from competitors aren’t a hit with users, cloning their other features won’t help you.
I’m not suggesting you shouldn’t include any features your competitors have. Only that you shouldn’t add a feature to your MVP purely to achieve feature parity.
Snapchat are a great example. Their MVP didn’t include features such as captions or filters which competing products like Instagram had. They just had one feature: send disappearing photos. Once they proved users loved it, then they looked at other features they could add to delight users.
What if my MVP disappoints my early users?
Yes, if you’ve done your MVP right you will probably have some unimpressed early users. You may even lose a few. So what? Either:
A) your MVP validates your assumptions. In which case you can make improvements and achieve better retention with your next cohort of users.
B) your MVP isn’t solving the problem for users. You pivot or scrap the idea and move on to something else.
You’ll either fast-track to knowing you have a real opportunity or you’ll avoid months of wasted effort. Win-win.
“If you’re not embarrassed by the first version of your product, you’ve launched too late.”Reid Hoffman, LinkedIn Co-founder
Your MVP should have the smallest useful feature set it needs to deliver value to your users and differentiate your product from competitors. Speaking to your target users will help you understand their problem and what features are needed to solve it.
As the examples above show, the best MVPs err on the side of simplicity. So if you’re spending a lot of time debating whether a feature should be in your MVP, it probably doesn’t need to be in there.
Most of your learning will happen once you get your MVP into the hands of real users. Limit the feature set so you can release sooner and get straight to that learning!