Every idea, product development or business plan is accompanied by a vision. For IKEA, their vision was "to offer a wide range of well-designed, functional home furnishing products at prices so low, that as many people as possible will be able to afford them".

In the case of Prezi, a presentation software that became one of the most successful Hungarian startups, the founders stated that they wish to build a software that reforms the presentation experience and "reinvents how people share knowledge, tell stories and inspire their audiences to act".

Thanks to today's modern technologies, the question most often is not whether these visions are achievable but if they are worth achieving. If you're familiar with lean product development or design thinking, this train of thought won't be foreign to you.

But how do we know if an idea is worth pursuing or not? The lean product development framework starts by breaking down the vision into its elements. These elements should be formulated as hypotheses or assumptions, which should be in turn tested in small, iterative batches.

"Every business plan begins with a set of assumptions. Because the assumptions haven't proven to be true (they are assumptions after all) and in fact are often erroneous, the goal of a startup's early efforts should be to test them as quickly as possible." (Eric Ries – The Lean Startup, 2011)

Which assumptions are worth testing?

Ok. We should break down our vision into its parts. But where do we start? Which assumptions are worth making?

A business plan comprises of several assumptions that are not worth testing. These are usually evident or directly inferred from industry observations and knowledge.

In the case of IKEA, it was pretty evident that people would be willing to buy well designed and cheap furniture. But that they would also be willing to assemble it themselves was a lot less obvious, especially in those days when IKEA started.

These riskiest assumptions are called Leap of Faith Assumptions, or LOFA, by Eric Ries.

Types of assumptions

Based on the stage of product development we find ourselves in, we'll have to make different types of assumptions.

Persona and problem hypotheses

Every vision is built around assumed buyers or users. Who they are, how they behave and what they want will be part of our persona hypothesis.

The persona hypothesis is closely related to the problem hypothesis, which assumes our user's challenges. Is it worth spending time on solving these problems? We'll encounter these two types of hypotheses in the problem validation stage of the product development process.

In my article about problem validation, I came up with an imaginary product idea and a corresponding vision. For example's sake, we're developing a gadget that can be mounted on micromobility vehicles and, using sensors, alerts travellers of incoming obstacles and dangers (pedestrian crossing, motor vehicle, etc.) with sounds and vibrations of increasing intensity.

If we look at our vision above, our persona hypothesis could be something like "all users of (motorised and non-motorised) micromobility user faces this (safety) problem are our potential buyers". Later, as we interview these users, we will probably learn that this assumption is incorrect. If this happens, we should reformulate our hypothesis.

For example, suppose we find out that this gadget is only interesting to people who use high-velocity micromobility vehicles. In that case, we could instead say that "users of micromobility vehicles which travel at a speed of over 25 km/h (bicycle, e-bike, e-scooter) are our potential buyers".

We might also learn from the interviews that people who only use these vehicles for leisure are not interested in extra security. Instead, those who regularly use these vehicles to commute to and from work show a higher level of interest. We should again reformulate our persona hypothesis to "users of micromobility vehicles which travel at a speed of over 25 km/h (bicycle, e-bike, e-scooter) and who use these vehicles daily, in an urban environment are our potential buyers".

Based on the same vision, we could formulate our problem hypothesis as "users of micromobility vehicles do not feel safe when travelling and would like to be able to travel more safely". Or as "users of micromobility vehicles are not happy with the current safety solutions".

The second of these two assumptions is a great way to formulate hypotheses when there are existing competitors in the market. These competitors solve the same problem, but we assume we can do better. A great example of this is Prezi, as mentioned above.

There was presentation software on the market before Prezi, but every one of them delivered the same experience. So, Prezi's problem hypothesis probably sounded a lot like this: "users of current, slide-based presentation software (PowerPoint, Google Slide, Keynote) are not content, because the existing software doesn't assist the storytelling narrative".

Value and usability hypotheses

The value hypothesis, simply put, assumes that our solution effectively delivers value to the user. Sticking to our previous example, our value hypotheses would be as follows:

• our product helps the user be safer when travelling
• our product improves the sense of safety of users in such a way that would incentivise them to use the gadget regularly

We usually encounter the value hypothesis in the problem-solution fit stage of product development.

The usability hypothesis is closely tied to the value hypothesis. So closely tied that often it's not even mentioned separately. But if we take a closer look at the four stages of product development, usability hypotheses are used in the following third stage, the solution-product fit stage.

The usability hypotheses assume that our product can deliver our value proposition and does so in an effective, easy to use manner while also providing the expected user experience. In the case of our safety gadget, some of the usability hypotheses we could make are:

• our product is easy to user
• our users trust the product

Growth hypotheses

If we arrive at a stage where we're making growth hypotheses, we do probably have a good product on our hands, which solves a valid user problem. But this does not mean that the product is marketable. With the help of growth hypotheses, we search for this exact answer: is our business model sustainable.

In the case of our product, we could make the following assumptions about the business model:

