Validation in product development

Validation in product development

Last time I told you about my story about Archie, who had a start-up idea. Unfortunately, he decided to jump into developing the product without previously validating his ideas. Today, I would like to show you what he should've done and how he could've validated his idea. But first, let's see what validation actually means.

Start-ups are inherently uncertain

In his 2011 book, The Lean Startup, Eric Ries defines a start-up as "a human institution designed to create a new product or service under conditions of extreme uncertainty".

According to Ries, the most important part of this definition is what it omits. It doesn't say anything about the size of the organisation, the industry or sector of economy it operates in. Anyone who does product development under conditions of extreme uncertainty is a start-up.

Of course, another important part of the definition is that a start-up should create a new product or service. In other words, they should always innovate. Innovation should be understood broadly. It doesn't have to be a revolutionary change or new technology. It can also be the repurposing of an existing technology, a new business model or a new way to interact with customers.

The context in which the innovation happens is also important. If it's not done in an uncertain environment, then it is not a start-up.

Most enterprises are excluded based on this context. It might be a sound investment to create a company which is an exact clone of an existing company, including the business model, pricing, target demographic and product offering, but this will not be a start-up. The success of these businesses depends solely on execution, so much so that their success and the size of success can be modelled with high precision.

The future is uncertain for a start-up. There is no way to know how sustainable their business model will be, if their proposed solution will solve the problem they set out to solve, or if this problem is even perceived as a problem by others.

Validated learning

To ease uncertainty, the start-up world uses validated learning. Validated learning is a process which aims to empirically demonstrate that we are getting closer to our goals.

In practice, validated learning is achieved through the Build-Measure-Learn loop. In the Build phase we strive to create a minimal product or experiment which helps us test one or more assumptions.

The goal of these experiments is to show them as soon as possible to potential users and receive feedback and information which can be used in the next experiment. Gathering this data will be our Measure phase.

Based on the data collected, we will decide if we are closer to our goals or not. If we are, the loop starts over with a new Build phase in which we fine-tune or create new experiments to test further assumptions.

At a certain point our project will turn into a product. Soon, the product will enter the growth and maturity stages. You might think that the loop ends there, but in fact you can still use it to perfect the product or increase customer experience.

If the data shows us we reached a dead end, then we might choose to pivot, which means to develop a new strategy to reach our goals.

This decision point in the loop is our Learn phase. Although the Learn stage is the last element of the loop, since this is where the decisions are made, our very first task at the beginning of a loop is to decide what assumptions we want to test and what we want to learn from these tests.

Validation in product development - Infographic

Assumptions and validation in the different stages of product development

As we've seen, during our Build-Measure-Learn loop we constantly develop new experiments to test our assumptions. But what assumptions should we test in the different stages of product development? My favourite resource on this topic is the Lean Validation Cheat Sheet.

Problem validation

In the early stages of product development our goal should be to validate our problem. Usually, we have just recognized a problem for which we might have an idea on how it can be solved, but we don't know if it's a problem others have as well. The main question we should answer is if the problem is meaningful enough to address.

In the learning phase we should look to find answers to questions like what is the problem we wish to solve? Who else has this problem? How do they try to solve this problem currently? Is this problem important enough for them to invest their time and effort to solve this problem?

In the build phase of problem validation it's worth defining the vision and goals, user personas and customer journey map, while in the measure phase one should conduct interviews, field observations and other discovery techniques such as contextmapping.

Validation in product development-Cheat-sheet-1

Problem-solution fit

When in this phase, we already know that the problem we discovered is meaningful for others as well and they are actively looking for a solution, but we are not sure that our solution truly solves the problem for them.

In this phase we are searching for answers if our solution works (and we can prove it), but also if it brings a big enough improvement to the lives of our users. We also want to answer if the users trust our solution enough to use it.

A good method to find answers to these questions is creating a value proposition canvas. This canvas helps us to position our product or solution around the needs and values of our users.

Another tool we might use in this phase is the concierge MVP. This is one of the most minimal versions of an MVP. It's so minimal, that we don't even have a product, instead we perform every function of the product manually. Of course, this is not a sustainable business model, but it isn't even our goal. In this phase, we only want answers to the above questions before we start building our actual product.

Validation in product development-Cheat-sheet-2

Solution-product fit

Once in this phase, we already have a validated problem and solution. The question that remains to be answered is if we can actually develop a product that delivers this solution effectively.

We're looking to answer questions such as if our product delivers a better solution than what our users have been doing until this point, or if the product is usable.

Another important question is if using the product requires a behavioural change from our user. Think of the iPhone. It wasn't the first ever smartphone. There were many smartphones before that failed, because users didn't develop enough maturity to change their behaviour to use smartphones. Apple recognized this situation, but they were still confident in the rollout because of the previous success of the iPod, which cemented this behavioural change.

This is the first phase when we develop tangible, palpable prototype: paper prototypes, clickable demos or even a Wizard of Oz type MVP. This type of MVP is an advanced version of a concierge MVP. The prototype needs to feel like a polished product, that everything is fully automated, but in fact all the background functionality is still carried out by human operators as in a concierge MVP.

Measurements are also done on the tangible product with the help of usability tests, UX test, alpha and beta tests.

Validation in product development-Cheat-sheet-3

Product-market fit

This is the last stage of our product development. At this stage we already know that our product delivers the solution to our problem effectively, but we still don't know if our business model is sustainable.

Are we able to turn users into paying customers? How many customers are we able to get and how much are they willing to pay? How many customers are going to be returning customers? These are the core questions we are looking to find answers for.

In the Build phase we are no longer creating prototypes. Instead we are building marketing campaigns: product videos, landing pages and newsletters. As for as the Measure phase goes we should concentrate on measuring the success of our campaigns based on analytics, A/B testing or pre-order experiments.

Validation in product development

Whichever stage we're in, when we arrive at the end of our experiments we have to decide based on the things we learned and our measurements if our developments are getting us closer to our goals and we should persevere, or pivot instead. If we reach the end of the product development process, we can repeat these steps to further improve our product or introduce new features.

The beauty of validated learning is that it can be applied outside the start-up world as well, in enterprise or industrial settings as well.

If you liked this article, download the accompanying infographic!

I want the infographic