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)
Ok. We should break down our vision into its parts. But where do we start? Which assumptions are worth making?
A business plan is made up 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 obvious 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 out.
These riskiest assumptions are called Leap of Faith Assumptions, or LOFA, by Eric Ries.
Based on the stage of product development we find ourselves in, we'll have to make different types of assumptions.
Every vision is built around an assumed buyer or user. Who he or she is, how he or she behaves and what he or she wants is all going to be part of our persona hypothesis.
Closely related to the persona hypothesis is the problem hypothesis, which basically assumes the challenges our user faces. 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 which 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 persone hypothesis could be something like "all users of (motorized and non-motorized) micromobility user faces this (safety) problem are our potential buyers". Later, as we interview these users we will probably learn that this assumption is most probably incorrect. If this happens we should reformulate our hypothesis.
For example, if we find out that this gadget is only of interest to people who use high velocity micromobility vehicles, we could instead say that "users of micromobility vehicles which travel at a speed of over 25 kmph (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 kmph (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 in a safer way". 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 are able to do so better. A good example of this is the aforementioned Prezi.
There were 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 these software don't assist the storytelling narrative".
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:
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 in fact, that often it's not even mentioned separately. But if we take a closer look at the 4 stages of product development, usability hypotheses are used in the following, third stage, which is the solution-product fit stage.
The usability hypotheses assume that our product is able to 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:
If we have arrived at a stage where we're making growth hypotheses, we most 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:
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 are going to be able to reach, convert and keep more users. There is no one-size fits all method to achieving this. The way you're going to formulate your growth hypotheses and the types of experiments you're going to run will also depend on the type of growth engine(s) you'll employ.
It's important to avoid assumptions that concern 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.
Our value hypothesis could also be formulated 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. As such, we throw our idea to the bin. In reality though, the users were actually feeling safer, but the users did not want to use it regularly because it did not provide the expected user experience.
This is 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.
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 to always 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 kmph (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.
Formulating goals based on SMART criteria is probably something that many of you already know. The good news is that the same SMART criteria can be used 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?
Let's remember what our problem hypothesis sounded like: "users of micromobility vehicles are not happy with the current safety solutions". This assumption is definitely not specific enough. It could be made more specific by stating which current safety solution they're not happy with.
The testable outcome part of our value hypothesis could also be improved. 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".
Now we're getting closer to a SMART value hypothesis, but if we look at it, we can immediately observe that it's not measurable. 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".
The importance of this criteria is best illustrated by our original persona hypothesis, which sounded like this: "each (motorized and non-motorized) 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 was also getting more achievable. "Users of micromobility vehicles which travel at a speed of over 25 kmph (bicycle, e-bike, e-scooter) and who use these vehicles daily, in an urban environment are our potential buyers" sounds actually 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.
If our assumptions are not relevant, then we will be losing time testing them. They could also easily lead us down a wrong path. A relevant assumption will always bring us closer to our vision.
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, a lot of countries make safety helmets mandatory, so this assumption cannot even be true due to legal restrictions.
This criteria 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. Obviously, our growth rate is going to be very different. As such, it is very important 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".
I hope this article helped you to understand how you ought to formulate your assumptions in each stage of product development. It's definitely not an easy task, but one worth putting some effort into.
The steps I provided are not meant to be exact rules, but as a loose guideline. 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.