DEVELOPING A GREAT VALUE HYPOTHESIS
A great value hypothesis is essential for any business hoping to solve a problem. It is a crucial starting point while finding your company’s “unique value proposition”, and is essential for any business hoping to clearly communicate to customers why they are different, better, and worth purchasing from. This article provides a brief intro about the “Value Hypothesis”, “Growth Hypothesis” and the “Highest Risk Assumption”. It then goes on to focuses on forming a “Value Hypothesis” with a case study example of DropBox. However the same experiment and hypothesis methods can be applied to articulate a “Growth Hypothesis”, which will be the subject of a future post.
Your most fundamental activities during your early days in developing a new startup are:
1. Articulation of a testable “value hypothesis”
2. Validation of your “value hypothesis”
3. Using your validated value hypothesis to generate a “value proposition” with longevity (1-2 years) for your Minimum Viable Segment (MVS) in order to define a Minimum Viable Product (MVP) and achieve a faster product/market fit.
The Lean Startup approach is NOT about releasing a poor quality product, spending no money, throwing something against the wall to see if it sticks, A/B testing your way to success and changing your business model constantly. Instead, lean is about learning, and about taking a scientific approach to launching a startup, recognizing the assumptions that you believe (with little or no evidence) and testing them vigorously, as early as possible.
The two most important assumptions entrepreneurs make, should be articulated as “value hypothesis” (before Product/Market fit) and “growth hypothesis” (after Product/Market fit) and rigorously tested.
The value hypothesis tests whether a product or service really delivers value to customers once they are using it. This hypothesis will determine if the product should be used and adopted into your customers’ lives. Note that a value hypothesis should not be about whether you can build a particular piece of technology – it should be about whether you can deliver value to a set of customers.
The growth hypothesis tests whether you can establish a repeatable and scalable sales cycle.
A strongly validated value hypothesis plays a crucial part in articulating your final value proposition.
The Life of a Value Hypothesis
There are certain assumptions inherent to the value hypothesis. A critical part of a startup’s CEO’s role is to:
1. Validate/amend the Big Market Problem and the value hypothesis based on their experience and some initial conversations with potential advisors, investors, employees, and prospective customers.
2. Document and categorize the (sub-)assumptions to help test, validate and adapt the value hypothesis in order to achieve a strong and meaningful direction for the company.
3. Define candidate MVSs to identify the narrow (50-200 company) target sector where the value hypothesis best resonates.
4. Define candidate MVPs that will enable the company to test the value hypothesis as quickly as possible while minimizing cost/resources.
5. Articulate and laser-focus on your value proposition, which you have arrived at by having a fully validated value hypothesis.
Example: Big Market Problem and Value Hypothesis
Here’s a healthcare example showing a Big Market Problem and a Value Hypothesis:
Big Market Problem
High-cost Specialty Drugs (SDs) for chronic or rare conditions, like cancer or multiple sclerosis, are rising by up to 20 percent a year. According to a study done by Express Scripts, SDs will account for more than half of all prescription costs by 2019. Although used by a only a small subset of very sick patients, the SD spend is outpacing all other sectors of healthcare costs and therefore is a natural target for cost cutting by payers and pharmacy benefits managers (PBMs). At the same time, these are the medications that drug makers are most keenly focused on developing and bringing to market. And for many patients, these are the only drugs that will help them. However, the most striking aspect of specialty drugs is that few payers have effective ways of controlling their associated costs. Conventional tools of benefit design, switching to cheaper generic alternatives and utilization management are less effective for specialty drugs.
Value Hypothesis
NewCo’s analytics solution will help the Utilization Management managers/nurses to analyze and determine the optimum utilization levels of a specific SD within a payer's provider network, at an individual patient level and thus decrease payer’s SD costs by a significant percentage.
A value hypothesis needs to be specific, measureable and falsifiable. For example, you will notice in the statements above that the aim is to decrease a payer’s SD costs by a significant percentage. This is an adequate starting position for a new startup, but one of the early tasks for the CEO will be to harden this value hypothesis and make it more measurable, e.g. to “decrease payer’s SD costs for cancer drugs by 25%”. The key here is that the change in the metric (and the metric itself) needs to be meaningful to your customers.
Document and Categorize Assumptions
Having defined and hardened the big market problem and the value hypothesis, you should now look at the underlying assumptions. The CEO's task is to list of all of the assumptions and categorize them. She/he can then identify the Highest Risk Assumption (HRA) and build an experiment to test that.
There are three types of assumptions:
1. Problem Assumption: Is there a problem? (User & Problem)
2. Solution Assumption: Is this the right way to solve it? (How are you solving?)
3. Implementation Assumption: Can you build & sell it before running out of money? (What do you have to do?)
Out of your Problem, Solution and Implementation Assumptions, your HRA is the one that, if untrue, forces you to pivot to have a viable business. Note that your HRA will change over time as you work towards proving your value hypothesis.
Identifying and Testing Your Highest Risk Assumption - DropBox Example
DropBox synchronizes files across your computers and your team’s computers in such an efficient way that you don’t need to carry a USB drive, or upload or email these files to share.
1. List all the Assumptions.
“For DropBox to succeed, it is necessary that _________”
- People have multiple devices.
- People want to access the same files across those devices.
- This is hard to do.
- People will download DropBox on multiple devices.
- People will trust the service with important data.
- People understand how DropBox folders work.
- We can build a product that syncs files across multiple operating systems.
- The product will synch quickly and accurately.
2. Categorize the Assumptions into Problem, Solution and Implementation.
DropBox’s Problem Assumptions
- People have multiple devices.
- People want to access the same files across those devices.
- This is hard to do.
DropBox’s Solution Assumptions
- People will download DropBox on multiple devices.
- People will trust the service with important data.
- People understand how DropBox folders work.
DropBox’s Execution/Implementation Assumptions
- We can build a product that syncs files across multiple operating systems.
- The product will synch quickly and accurately.
- We will not need to provide services or face-face training for our customers
3. Identify “Will Kill” assumptions.
DropBox’s “Will Kill” Assumptions:
- People have multiple devices and they want to access the same files across those devices.
4. What is the Highest Risk Assumption (HRA)?
People have multiple devices and want to share files across them
Since DropBox’s Value Hypothesis assumed that “people would want to synchronize files across their computers”, it is crucial for the assumption “People have multiple devices and want to share files across them” to be true.
Keep in mind that this was DropBox’s HRA when they were starting! The HRA will change over the company’s/product’s life span. Your HRA can be a Problem, Solution or Execution/Implementation assumption, depending on where you are in terms of lifecycle.
Now that you have identified your Highest Risk Assumption, make sure to turn it into a falsifiable hypothesis statement and write “How you will know if you were right?” (this is your experiment).
Note that you should not use an execution/implementation assumption as the basis for your value hypothesis, since you will tend to focus on internal metrics, rather than something of value to your MVS. The HRA is something that you need to verify as you work towards testing your value hypothesis.
Pivot vs. Optimization Experiments
In the ideal scenario, prior to Product/Market fit, where you are testing your value hypothesis, you should be conducting Pivot Experiments.
Pivot Experiments: (During Sprint I-II for Problem/Solution Fit)
Attempt to validate parts (sub-hypothesis, HRA etc.) of a business model hypothesis in order to find product/market fit.
The Goal: Course correction (or a pivot).
After Product/Market fit, where you are testing your Growth Hypothesis, you should be conducting Optimization Experiments.
Optimization Experiments: During Sprint III-N for Product/Market Fit
Attempt to refine parts of a business model hypothesis in order to build a scalable and repeatable business model.
The Goal: Efficiency (or scale).
“Pivots are about changing direction, while Optimizations are about going faster.”
Value Proposition
A great value proposition with significant longevity has a number of key responsibilities. Catchy, abstract phrases don’t make decisions easy for customers when they are comparing “apples-to-apples” purchases.
In other words, especially for a small company, telling your customers to “just do it” doesn’t make picking a pair of shoes or a Big Data Analytics solution any easier. Instead, the following items are what you should be addressing:
1. Give your value proposition relevancy to customers by saying (outright) what problem it solves, or how it will improve their current situation.
2. Quantify the value for your customers by listing specific benefits (steer clear of “It’ll save you money,” and opt instead for “You’ll save $30/month on your bill.”)
3. Place priority on your point of difference, which is the reason why your solution is better than the competition in some notable way.
FAQ
What is a falsifiable hypothesis?
A falsifiable hypothesis is a statement that can be clearly proven wrong.
- Bad example: “Being known as an expert will drive early adopters” [No! Hard to prove wrong]
- Instead, you should have a statement such as “A blog post will drive 100 sign-ups”
Since my company tackles a big problem, is it OK if the the MVS is broad too?
No. MVS = Minimum Viable Segment. The ultimate market for your product may be wide, but the MVS is your first target segment where you will knock down a lead pin in a bowling alley strategy, to quickly gain traction. The MVS is not the addressable market. You should be looking for an MVS of ideally 50-200 companies, who hang out in the same places (geography, conferences, social networks) so that word-of-mouth marketing can help create the whirlwind once you’ve proven your value hypothesis. The other point of an MVS is that it helps you stay focused on a narrow MVP – otherwise you will end up trying to support too many use cases and therefore too many product features.
Shouldn’t I be trying to build a ‘whole product’ that solves a customer problem?
Ultimately, yes, you should deliver a whole product and have that as part of your long-term vision, but this is different from an MVP. The MVP aims to build the minimum necessary to test your Value Hypothesis. It is designed to help you get to an inflection point, to trigger adoption in your MVS as a first step towards your broader market opportunity.
Is it OK if my POC is broader than the MVP, especially if the customer is paying?
While always very tempting, you should try and resist. Receiving money for a POC or POV is a nice to have, but you mustn’t get distracted from your goal of building and testing an MVP. It is better to turn down a paid POV that does not test your MVP and to accept a free POV that directly supports your MVP. Note that the success criteria of a POC/POV should also reflect your MVP (and therefore your Value Hypothesis).
Am I hedging on my MVS?
One key aspect of this approach is that you make a hypothesis based on reasonable assumptions, and then test it, as quickly and efficiently as you can. There is a danger in trying to keep too many options open ‘in case my hypothesis fails’. For one thing it is distracting, wasting time and resources, and it also means you are not fully committed to the MVS. Nobody is recommending that you only work on one POV – it’s wise to have several POVs lined up, so you’re not reliant on one single opportunity. However, that is very different from running multiple POVs in various industries and use cases ‘because I have a horizontal solution’. Pick the use case that seems the best fit, and focus exclusively. If it doesn’t work, you have given yourself time to pivot.
“If you put software in a hospital for a 90-day trial and at the end of 90 days they say, “Don’t take that software out!” we know it has reached product/market fit”
Stephen Liguori, GE, Executive Director, Global Innovation.
About the Author:
Stuart Frost has 30 years’ experience in founding and leading successful data management and analytics startups. His latest company, Geminos Software, has created a platform that is designed to improve productivity of developers building AI-driven analytics by 10X. In the last eight years, he has created and incubated some of the leading companies in the IIoT market, including Maana (IIoT knowledge platform), OspreyData (oil and gas analytics), NarrativeWave (wind farm analytics), ThinkIQ (food traceability) and SWARM (AI agents for IIoT). During this time, he saw the market go from its very early gestation to the point where major industrial companies are starting to make significant, long term commitments to digitization. Through this unique experience, Stuart has developed deep knowledge of the market’s needs and how to successfully create and sell key technologies to meet those needs.
For more information: