How many features are you planning for your app or website?
Whether you’re planning only 2-3, or as many as 23 the chances are that if you don’t find the one killer feature that will make it stand on its own then it’s likely to fail. Building a Minimum Viable Product (MVP) is one way of helping you learn what that feature is, as quickly, cheaply and efficiently as possible.
What is a Minimum Viable Product?
Within product design it’s a strategy and development technique where, having done your customer research, you then move on to building the most pared down version of your product that can still deliver enough value to its users.
An MVP has three key characteristics:
- It has enough value that people are willing to use it or buy it initially
- It demonstrates enough benefit to retain those early users (aka early adopters)
- It provides a feedback loop to guide future development
In the words of startup guru Eric Ries:
“The minimum viable product is that product which has just those features and no more that allows you to ship a product that early adopters see and, at least some of whom resonate with, pay you money for, and start to give you feedback on”.
It Gets You Feedback, Fast
Within an iterative and user-centred design approach (like some of the Lab projects are doing), deciding to create an MVP is a strategy that can get you fast, quantitative feedback on your product before you build its next layer of features. The idea is useful because with it you can basically say, look, our vision is to build a product that solves this core problem for users and has these kind of general feature areas. By giving early adopters the core features that point in the direction you’re trying to go, it engages their vision and helps them to fill in the bits that aren’t quite there yet. This makes their feedback more specific, informed and practical.
The alternative is to build a product with the maximum number of features, on the basis that this will maximize your chance of success. However this won’t get you any feedback about whether you’re on the right track until it’s too late.
The Value of Simplicity
In their Signal To Noise blog 37 Signals points out the value of simplicity:
The key is to restate any hard problem that requires a lot of software into a simple problem that requires much less. You may not be solving exactly the same problem but that’s alright. Solving 80% of the original problem for 20% of the effort is a major win. The original problem is almost never so bad that it’s worth five times the effort to solve it.
Why is it a good idea to build an MVP if you’re building a product to solve social problems?
Mark Mitchell, Design Lead at Sidekick Studios (creators of innovative tech for good projects like Buddy, The Amazings and Sidekick School) talked to us about the value of building an MVP for one of their latest projects. For Mark it’s about making sure that you’re solving the right problem.
We’re quite fond of the phrase “Executing the wrong plan, flawlessly”. The point being, it’s easy to make a beautiful product that no one needs. It is important to discover early what users want and customers will pay for. When we started working with Inaura, it seemed that a list of alternative education providers would be useful for schools. However, during our research, those we interviewed did not express any pain points around student placements. Instead, they found it difficult to communicate and collaborate with other agencies around the progress of a student. This problem is what led us to the current product.
Why and how often should you iterate while building an MVP?
MVP can be seen as an iterative process of idea generation, prototyping, presentation, data collection, analysis and learning. Within this you seek to minimize the total time spent on an iteration. From Mark’s designer perspective
it’s about prioritising what’s needed. We ask these questions
- What is the minimum amount of design needed to satisfy the product’s users?
- How do we keep the MVP fundamentally usable but also open to feedback?
When we’ve developed the minimum number of features needed and gauged testers’ reaction to the experience of using it we can then iterate again. As we repeat this cycle the design’s growing complexity overwrites earlier iterative loops.
By taking this, quite scientific approach to design budgets are saved, informed and meaningful feedback is gathered and products develop into something that users are more likely to value and use, even if the product itself achieves different things or solves different problems to what might have initially been expected.
You can read more about Mark’s experience of building an MVP for Inaura here.
Examples of MVPs
Buddy App
Started as a radio mood monitoring and communication device. Hacked from bits of cheap radios. Although it failed enough people were prompted towards a new way of behaving and interacting and got the concept that they were able to tell Buddy’s deveopers what they wanted – a mobile app. The rest is Buddy’s history…
Zappos
Though it’s now the world’s biggest online shoe retailer it started life as just a website with pictures of shoes from local shoe shops. There was no stock. When a pair sold on the site its owner went to the shoe shop, purchased the pair over the counter and then shipped them to the customer. Though the product – an online shoe website – wasn’t sustainable in this form it told its owner what he needed to know about demand for a superior online shoe shopping experience
Dropbox
Started as a simple video. It gave early adopters a hint of the product experience. In fact, it was so good that some of those adopters were smart enough to be able to give them as good feedback as if they were using the product for real.
Started as a simple search engine. One feature. No frills. Even today it’s still quite minimal.
[…] different methods at different times – start with listening, then show them a Minimum Viable Product, then start to build and get immediate feedback from as many people as possible, then engage with […]