There are right ways and wrong ways to go about building your Minimum Viable Product (MVP). For example, some people think that it is about building a cheap, small-scale, version of the actual product.

It really isn’t.

If you’ve been following Lean Startup principles, the fundamental objective of MVPs is to help you acquire validated learning, which brings you closer to identifying a business model that can scale. The more you understand about the business model, the less risky your decision making and you can expend your resources more efficiently.

After all, that’s what being lean is about. It’s not about being cheap either, some of your later MVPs will be more expensive to test, and that’s okay if you are acquiring validated learning and using it to guide your next steps.

Step 1: Understand the Objective(s) of your MVP

At different stages of your startup, you should be looking at different objectives for your MVP (or MVPs when you are further along), each testing one or more hypotheses (covered in the next step).

For your first MVP, you are really looking to understand your customer audience, measure their interest to identify paths to them. You need answers to questions like ‘how many people are looking for product XYZ on Google’, ‘what are their pain points with alternative products (if any)’, ‘what will it take for them to switch’.

You really want to validate that the problem you are trying to solve actually exists. For your problem to exist, real people must acknowledge the pain it causes.

Contrast this to a later stage product, where we might have a problem that we’ve validated, and we now need to ask questions around the solution such as ‘does our product reduce your cost, or increase your happiness’, or perhaps ‘is this something that you would pay $30 monthly for’.

When you start taking money from your customers, you are doing validation for product-market fit. You are trying to find a path to your customer, and understand if the product that you’ve built, and the marketing that you do, is repeatable and scalable.

When you skip from validating the problem, straight to building the product, you lose out on validated learning. This is a problem because you may not know why your product fails, or worse still, why it succeeds.

Step 2: Formulate your Hypotheses

No one can tell for sure if a business idea would succeed. I for one would never have thought that a micro-blogging service with a 140-character limit would one day be worth billions (at least at one point). For most parts, Twitter’s early but meteoric rise to success was mostly luck. Twitter started off as fun project to hack on, and they were probably not setting out to solve specific pain problems on the scale that they do today.

One thing they did prove was that people needed a quicker way to communicate, 140 characters at a time. Other giants like Facebook, Dropbox, Zappos, Aardvark, all began with a simple MVP proving some of their core positioning.

It is recommended that you pick the most risky question you have about your business as your first hypotheses. Some times, this means answering a glaringly obvious aspect of your business that customers, investors, would be skeptical about.

Every great business is built around a secret that’s hidden from the outside. A great company is a conspiracy to change the world. 

- Peter Thiel, Zero to One

If you are in such a position, then according to Peter Thiel in his book, Zero to One, you’ve perhaps stumbled upon some undiscovered truth that no one else has latched on to yet, or don’t believe will work, which he calls a secret. For example, Elon Musk has his fair share of naysayers that didn’t believe in his ability to build electric cars or launch (and land) space shuttles more cost-effectively. However, his engineering mind, and endless imagination has proven his naysays wrong time and again. 

If you have a secret you can validate, that would be the first thing you’d want to tackle.

Step 3: Pick a Type of MVP

There are a number of MVP types to choose from. For your first MVP, you can build simple landing pages, or explainer video, to gauge early response from your target audience.

These are cost-effective ways to acquire validated learning, which can then be used to inform the next steps. As you validate the various hypotheses, you are effectively reducing risks and uncertainty as you calibrate your course.

Picking your MVP is all about maximizing the amount of validated learning you can acquire for the hypotheses that you have, and you will build more MVPs to answer more questions that may arise as you go along.

As such, building MVPs is really a process, and not about one single product. Each MVP builds upon your validated learning, to find answers to all the questions about your business model that you and your investors might have. If you can reduce risk and uncertainty in your business model, you will naturally make better decisions.

A great way to chart your progress is to follow the Business Model Canvas, or a variant of it, The Lean Canvas.



As you progress, you may find it more worthwhile to invest more time and effort into your MVPs. This may require that you raise more funds, but if you have executed previous MVPs well, then the validated learning you’ve collected will give you a good foundation to ask for more resources.

Step 4: Document Your Requirements

Now that you have a good idea why you are building what you are building, it’s time to put it down in writing so that someone can actually build it. If you have documented your findings and decisions around validated learning, then it becomes easier to decide what goes into your first MVP.

Too often, we want to build everything that we possibly can to delight our customers. However, doing so is risky as we may be building ourselves into a corner.

In software engineering, we say that all code is liability since we have to manage and maintain it over its lifetime. It also introduces complexity which prevents us from moving faster should we need to add or change features.

If you stay true to the goal of the MVP, then you will be able control the number of features it has. At Tinkerbox, we favour the use of user stories as a unit of work, and a medium for collaboration. You don’t want to get super detailed, but you want to encompass the entirety of your vision for the MVP; you can explore and add detail as you go along.

With a set of user stories, it will be easier to align with your designers and developers, before getting it built. As you run through the stories with your team, you get to refine it further based on questions that they may have, usually things that you may have missed out.

As a further step, it is always helpful if you can provide visual specifications of what you want. Using prototyping tools and techniques, even with pen and paper, can go along way to get your team on the same page.


Step 5: Build it

Now you have a concrete plan around what your MVP looks like it’s time to build it. Entire books have been written on this topic, so we’re just gonna cover some methods you might want to try out to make sure things are on track.

Let’s say that you are working on a tech startup, which works primarily through the form of a web or mobile application, and you're building a prototype to take to actual customers. You’re able to cobble together a small team of three, that’s the ideal according to 37 Signals (now Basecamp), to get on this.

In order for your product team to move in step with your Lean Startup driven startups, you will want to adopt Agile methodologies to manage the process. Agile is a good fit for lean startups because it does not require all details to be decided on up front, and is capable of reacting to changes more efficiently.

One great way to manage MVPs especially at the early stage would be to use Kanban boards to manage a pipeline of user stories.

A typical Kanban board for a small team (Image from

If you are familiar with the more popular Scrum method, Kanban offers a more lightweight approach that’s more suited for smaller teams and products. In fact, Scrum projects tend to be process heavy and time consuming, a cost that is only be outweighed when value can be captured usually by larger teams.

If you can get more efficient at planning and building user stories while test working product with customers in lock-step, you can build a very effective process for validating your business model with multiple MVPs.

Beyond these 5 Steps

Building the MVP is only one aspect of the Lean Startup Methodology, the other two parts being Measure and Learn. How you do that really depends on the type of MVP and the stage of the product.

More importantly, keep in mind the overall iterative nature of building MVPs. The more efficient you and your team gets at Build-Measure-Learn, the faster you can acquire validated learning, which in turns leads to identifying a scalable business model.


This is the third article of the mini series "Tinkerseries: The essentials for introducing technology into your business". To check for the latest updates regarding the series, please visit

Or go to the next article here.