Last time I told you about my story about Archie, who had a startup 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.

Startups are inherently uncertain

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

According to Ries, the essential part of this definition is its omission. It doesn't say anything about the size of the organisation, the industry or the sector of the economy it operates in. Anyone who does product development under conditions of extreme uncertainty is a startup.

Of course, another vital part of the definition is that a startup should create a new product or service. In other words, they should constantly 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 existing technology, a new business model or a new way to interact with customers.

The context in which the innovation happens is also important. It is not a startup if it's not done in an uncertain environment.

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

The future is uncertain for a startup. 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 others even perceive it as worth solving.

Validated learning

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

In practice, we can achieve validated learning 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 we can use in the following 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 we reached a dead end, we might choose to pivot, which means developing a new strategy to achieve our goals.

This decision point in the loop is our Learn phase. Although the Learn stage is the last element of the loop, since it is where we make our decisions, 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.

Assumptions and validation in the different stages of product development

As we've seen, we constantly develop new experiments to test our assumptions during our Build-Measure-Learn loop. 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 recognised a problem for which we might have an idea of how we can solve it, but we don't know if it's a problem others have. The main question we should answer is if the problem is meaningful enough to address.

In the learning phase, we should 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 significant enough for them to invest their time and effort in solving it?

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

Problem-solution fit

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

We are searching for answers to whether our solution works (and we can prove it) and 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 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, 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. We only want answers to the questions above before building our actual product.

Solution-product fit

Once in this phase, we already have a validated problem and solution, but we still need to answer whether we can develop a product that effectively delivers this solution.

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. Before, many smartphones failed because users didn't develop enough maturity to change their behaviour to use smartphones. Apple recognised this situation, but they were still confident in the rollout because of the previous success of the iPod, which cemented this behavioural change.

Solution-product fit is the first phase when we develop tangible, palpable prototypes: 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. However, human operators still carry out all the background functionality, just like a concierge MVP. We can measure these tangible products with the help of usability tests, UX test, alpha and beta tests.

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

Product-market fit

Product-market fit 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 can we 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 to.

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

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 improve our product or introduce new features.

The beauty of validated learning is that we can apply it outside the startup world, in enterprise or industrial settings.