Proven Need

Reading Time Time to read: 5 minutes

The Do’s and Don’ts of building your MVP

Martin Sanders

Full-Stack Developer

In the Startup world we’ve been obsessed with the idea of building Minimum Viable Products (MVPs) ever since Eric Ries popularised the approach back in 2008.

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.”

-Patient Communicator

We start by doing everything we can to understand the problem before we build any solution.

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.

To conclude

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.

Martin Sanders

Full-Stack Developer

Martin is a full stack developer who helps build the right product. He has a passion for development best practices, lean solutions and user-focused products. His background is working with digital media and Fast Moving Consumer Goods (FMCG) brands. When Martin is not at work he likes long walks on the beach and other cliches.

Apply for Office Hours

We’re looking for great entrepreneurs with great ideas.

Apply here

Similar Guides