How To Do MVPs Right!
Minimum Viable Products Made Easy.
Originally posted on How To Hatch — A Guideline For Entrepreneurs.
You think that it needs to be a lengthy process from idea in your head to shipping your first product? Surprise! It’s closer than you think.
We have all been there before — Once you’ve identified that world-changing business idea, you start asking yourself: How should you start start building it? How do you go about finding out what the first version should look like? What should you prioritize and build first, and what can wait until later?
Developing a Minimum Viable Product (MVP) can answer a lot of these questions for you. It’s a great way to kick off your startup’s journey, which is why we want to share our experience with you and show how you can use this method, too.
What is an MVP?
A Minimum Viable Product is the smallest thing you can build to deliver the value of your solution to your customers.
The idea is pretty simple:
- Build the minimum set of features that is viable enough to test your key assumptions.
- Learn more about your customers and the problem you want to solve.
In other words — it´s a version of your product, stripped down to the most essential features, that allows you to collect the maximum amount of validated learning with the least amount of effort. Sounds easy, right? The bad news is that it’s actually a bit more tricky to build your MVP than meets the eye. But totally worth it!
As simple as it may sounds in theory, building an MVP is an experimental method aimed to discover the right approach to successfully design your product and business. Experiments always come with a huge number of variables, different results, and failure. Therefore it’s hardly surprising that so many people have varying opinions and experiences.
What an MVP is Not!
We have seen a lot of discussions recently on how different people define MVPs, and quite frankly, it’s annoyed us. Way too often, people use the term MVP as an excuse to build crappy, non-functional products. For example landing pages with a big orange button on it, yelling ‘Sign up for beta’.
No … Just, no. Stop it. Let’s step into the kitchen for a moment. You have to let your customers taste, not just smell what you’ve cooked. MVPs should always be viable to your customers. Only then can you legitimately call them MVPs. We’ll go into some good examples of this later on.
Landing pages, videos or interviews are so called Vanity MVPs or smoke tests. They are useful in helping you to identify the existence of a problem; but they won’t help you learn much about your solution. What’s the difference between a smoke test and an MVP? Let’s break it down a little more — This is how we see the lean startup approach of starting a business:
1.) Validate the problem
Before we do anything else, we first need to check that the problem we want to solve really exists for a certain group. We also want to figure out if there could be a way to solve it. This is the right time for customer interviews and smoke tests.
2.) Validate your solution
The MVP is our tool of choice for this step. We’ve already determined that the problem exists and is experienced by a group of people. Now we want to test our Problem-Solution Hypothesis to learn as much as possible about our customers and their pain.
3.) Build — Measure — Learn
After you know that you are on the right track with your solution, it is time to create the product your customers will love. To get there, you’ll need a steady cycle of adding new parts to the solution, asking customers for feedback, and learning from that feedback.
Just a note before we dig deeper. MVP’s are not the only approach to product development. And having an MVP is not like finding the holy grail of startup success. But, we think they are one of the best ways to kick off your startup. Let’s get into some actionable steps you can apply to transform your business idea into an MVP.
Step 1: Find your riskiest assumptions
Every startup is based on a set of assumptions about its customers, its product, the implementation of the product, and its market. The validity of these assumption is the Achilles’ heel of your business, and crucial for its success.
In the following example, we illustrate how to identify these assumptions and deduce which are the riskiest ones.
Example: Let’s say you’ve discovered that many dog owners struggle to find time to take their furry friends on regular walks. You hypothesize that it may be because they’re working long hours or are just too busy. You already have validated this problem by talking to dog owners and gathering a lot of feedback. Based on that feedback, you had a first idea on how to solve their problem. Your Problem-Solution-Hypothesis could look like this:
“By creating an online platform, we will help dog owners to find the perfect dog sitter nearby.“
What do you assume?
Your first step is to write down all the assumptions about your solution that you can think of. What do you assume about:
- Your customers: Where do you find your customers? Is your target group big enough?
- Your solution: Will your solution solve your customers’ problem?
- Your competitors: Who else is providing a solution to this problem?
- Sales channels: How will you sell your product/service?
- Your pricing: How much are your customers willing to pay and how much do you need to make to be profitable?
- The implementation: Are you able to actually build the product? Do you have the right resources?
Start brainstorming with your team, your advisors, and anybody else who could bring in valuable ideas. We write all ideas down on sticky notes, trying to build sentences like:
- “Dog owners will trust people they meet online to walk their dogs.”
- “Dog owners are willing to pay $25/hour to have their dogs walked.”
- “Dog sitters are willing to offer their services on our online platform.”
- “Dog owners will prefer to use our service rather than searching for dog sitters in the Yellow Pages.”
How to identify your riskiest assumption
Now, that we’ve found some assumptions, it’s time to identify the riskiest ones. But how do we make that determination?
Risk = Probability x Impact
Risk is a product of two factors:
- How big is the impact of the event?
- How possible is it to happen?
This will help us to filter not only which assumptions will cause our idea/business to fail (impact), but also what is more likely to happen (probability).
In this post by Diana Kander, you can find a very simple method to calculate the risks for each of your assumptions. It combines your confidence in the assumption with the impact of being wrong to get an overall risk score. In our example, it could look like this:
Of course, this isn’t a scientific method to calculate your risks. The evaluation of your assumptions is still based on your gut feeling and your experiences. But it still helps you to add clarity to your assumptions.
Step 2: Build your experiment
You should always test your riskiest assumption first.
The most frequent question asked about building an MVP is “What do I need to build to deliver a viable solution?” Focusing on your riskiest assumptions will give you a much clearer picture on what really matters. It’s worth mentioning that ‘build’ does not always need to mean ‘code’. There are tons of different ways to produce a viable solution without writing a single line of code. For instance:
The “Wizard of Oz” MVP
Your MVP looks like the real working product, but it’s just a storefront. With the “Wizard of Oz” approach, you manually handle all functions in the background to make your product appear automated.
Case Study — Zappos
Instead of building a fully automated eCommerce platform, the founder wanted to test if people would buy shoes online. He went out, took photos in a local shoe store, and posted them online. Once the first sales came, in he bought the shoes in the same shop to ship them to his customers.
The “Concierge” MVP
You manually perform tasks related to delivering the value of your product or service. Sure, you can offer your service on a website, but all functions of the product are emulated manually.
Case Study — Food on the Table
Before building anything, the founders of Food on The Table, a service providing weekly recipes based on sales at customer’s local grocery stores, went to local markets to interview consumers. The first people interested in the service got a concierge treatment. The founders visited them at home every week to create custom recipes together. This way, they learned a lot about their product and validated their assumption that people would pay for the service.
The “Piecemeal” MVP
Rather than investing time and money into building your own solution, the “Piecemeal” is built upon existing infrastructures. You put together a functioning demo of your product using existing tools and services to deliver the experience and steps your customers would go through.
Case Study — Groupon
The founder, Andrew Mason founded Groupon by setting up a WordPress site where he posted deals manually, each day. He used AppleScript to generate PDFs as orders were received and emailed them via Apple Mail. All the work was being done manually with the help of third-party resources.
In the case of the dog-sitting platform, we could go with the “Wizard of Oz” MVP because we already know that people pay for dog-sitting services, but we don’t know if they will also do it online.
To test our riskiest assumption, we could set up a simple landing page where users can select their city and book a dog sitter. To handle the bookings, we don’t need to start coding a complex back-end system. This could easily be handled manually by calling dog sitters directly after a dog owner contacted us via the landing page.
Tips for building MVPs
To build your MVP, there are some important things you should keep in mind. Within the process of creating your own MVP, you will recognize pretty fast how hard it is to focus on the important stuff. As soon as your euphoria enters the equation, your brain starts to lure you away from your focal point with tons of ideas, pipe dreams, worries, and fears. The following tips will help you to stay on track:
Use existing frameworks!
There is no need to reinvent the wheel. You’ll find plenty of existing resources to keep efforts low. You could bootstrap your development, use Software as a Serivce (SaaS) tools such as FastBill or Stripe for automated billing and payments, or Userlike for customer support.
There are hundreds of tools out there for nearly anything you need. To get a wider view, check out the start-up toolkit collection on Product Hunt.
Don’t lose yourself in details!
Don’t fall into the trap of waiting until your product is nice and shiny. Your instinct will probably tell you to add “just one more feature” or rethink the design “just one more time”. Get it out of the building; the niceties can be added later. Don’t let perfect thinking be the enemy of a good product.
Don’t screw up your first impression!
Launching early is vital, but don’t forget the all-important first impression. Finding the right balance between those two is probably the hardest part. Your product’s design has a big impact on how likely your users are to use it or not. Today, having the right set of features is not enough. It’s about creating an experience.
With this in mind, you are on a good track to build a product that really matters to your customers. We hope our thoughts on MVPs and the lessons we’ve learned (sometimes the hard way), will help you to improve how you build your products. We’d love to hear your thoughts on MVPs and what has worked for you so far.