MVP: how to use it to learn faster avoiding mistakes?
Starting with an MVP (Minimum Viable Product) can help you learn faster from your users and save on the development costs. But what’s exactly an MVP? And how can you use it to speedily test a new business idea?
When launching a new product, it’s a common mistake for companies of all sizes to start building it too soon. This way a lot of resources go into something that hasn’t been fully tested. Or, even worse, often teams stop testing after the launch.
Your product launch has one main purpose: to test and learn how your idea performs once it’s live. To start testing as soon as possible, what you want to do is to launch a Minimum Viable Products (MVP).
So what’s a Minimum Viable Product?
An MVP is the minimum set of features needed to solve your users’ problem. With an MVP your users will be able to sufficiently solve the problem your product wants to address. Every user? Certainly not. Since an MVP is not optimized, it won’t be for everyone. Only for the ones with a problem big enough to be solved and with an open mindset. You’re looking for early adopters. Those are the users who are more open to help you with feedback in the initial phase.
An MVP is a working product that can be launched on the market, it’s not a prototype. But it will probably be very simple and offer minimum automation.
The essential function of an MVP is to allow for testing and learning. So it’s a good idea you build a feedback loop within your product.
Why is an MVP not a prototype?
Also prototypes are designed to help you learn right? True. However, their purpose is not to address the needs of users. A prototype is to visualize solutions, but not to solve problems. The idea is to sketch it as rapidly as possible and get feedback on it. With a prototype you can test if an idea is feasible before you start developing it.
What both prototypes and MVPs have in common is that they’re a very good way to de-risk the launch of a new idea and reduce waste.
The most common mistake with MVPs
An MVP shouldn’t have too much. It is a minimum viable product. This means it should have the bare minimum to satisfy the needs of users and not more.
There are two risks when you build more than you need: first of all the risk of spending money developing things you won’t need. The second risk is that if users will like your product, you won’t know exactly what part of it they can’t do without.
How do you know if you’re building a Minimum Viable Product or if you’re building more than you actually need? Ask yourself: “Can I do with less?”. Can you still solve the main pain of your user building less? If that’s still possible, then you need to reduce the features of your MVP.
There will be time to introduce new features gradually and then ask users how they impact the value they receive from the product.
Why build an MVP: save on your development costs
The first reason to build an MVP is because it saves you money. When you launch a new product there’s inevitably things you’ll build and then have to throw away. The reasons can be many. It can be because users won’t need those features or because you’ll simply improve your product. Starting with an MVP reduces the cost of waste.
According to the data available, every euro spent in this phase saves 10 euro in the development phase.
So having a MVP gives you value if you use it to test and learn from users. This way you’ll avoid building features that users don’t really need.
Second advantage of an MVP: quick idea validation
Building an MVP is also the fastest way to validate the viability of a business idea. While you can’t ask people to pay for a prototype, you can ask to pay to use an MVP. After all, an MVP does solve a real problem.
Now, some will argue you can still ask to be paid for a pre-order (see Tesla). But to validate a business idea, getting paid upfront is not enough. What you need is recurring paying customers. Paying, because there’s no better form of validation than people who pay for what you offer. Recurring, because their experience needs to be satisfying enough that they’ll want to come back. And that’s not something you do with a pre-order.
Launching a product that people want to pay to use is what you need to validate your business idea. As said before, it won’t be for everyone. It will be for those early adopters who have a pain big enough to be solved. If their problem is big enough, they’ll look beyond the beautiful interface.
So where to start building a Minimum Viable Product?
Build your MVP in a way that allows for learning. Have a system to actively receive users’ feedback. The feedback flow shouldn’t be occasional. It’s an essential reason to have an MVP.
If you’re considering building an MVP it means you have already started researching your concept idea. Most likely you’ll have learned about your persona and the problem you’re trying to solve. Probably you’ll already have feedback from potential users about the solution you have in mind. What’s handy at this point is to dive deeper in the single features you want to build. Try to rank them and see if one could do without the other. You’ll have to apply a good mix of quantitative and qualitative research to understand what features are most important and why and also if one can work without the other.
When you’re confident you’ve found the minimum amount of features you need to start learning, then that’s where you can start building your MVP.
I’ve already written about how to ask feedback from users the right way. You’ll find the post here. Use those tips to decide what features to prioritize.