Customer development means testing your guesses about customers before you pay for a build. You find out who has the problem, how much it hurts and whether they’d pay to fix it, and you do it by talking to them. This guide covers the method and the one habit under it: talking to the people you want to sell to.
It’s the first of five guides. The other four go deeper into hypotheses, budgets, problem interviews and solution interviews. There’s a map of all five below.
Building software got faster. In Google’s 2025 DORA report, 90% of the nearly 5,000 tech professionals surveyed said they use AI at work. The same report says AI helps most when it’s pointed at a clear problem, and that a focus on users amplifies its positive effect on team performance.
For founders, that cuts both ways. When building is cheap, you can build the wrong thing faster. In March 2026 CB Insights studied 431 VC-backed startups that shut down since 2023. Of the 385 with a known reason, 43% cited poor product-market fit. 70% ran out of money, but the report calls that the final cause of death, not the root problem.
Talking to customers before you build is a cheap way to stay out of that 43%.
Steve Blank, who created the method, splits it into four steps. Each step has its own question, and each one is in a guide of its own.
| Step | What you’re testing | What you do | Where to read more |
|---|---|---|---|
| Customer discovery | Who has the problem, and how badly | Problem interviews, written hypotheses | Problem interview checklist |
| Customer validation | Whether people will pay, again and again | Solution interviews, pre-orders, paid pilots | Solution interviews |
| Customer creation | Whether you can create demand at scale | Marketing channels, a sales process | Why you don’t need a marketing team yet |
| Company building | Moving from learning to running the business | Teams, process, hiring |
Blank’s model expects you to loop. If you can’t find enough paying customers in validation, you go back to discovery. That loop is what most people call a pivot.
In Y Combinator’s Startup School, Eric Migicovsky described three mistakes people make when they talk to users:
Three more rules help. Ask for numbers: how often the problem happens, what it costs them now and who holds the budget. Throw away compliments, because “that sounds great” isn’t data. And in the early stage, the founder talks to users, not a hired researcher. The person who decides what to build has to hear it first-hand.
These come from the same Startup School talk, lightly reworded:
Question 1 shows which problems hurt. Question 2 gets a real story with context instead of an opinion. Ask question 3 again and again, and you get to why people would pay. Question 4 is the filter: if someone has never tried to fix the problem, it may not hurt enough to buy a fix. Question 5 tells you what the current options get wrong, which is where your product has room.
Start small. In the same talk, Migicovsky says every good research plan starts with one or two people. Often that means co-founders, friends and friends of friends who have the problem. Then widen the net:
How many conversations? Teams in the US National Science Foundation’s I-Corps program, a seven-week course in customer discovery, are told to complete a minimum of 100 interviews. You don’t need 100 before your first decision. Ten good interviews with one customer group will usually show whether the problem is real. Keep going until new interviews stop telling you anything new.
| Stage | What you need to learn | What to ask | Next guide |
|---|---|---|---|
| Idea | Is the problem real, and who has it worst? | The five questions above | Problem interview checklist |
| Prototype | Who to launch with first | What the problem costs them, how often it happens, whether they have a budget | Solution interviews |
| Launched | What to build next, and whether it’s working | “How would you feel if you could no longer use the product?” | Hypothesis testing |
The last question is Sean Ellis’s product-market fit test. When Superhuman ran it, 22% of users said they’d be very disappointed without the product. Ellis puts the bar at 40%, and within three quarters the team nearly doubled its score to 58% (First Round Review).
A few habits from the old version of this guide still hold. Don’t build features straight from support requests; ask what problem the request is about. And keep the founder close to users for the life of the company, not only in the first month. For more on that habit, see our guide to customer obsession.
Customer development and a budget go together. You want to know what the build costs before you decide how much evidence you need.
Our project estimate turns your brief into user stories. You confirm what’s in scope, and every hour in the budget traces back to a story you kept. We check the hours the model suggests against what our team actually books on finished projects, then multiply by our published rate of $39-55 an hour. It’s a planning range, not a fixed quote.
The estimate also names the customer groups you could sell to and gives each one a market size (TAM, SAM and SOM) with a note on what the number covers. Treat those as hypotheses to test, not verified demand. That’s where this guide comes in: take each group you kept and talk to ten people in it. You can run your idea through our project estimate in about four minutes.
Evidence can come from more than interviews. The founders of Daisy’s Guide first sold a printed guidebook for couples expecting their first child, in the low thousands of copies. Only then did they turn it into a web app. After about 10 hours of paid discovery, the app reached a beta with real couples about 2 months after kickoff.
If you’re a first-time founder, our software development for startups page shows the price of each stage, from a 1-week discovery sprint for $3,000 to a first version for $5,000-15,000, typically in 2-4 weeks.
A way to build a company by testing your guesses about customers before you commit money to a product. You talk to the people you want to sell to, find out who has the problem and how much it hurts, and build only what they show they need.
Customer discovery (who has the problem), customer validation (will they pay, again and again), customer creation (can you create demand at scale) and company building (moving from learning to running the business). Most startups loop back to discovery at least once.
Ten good interviews in one customer group usually show whether the problem is real. Keep going until new interviews stop telling you anything new. The US National Science Foundation’s I-Corps program asks teams for a minimum of 100 over seven weeks.
Ask about the past, not the future. What’s the hardest part of the job, when did the problem last happen, why was it hard, what have you tried, and what don’t you like about it. Never ask “Would you use this?”
The founders. The people who decide what to build need to hear the problem first-hand. Hand it to someone else only once you have a repeatable sale.
Carefully curated content for resourceful Devs, CTOs, and PMs. No spam.