• users are still willing to pay or exchange value for our product or service
• we can keep our existing users, maybe even sell the additional products or services
• users like our product so much, they are willing to refer it to others

We'll use growth hypotheses in the product-market fit stage of the product development life cycle. Here, we will employ multiple experiments to test how we will reach, convert and keep more users. There is no one-size-fits-all methods to achieving this. The way you formulate your growth hypotheses and the types of experiments you're going to run will also depend on the kind of growth engine(s) you'll employ.

How to formulate your assumptions?

Test one thing at a time

It's important to avoid assumptions concerning multiple aspects of our product or service. It's easy to make this mistake as at first thought it may seem that we save time in doing so. But the truth is that we won't be able to distinguish the exact reason why our experiments fail.

We could also formulate our value hypothesis as "our product helps users be safer when travelling and because of this, they will regularly use it".

During our experiments, this assumption could easily prove to be false, from which we could, erroneously, deduce that our product doesn't add to the safety of users. In reality, though, the users did feel safer but did not want to use it regularly because it did not provide the expected user experience. As such, we throw an otherwise good idea into the bin.

We've just seen how simply an easily solvable issue might sidetrack us completely. To avoid situations like this, take care to make assumptions that only test a single aspect of the product.

Base assumptions on prior knowledge

Our assumptions always have to be testable without difficulty, meaning that we should be able to devise experiments that allow us to validate or invalidate the current understanding of our users. It's best always to base our assumptions on prior knowledge. The following template may help with this:

By using the above template, we can improve our value hypothesis like this:

Since we know that users of micromobility vehicles which travel at a speed of over 25 km/h (bicycle, e-bike, e-scooter) and who use these vehicles daily in an urban environment don't feel safe when travelling, if we build a gadget that alerts them of impeding obstacles with sound and vibration alerts, then they will feel safer while commuting.

Be SMART

Formulating goals based on SMART criteria is probably something many of you already know. The good news is that we can use the same SMART criteria to make assumptions easier to test.

For those who don't know, SMART is an acronym for Specific, Measurable, Achievable, Relevant and Time-bound. So how do you make a hypothesis SMART?

Specific

Let's remember what our problem hypothesis sounded like: "users of micromobility vehicles are not happy with the current safety solutions". This assumption is not specific enough. It could be more specific by stating which current safety solution they're not happy with.

We could also improve the testable outcome part of our value hypothesis. It sounded like this: "they will feel safer while commuting". We could instead say, "our users will be more likely to avoid moving (motor vehicle, pedestrian, other micromobility) and static (tree, road surface issues) obstacles".

Measurable

Now we're getting closer to a SMART value hypothesis, but we can immediately observe that it's not measurable if we look at it. To make it measurable, let's include the minimal expected increase in safety: "our users will be 80% more likely to avoid moving (motor vehicle, pedestrian, other micromobility) and 40% more likely to avoid static (tree, road surface issues) obstacles".

Achievable

The importance of this criteria is best illustrated by our original persona hypothesis, which sounded like this: "each (motorised and non-motorised) micromobility user faces this (safety) problem".

Even the less experienced will immediately notice that this assumption will be hard to prove. But since we made this assumption at the very beginning, when we had close to no knowledge of our users, this is a forgivable offence.

As we progressed with user interviews, our hypothesis also became more achievable. "Users of micromobility vehicles which travel at a speed of over 25 km/h (bicycle, e-bike, e-scooter) and who use these vehicles daily, in an urban environment are our potential buyers" sounds achievable.

Reformulating or detailing assumptions is a natural, obligatory part of the learning process. Each of these changes is called a focus shift or pivot.

Relevant

A relevant assumption will always bring us closer to our vision. If our assumptions are not relevant, we will lose time testing them. They could also quickly lead us down the wrong path.

In our case, a non-relevant assumption could be that "our gadget will be a substitute for the safety helmet". This is non-relevant on multiple levels. First of all, it's not even our goal to provide an alternative to the safety helmet. Second of all, many countries make safety helmets mandatory, so this assumption cannot even be true due to legal restrictions.

Time-bound

This criterion is easiest to showcase with the help of our growth hypothesis. One of our assumptions was that "our users like the product enough to recommend it to others". First things first, this assumption is not measurable, so let us address that first: "our users like the product enough to recommend it to at least 1 other person".

But is it enough to make an assumption measurable? Let's say one of our users recommends our product to 3 people in the first month of using it, but never after. Another user recommends it to 1 person but does this every month. Our growth rate is going to be very different. As such, it is imperative to time-bound our assumptions. We could say, "our users like the product enough to recommend it on average to at least 1 other person every month".

Afterword

I hope this article helped you understand how you ought to formulate your assumptions in each stage of product development. It's not an easy task, but one worth the effort.

I did not write these steps as exact rules but as loose guidelines. If you don't use the "since we know that [prior knowledge], if we [do something] then [testable outcome]" template, no worries. You also shouldn't worry if not every assumption you make is time-bound or even measurable.

The goal, as always, is to learn more about your users with each test and be able to sustain this knowledge with empirical data.