Getting MVP right
Why do most startups fail? One of the reasons is focusing on a wrong problem or lack of knowledge about the actual one. We need some tool that helps to study the problem space better and only then switch focus to building the final product. However, what usually happens is that the rear resources are spent on building the product, and only then learnings are collected. What is a better solution here is to utilize the MVP approach or a minimal viable product to collect validated learning.
Quite often MVP is associated with the first version of a final product built and delivered to customers. The misconception here is that MVP should not be treated as a product in its final form where half of the features are de-prioritized. MVP is more about establishing a repeatable process that helps to deliver value to customers and validate main product risks before any substantial investments.
Validated learning is the one purpose of MVP.
For example, instead of building a software piece that solves customer problems, focus on finding a way how to deliver services manually. This is not a scalable approach but gets you to the feedback from customers faster. Once you understand that users benefit from the service you provide and most important are ready to pay for it, you can start focusing on the product itself and how it can potentially evolve.
The goal of MVP is to gather feedback and iterate over it. It is not the first increment of your final product and can be completely different from the product you will end up building. The main goal behind MVP is to communicate the way you solve the problem to your target users and get some traction on it.
Product risks
Every product idea is followed by some risks that we should try to mitigate before starting any development effort. The most critical risks or unknowns are good candidates for applying MVP. But first, let’s see what are the main risks a product might have:
Feasibility
This relates mainly to the implementation risk or the evaluation of the product from a technical standpoint. However, this is one of the least important risks you might want to address at the beginning, as 90% of all the commercial products are more or less clear how to build, at least your engineers have had some similar cases before, otherwise we are in deep R&D projects.
Value and viability
These are the most important aspects to validate before you start. They indicate if you have customers ready to pay for the product you are offering. Value alone is not enough if you decided to do a commercial product, as commitment from users to pay is the best indicator of the problem they have. And we should not forget that the goal of almost every company is to become profitable at some time. You should not optimize monetization from the very beginning, but you should be sure, that later on the value your product delivers is sufficient enough to monetize.
Distribution
Also, one of the risks indicating you can efficiently reach your customers, sell and deliver your product to them.
The wrong approach is to focus on technical feasibility first. In the beginning, the way a product should look, which features it should have, and which technologies to use, are not that important. It is the easiest to start with as you are not supposed to interact with the customer because getting harsh feedback is hard, however, negative validation is also a result that your idea does not match the problem space well and needs to be iterated.
Early feedback and engagement with customers help you to validate value and viability risks. By talking to people and presenting your idea, asking questions, you can already understand if your idea solves a problem and if you have potential buyers. You will be able to evaluate the following questions:
- Does your product solve users’ problems, and if there is enough demand from their side?
- Are people ready to pay for it, and how much?
- What features do they want to get in your product?
The hardest part is to validate the market and if your product can deliver value and viability for your business. Business is built around the problems people are ready to pay. So, try to get deeper into these problems first and sell before you make.
Validation of product ideas
MVP is more about using the fewest time possible to validate a product idea and prove demand along with the ability to distribute your product. It is possible due to feedback loops you have built with your users. MVP helps you to build this feedback loop. Depending on the question you might have, there can be four types of MVP.
Group 1: Content-based MVPs
Applicable if you are validating if there is a real problem and would like to get an idea of your potential target audience in the early stage. It is one of the fastest ways to validate ideas and is a good choice for B2B products. For example, this can be content in blog posts, newsletters, free webinars on the topic related to your product.
Group 2: Demos
Help to prove demand for your product and also gather feedback from your target audience. You can rely on landing pages, demos, and doing presentations of your product idea to your customers. Also, crowdfunding campaigns are the approaches to gauge demand when you have no product in place.
Group 3: Prototypes
Help not only to validate your understanding of a problem but provide you with feedback on the way you are solving this problem. A couple of examples are click-dummies, paper prototypes, and any kinds of models that represent your product idea.
Group 4: Product imitation
A good choice for validation of your service value. It is also a good choice for B2B space. Some examples here are The Wizard of Oz and Concierge prototypes.
Two rules to keep in mind while building MVP:
- Your goal is not only to get feedback but also a commitment from your customers. It can be either signups or payment for your service or LOI if we are in B2B space. If you have proved demand and have a waitlist of hundreds of target users in the B2C space, and at least several LOIs in the B2B context, you can investing in building the first version of your product.
- You should timebox your validation period. Timebox your validation efforts. The whole thing about MVP is that the validation should happen fast, so impose a hard deadline.
Designing MVPs
How to start with MVP? Consider the following steps in the process:
- Who is your target customer?
Be focused and specific here. It is easier to target a niche, validate your assumptions within it, and then grow out from it.
- What is their problem?
The problem that you perceive as a problem might not be the same for your customers. Also, it is good to understand if this problem is worth solving.
- What is your value proposition for this target customer group that your future product can deliver?
- What is my riskiest assumption?
Understand your main potential risk here. Is it engagement from the user's side (value)? Is it possible to market and distribute the product (distribution)? Can you monetize your idea (viability)? Or is it some technological risk you might have (feasibility)?
- What experiment should I plan to test the riskiest assumption?
Here select the most appropriate type of MVP. It depends on the risks you have identified at the previous step:
- If the goal of your MVP is to learn more about the problem and get the first interested people, then you can use content-based prototypes: social media and posts or blogs, newsletters, any kind of webinar.
- If you try to understand if people will pay for your solution (viability), then you can try driving traffic to a landing page that communicates your value proposition or start a crowdfunding campaign.
- If you know that the problem is present and the user base is there, but are not sure about the way you should solve the problem, then you can pick up process-based prototypes — Wizard of Oz or Concierge. Even static prototypes can do their job here.
After designing MVP, test it with your target customers and get early feedback. Try to understand their goals. The intent here is to make them commit to your product. Commitment means show readiness to pay. It is necessary because just liking your product is not a commitment and indication of future usage. After all, business exists to be profitable, and you need to be sure that your efforts would have a chance to be paid out.
What can be the typical problems to avoid while designing MVP:
- You have an idea of the product and decide on which features should be in MVP. The right approach here is that MVP is about learning more about your problem space. Only if you know the specifics of the problem, you craft the solution the users will use on a repeatable basis (product-customer fit). MVP is not about the initial version of your product with the trimmed feature set.
- You plan just one MVP, and it is enough to have one experiment. The more diverse experiments you run to understand the problem space better, the more confident results you get.
- Validation of the obvious things. Only the riskiest and critical problems should be part of the validation and MVP process.
- No payment guarantee from your customers. Liking is not buying.
To sum up the main takeaways on MVP:
1. MVPs is more about the process that helps to validate:
- your product idea with real users and collect insights for your future product initiatives;
- your sales strategy, the way you attract your customers and deliver a product to them.
Apart from the strong validation focus, MVP allows you to test and get as much feedback as possible before writing a single line of code. It also serves the purpose of attracting your first users.
2. Keep the focus and start with the riskiest hypothesis and validate it. Remember that the less is more, and you should not validate all possible things in one go.
3. Do not focus on features to build. Start with delivering the maximum of value and the process of value delivery.
4. Try to get some commitment from your customers, and do not forget about readiness to pay.
