Some of the biggest startups started as MVPs: DropBox started life as a product demo video on Digg and Groupon started as WordPress blog. I wrote about how some of our pre-seed investments also started out life as MVPs here.
At Forward Partners, we like to think of a good MVP as the least you need to build to deliver value to the customers your product serves. A good MVP can almost be thought of as your product’s spine -- giving a solid core foundation for the form and function to follow.
Let’s run through some of the big Do’s and Don’ts of building an MVP.
DO be sure there’s a problem
Building a solution must start with a problem to solve and to build the right solution, we need to understand the right problem we’re trying to solve first.
CB Insights have an excellent report breaking down the top 20 reasons why startups fail and the #1 reason at 42% was “No Market Need” - solving the wrong problem. Scary stuff.
“I realized, essentially, that we had no customers because no one was really interested in the model we were pitching. Doctors want more patients, not an efficient office.”
We start by doing everything we can to understand the problem before we build any solution.
We use the Lean Canvas framework to identify what we know and don’t know in all the areas that we should assess an idea by;
We carry out 30+ Timeline Interviews to gather unbiased insight into the problem;
We develop Personas to reach a shared understanding of our target customer;
We run Design Sprints to shortcut to learning without building and launching.
As innovators, we often fall into the trap of starting with a solution in mind to a problem we believe exists. If we’re not careful, this preconceived solution clouds our vision and it quickly becomes the product we build and offer to customers.
This is dangerous as customers are looking for something that addresses their needs and we rarely get their needs right the first time around. As the saying goes, if we start out with a hammer, everything starts looking like a nail.
Do test your assumptions
At the earliest stages, your product may just be a bunch of ideas, hypotheses and assumptions. Making assumptions is a good thing, they allow progress even with uncertainty. And, as you test assumptions, you will prove them either valid or invalid.
You’ll likely want to start by testing your riskiest assumptions like “does anyone actually care enough about this problem?” and prove to yourself that this is a problem worth solving.
Over time you will gain a clearer understanding of your value proposition and the potential product solutions before you start building any product. However, if you jump the gun and build too early with many unvalidated assumptions, you are in danger of trying to solve the wrong problem or building the wrong solution.
We do what we can to better understand the problem and validate assumptions to gain enough confidence in a potential solution before we start building.
DON’T cut quality in favour of features
After attempting to understand the problem and our target customer, we now know what features they want and we’re ready to start building.
But we must remember that often MVPs do not need to be complex, and indeed, it’s surprising how minimal an MVP can be. And identifying what to include in your MVP is not easy.
So, what features should we build?
Oftentimes, I have seen stakeholders choose to cut the quality of work in favour of additional scope -- and this rarely works out. Customers are normally happy to use a product that doesn’t do everything else that they want but they are not happy to use a product that doesn’t solve their core needs or solves them badly. We must start by delivering an MVP made up of features that address their core needs exceptionally well.
DON’T try to address all the edge cases
We’ve built a high quality MVP that addresses the core needs of our target customers, but during the build we found that the user journey doesn’t work in one particular case. Do we need to solve these issues in the MVP before launch?
We refer to these cases as edge cases, which is just a nice way to describe the things you missed when you came up with a solution the first time around.
There will always be edge cases and an MVP is allowed to break when it hits them. After all, it is not a mature product and these are exceptional circumstances.
In Software development we often misquote Donald Knuth here and say that:
“Premature optimisation is the root of all evil”.
The same applies to your MVP. If we attempt to discover all of these edge cases, inefficiencies and problems ahead of time, then we would spend a lot more time developing and a lot less time learning and iterating.
That is not to say you should completely ignore these edge cases when you discover them. Capture them and acknowledge that you’ve decided to ignore them for now. You will likely need to address them at some point in the future -- but crucially, not right now.
What you’re not allowed to be is unresponsive or worse still, unaware of these problems when they do happen and affect your customers.
DON’T Ignore the Feedback loop
Once we’ve released our high quality MVP, I guess we should move on to building more features?
A core component of the Lean Startup MVP process is the Build-Measure-Learn feedback loop. First we figure out the problem, next we develop a hypothesis to test the solution and build it, we then measure how well it performs and learn what does and does not work, finally we develop a new hypothesis based on our learnings and repeat. If we forget to measure and learn, it defeats the main purpose of releasing an MVP.
At the earliest stage, due to a lack of users, measuring and learning will mainly be gleaned from qualitative feedback, both formally and informally. Do customer interviews, organise user tests, add live chat to your site, systematically capture feedback from support enquiries, periodically collect NPS. Through developing a deep understanding of your customers, you will be more likely to develop a product that truly resonates with your customers.
With these core tenets, you will be able to get a long way through your product feedback loop and take steps towards product-market fit. And that’s the real tricky part here -- ensuring you get far enough through this process to hit on something genuinely useful for your customer before you run out of runway.
We think every startup deserves the chance to get there, and we hope you found this useful.