Why you shouldn't start with an MVP to validate your product idea

You have a problem worth solving and an idea on how to solve it, but you want to make sure you validate your idea first. You have heard of a Minimal Viable Product(MVP) to kickstart the build-measure-learn loop. But there is a catch. MVPs are great, but not the first thing you should do to test your idea. Hear me out.

Learning with MVPs is too slow and prone to bias

It's true - you will only know if something works when you put it in front of your users. But you often can't afford to invest weeks or months getting the MVP out, and only then learn if your idea works or not.

There is a time to go for the MVP. But going right to an MVP without prior testing can be costly and prone to fail due to flawed assumptions about your customer and market.

Going from idea to MVP right away comes with its risks:

• It usually still takes a couple of weeks to get to the desired learning.
• Teams usually only validate a single MVP at a time, risking confirmation bias.
• MVPs rarely get thrown away. You keep iterating without realizing that something underlying might be flawed.

It is possible to avoid these pitfalls and speed up your learning and feedback loops. What if you can test many solutions at the same time, to see which one performs best? What if you can already increase your confidence even before you start with coding your MVP?

Test your critical assumptions first

Start with testing your critical problem and solution assumptions first. Assumption tests allow you to limit the scope and yield faster learning loops.

• You can do multiple tests per week.
• You can and should test assumptions of multiple solutions at the same time
• If assumptions turn out to be false, it is much easier to throw away solutions than when you have already invested in an MVP.

Capture all types of assumptions and prioritize.

• Desirability Assumptions: Is the problem important enough? Does my target audience want the problem to be solved? Do they want the solution?
• Usability Assumptions: Can they use it? Can they adopt it?
• Feasibility Assumptions: Can we build it? Can we support it?
• Viability: Does it work for the business? What is the cost?

You don't have to test all assumptions. But you should capture them, identify the most critical - meaning the ones with the lowest confidence and highest importance - and test these. These are the ones if not true your business/product/feature is bound to fail and you need to adapt.

Run assumption tests

With your critical assumptions in hand, you can design small experiments to quickly test and learn about your assumptions. Assumption tests are usually cheaper and faster to execute than actually building an MVP version of a product or feature. They are the perfect tool for fast learning cycles. You can run multiple of these tests per week, giving you the learning needed to pick the best solution for your customers.

These tests can range from UX tests, landing page tests, customer interviews, to code prototypes, etc.

Prioritize speed of learning

You will never be able to remove uncertainty completely for any product or feature idea. By running smaller assumption tests before you commit to coding you can speed up your learnings cycles, de-risk, and drastically increase the likelihood for success of your MVP.

Next time you want to jump into coding, think about potential solutions, and start testing your critical assumption instead - quickly and nimbly. De-risk before you spend weeks building your MVP.