Sources
- Steve Blank, “The Four Steps to the Epiphany” (2005)
- Eric Ries, “The Lean Startup” (2011)
- Adapted by Nate Ritter for Founder Labs (2024)
Original Context
Blank created this after analyzing his failures across 8 startups. It was refined in 2004 when he worked with Eric Ries at IMVU. Ries combined it with Agile Development to create the Lean Startup movement.
What Problem It Solves
Traditional product development assumes you know who your customers are and what they want. Most startups have only untested hypotheses (guesses) about their market. Following traditional product development leads to building products nobody wants—the primary cause of startup failure.
Primary Goal
Find a repeatable and scalable business model through validated learning before scaling
Core Concept
“In a startup no facts exist inside the building, only opinions.” You must systematically test your assumptions about customers and markets BEFORE investing heavily in building product. The goal is finding a repeatable and scalable business model through validated learning.
The Four Phases
- Customer Discovery - Testing if customers have the problems you think they have and if your solution addresses them
- Customer Validation - Building a repeatable sales model with early customers
- Customer Creation - Scaling demand creation (marketing/sales)
- Company Building - Transitioning from search mode to execution mode
For Early Stage Founders
Focus ONLY on Phase 1 (Customer Discovery) and early Phase 2 (Customer Validation) until you have paying customers and have documented, extremely specific patterns within them. Many technical founders skip directly to building, which is why Customer Development forces you to “get out of the building” and talk to real humans about real problems they’re actually experiencing.
When to Use It
Highest priority / stage
If you’re pre-product, pre-revenue, your growth has stalled, churn is high, or you’re looking for revenue expansion with your current customers.
Not as useful for
Those companies / projects where the current focus is scaling what’s working, or if you’re dealing with marketing channel saturation.
Common Mistakes
Warning
Avoid these common mistakes when using this framework:
- Treating customer conversations as sales pitches instead of learning sessions
- Only interviewing people who fit your demographic assumptions (test them first)
- Believing compliments equal validation (read The Mom Test)
- Stopping customer discovery after building the product (it never ends)
Tactical “How To”
Step 1) State Your Hypotheses
Objective: Document all your assumptions so you can test them systematically.
Why This Matters: According to Blank, most startups fail because they execute a business plan full of untested assumptions. Writing them down forces clarity about what you actually need to validate.
How to achieve the objective: Start by writing hypotheses in each category - problem, customer, and product (you may also decide to add “marketing channel” too).
These should be as specific as you can make them. The templates will help guide you to write them as sentences. But, immediately after writing these, you can break the statements into a bunch of assumptions, categorize them as risks or opportunities, and prioritize them. Each higher level hypothesis you write will likely have many assumptions (and probably sub-assumptions) inside them.
Step 1.1) Write Your PROBLEM Hypothesis
Template:
[Target customer segment]
has a problem with [specific problem]
because [underlying cause].
This problem costs them [time/money/frustration]
and they currently solve it by [current alternative].
Example:
Example
Technical founders ($0-5k MRR) struggle to validate their product ideas because they build features based on assumptions instead of talking to customers. This costs them 3-6 months of wasted development time, and they currently ‘validate’ by asking friends/family who give biased feedback.
List of smaller, more specific assumptions from this example:
- Technical founders struggle with validation more than non-technical founders.
- Technical founders hate building products nobody wants (and have experienced this previously).
- Technical founders believe it would be better to validate before building.
- Technical founders struggle with the process of validation (i.e., customer development, customer interviews, etc.).
- After $5k MRR, technical founders aren’t struggling with product validation anymore.
- Technical founders typically spend 3-6 months developing first, rather than validating.
- Technical founders typically only validate by asking friends/family.
- Technical founders have a difficult time figuring out what questions to ask that won’t give them biased feedback.
Bold words are what you’re really testing.
Step 1.2) Write your CUSTOMER Hypothesis
Template:
Our customer is [specific description]
who [specific behavior/context].
They care about [primary motivation]
and make decisions based on [decision criteria].
We can reach them through [specific channels].
Example:
Example
Our customer is a solo technical founder or developer who has quit their job or is working nights/weekends on a SaaS product. They care about reaching profitability before running out of savings and make decisions based on tactics that worked for other bootstrappers. We can reach them through indie hacker communities, Twitter/X, and targeted LinkedIn.
List of smaller, more specific assumptions from this example:
- Solo tech founders / developers who quit their job or are side-hustling on SaaS biggest concern is profitability before running out of savings.
- Solo tech founders / developers who quit their job or are side-hustling on SaaS primarily make decisions based on tactics that worked for other bootstrappers (influenced).
- Solo tech founders / developers who quit their job or are side-hustling on SaaS exist on private indie hacker communities.
- Solo tech founders / developers who quit their job or are side-hustling on SaaS exist on Twitter/X.
- Solo tech founders / developers who quit their job or are side-hustling on SaaS exist on LinkedIn.
- Solo tech founders / developers who quit their job or are side-hustling on SaaS will reply to DMs on {each of the above marketing channels broken out}.
- Solo tech founders / developers who quit their job or are side-hustling on SaaS will reply to public tagging/messages on (each of the above marketing channels broken out)
Bold words are what you’re really testing.
Step 1.3) Write Your PRODUCT Hypothesis
Template:
We believe that [feature/solution]
will solve [specific problem]
for [customer segment]
because [reason/mechanism].
Success looks like [measurable outcome].
Example:
Example
We believe that weekly accountability sprints with structured validation frameworks will help technical founders make validation decisions faster because it forces them to talk to customers systematically with how-to tactics instead of building in isolation without experience. Success looks like members completing 10+ customer interviews in their first month.
List of smaller, more specific assumptions from this example:
- We believe accountability sprints + structured validation frameworks are more effective for pre-PMF founders (measured by decision making speed) than individually.
- We believe pre-PMF founder decision making speed is increased by talking to customers.
- We believe pre-PMF founders will pay at least $100/mo for faster decision making speed.
Step 2) Create Spreadsheets
Step 2.1) Create the Assumptions Spreadsheet: (with example data)
Create a table with the headings as shown below. For the “Risk” category, you can create selectable options as shown below, or a rating from 1-4 or so. The goal with the “Risk” column is to help you prioritize. The more you practice the skill of seeing where you’re making assumptions without data to back you up, the more assumptions you’ll add. This list will get long. Prioritization is key to making progress on the most important things. Focus only on validating the “Company killer” level assumptions first.
What is a “Company killer” assumption?
We all make assumptions about our businesses. Prioritize getting data on the ones where if you’re wrong, your company is dead on arrival. Product feasibility is one, but the more difficult company killers are whether the market actually wants what you have, and whether or not you can actually reach them with that offering.
“Kinda risky” assumptions are ones which would make the model you have in your head difficult, but you feel there’s probably a few workarounds or ways to hedge. They won’t kill the company, but they might make it unappealing to run.
“Maybe risky” assumptions are ones which can most likely be adjusted. The model might not be ideal, but there are other options that would still make the company appealing to run and work on in the future.
“Not really risky” assumptions are still assumptions, but likely would not change the directionality or feasibility of the company’s future prospects that much.
| Assumption (ICP = bootstrapped SaaS founders, indie hackers, solopreneurs) | Risk | Completed | Result / Learning |
|---|---|---|---|
| Value Proposition: The community’s primary value proposition (networking, resources, mentorship) is clear and compelling to potential members. | Company killer | 2024-11-03 | False. Only mentorship is compelling. |
| ICP is willing to pay at least $250 for guidance from an expert, hourly | Kinda risky | ||
| ICP has enough money to spend on a community ($20-100/mo) | Maybe risky | ||
| ICP are open to advice from experts | Not really risky |
Step 2.2) Create the Opportunities Spreadsheet: (with example data)
Create a table with the headings as shown below. For the “Opportunity Size” column, you can create selectable options as shown below, or a rating from 1-3 or so. The goal with the “Opportunity Size” column is to help you prioritize. The more you practice the skill of seeing where your biggest opportunities are, and the difficulty to test them, the more you’ll want to document and prioritize them.
“Difficulty” should be a rating of how difficult it would be to test if this opportunity is a viable/accessible one to you right now. You might make notes as to why you think something is rated where it is. Bringing your team or others into ranking these is helpful because some people will find ways of testing that are faster/easier than you might think at first.
“Priority” is simply subtracting “Difficulty” from “Opportunity Size”. You may notice this is a simplified version of the R/ICE Prioritization Framework, which is useful for deciding on features to build in software products.
You’ll start using this sheet AFTER your “Company killer” assumptions are all invalidated. Don’t worry about using this spreadsheet until then, but I do suggest practicing adding Ideas / Opportunities and evaluating them every so often so that you don’t start from zero when the time comes.
| Idea / Opportunity | Opportunity Size | Difficulty | Priority | Test Completed | Result / Learning |
|---|---|---|---|---|---|
| Niche down to agency owners only | Big (3) | 1 | 2 | 2024-11-03 | Playbook is already in Obsidian. |
| Niche down into full-time only | Decent (2) | 1 | 1 | ||
| Niche down to engineers only | Minor (1) | 1 | 0 | 2024-11-03 | They have money. I have cred. They aren’t big spenders. |
Step 2.3) Create the Hypothesis Spreadsheet: (with example data)
Each of the above assumptions (risks) and opportunities (ideas) are hypotheses. They are not reality. You must treat them as such. Thus, without data to back them up, you could be wasting time building solutions.
Admitting these are assumptions will naturally lead you to want to resolve them. They are “open loops.” So, let’s close them by creating hypotheses and testing them.
Characteristics of a Good Hypothesis
- Testable/Falsifiable: You must be able to support or disprove it with data from your study.
- Specific: Clearly identifies the variables (independent & dependent) and the population being studied.
- Predictive: States the expected outcome or relationship between variables.
- Clear & Concise: Easy to understand, avoiding vague language or moral judgments.
- Grounded in Theory: Based on existing knowledge or literature.
Examples in “If-Then” Format
Examples
- Science: “If a pond’s water temperature rises 2+ degrees, then the algae population will increase by 50%“.
- Health: “If athletes follow daily cold showers, then their endurance increases”.
- Education: “If students sleep at least 8 hours, then they will achieve higher test scores”.
The more specific the variable (“2+ degrees”) and the change (“50%+ more algae”) the better.
How to Formulate a Good Hypothesis
- Identify your variables: What are you changing and what are you measuring?
- Formulate the question: Turn your topic into a question (e.g., “Does X affect Y?”).
- State your prediction: Use “If {change X}, then {expect Y to change}“.
- Refine: Make it specific and testable, like “Dandelions in nitrogen-rich soil develop larger leaves”.
Example:
| Hypothesis | Test Method | Pass/Fail Criteria | Result | Pass/Fail | Date Tested |
|---|---|---|---|---|---|
| If I DM 100 solo technical founders on Twitter/X, at least 50% will respond | Twitter/X DMs | 50% response rate | 55% | Pass | 2023-11-03 |
[! warning]
Avoid these common mistakes when writing hypotheses to avoid wasting time on test that will fail to give you what you need:
- Making hypotheses too vague (“people need productivity tools”)
- Not making grooming of these spreadsheets at least a weekly activity
- Not focusing on the most risky assumptions first
- Stating hypotheses as facts (“customers want feature X”) instead of testable assumptions
- Never writing assumptions down at all and building without testing them
Source: Blank, “The Four Steps to the Epiphany” Chapter 2: Customer Discovery References:
- http://www.startuplessonslearned.com/2008/11/what-is-customer-development.html (Eric Ries on hypothesis testing)
- R/ICE Prioritization Framework
Step 3) Test Your Hypotheses
This part is somewhat vague because what you are testing and how will be dependent upon your stage.
Generally, you’d be using the methodology above for all 4 phases of Customer Development.
Once you’ve tested if customers have the problems you think they have and if your solution addresses them, you can move on to iterating on your theoretical repeatable sales model. Once it’s actually repeatable, you can start scaling demand creation (marketing/sales channels).
Important
These 4 phases of Customer Development seem to imply you must build before you sell. Nothing is further from the truth.
The first phase is customer/problem discovery. You don’t need to build here. This is what research, landing pages, small prototypes, MVPs, and other tiny tests and experiments can help you decide. This is why we break the assumptions down into smaller and smaller versions - to test them as quickly as possible. For example, if you’re testing whether or not a target is reachable on a particular channel, you only need to DM them and see if they reply, not build or demo anything.
The framework for ordering your hypothesis testing is Demo, Sell, Build.
Note
Note
There is more to Customer Discovery as Steve Blank and Eric Ries have defined it than what is in this document. The process documented here is just what matters most to early-stage, pre-PMF founders according to Nate Ritter.
References
- https://steveblank.com (Steve Blank’s blog with the Customer Development Manifesto)
- https://www.marsdd.com/article/the-customer-development-model-cdm-product-development-and-technology-startups/
- https://userpilot.com/blog/customer-development-process/