A startup idea is not validated when people say it is interesting.
Validation comes when the right people change their behavior, give up time, share real context, or pay.
Many early startup mistakes come from poor sequencing rather than poor engineering.
Founders often begin with a solution, then search for a problem that makes the solution feel inevitable.
Modern tools make that temptation stronger.
For example: a landing page can be generated in an afternoon, a prototype can be assembled in a weekend, and an AI-enabled product can look surprisingly complete before anyone has established that the underlying problem matters.
That speed is useful, but it can also make false positives cheaper. A polished demo can collect compliments. A waitlist can collect email addresses. A friendly conversation can collect encouragement. None of those, alone, establishes that a defined group of people will repeatedly make room for the product in their work or life.
The useful question is smaller and more demanding:
What is the cheapest credible test that could prove me wrong?
That is the spirit of customer development: treat the business as a set of hypotheses about a customer, problem, solution, channel, and business model - not a plan waiting to be executed. Steve Blank’s explanation of customer development and Strategyzer’s work on critical hypotheses are still good anchors.
This guide gives you a practical validation sequence, a way to rank evidence, decision rules, interview questions, and a four-week operating plan. It is for founders building software, services, marketplaces, developer tools, AI products, and internet businesses.
The plain version
Before building a substantial product:
Name one customer segment narrowly enough that you can find ten people in it.
Write the few assumptions that must be true for the idea to work.
Talk to people about their existing behavior and recent events—not your concept.
Find evidence of an expensive, frequent, or risky problem.
Test the promise with an artifact: a landing page, mockup, manual service, or prototype.
Ask for a meaningful commitment: a calendar slot, data access, a pilot, a deposit, or payment.
Decide in advance what result means continue, change direction, or stop.
The order matters. Interviews tell you whether a problem is worth investigating. Behavior tests tell you whether your proposed solution is compelling. A real transaction or pilot tells you whether a business may exist.
Do not validate “the idea” all at once
“Will people use an AI tool for marketers?” is not a testable question. It contains too many unanswered questions.
Break it into assumptions:
| Assumption | What could make it false? | Early test |
|---|---|---|
| Independent SaaS marketers struggle to turn product updates into distribution | The work is infrequent or already solved by an existing workflow | Recent-event interviews |
| The pain is important enough to change behavior | It is merely annoying, not consequential | Ask for examples, time spent, missed outcomes |
| Your proposed workflow is better than the workaround | A spreadsheet, agency, or existing AI tool is good enough | Clickable prototype or concierge test |
| A reachable channel exists | The people are difficult or expensive to find | Small channel test and direct outreach |
| They will pay | The problem is real but not budgeted | Paid pilot, pre-order, or pricing conversation |
This is the useful distinction between desirability, feasibility, and viability. Strategyzer recommends mapping assumptions by impact and evidence, then testing the consequential assumptions with the least evidence first. Its testing framework is valuable because it does not treat every uncertainty as equally urgent.
For an early founder, the most dangerous assumptions are usually: “this problem happens often,” “this group is reachable,” and “they will pay enough.” A feature can be changed later. A nonexistent market cannot be fixed by better UI.
Start with a specific customer and a recent event
Do not recruit “anyone interested in productivity.” Recruit a person who has recently done the job you want to improve.
Good segments include:
Solo B2B SaaS founders who ran a launch in the last 90 days
People at 20–100 person software companies who decide which salesperson or team follows up when a potential customer fills out a form or requests a demo
Agency owners who produce client reports every month
Security engineers who review vendor questionnaires before procurement
Specificity is not bureaucracy. It prevents you from combining incompatible jobs, budgets, and buying processes into one flattering average.
Ask about the last time the problem occurred:
“Walk me through the last time you had to do this.”
“What triggered it?”
“What did you try first?”
“What was slow, risky, or frustrating?”
“What did it cost in time, money, missed revenue, or reputation?”
“Who else was involved?”
“What would have happened if you had done nothing?”
Avoid leading with: “Would you use an app that…?” That question invites politeness and imagination.
The customer-development case against focus-group-style feedback is simple:
People are much better evidence when describing actual behavior than when predicting a hypothetical future.
YC’s Startup School materials similarly emphasize validating ideas with potential customers before committing to the company.
Look for expensive workarounds, not compliments
The strongest early signal is usually not enthusiasm. Look for a workaround with a cost.
Pay attention when people:
Export data and reconcile it manually
Maintain a spreadsheet nobody likes
Use two or three tools in sequence
Hire a contractor or agency for a repetitive task
Delay work because it is difficult or risky
Describe a failed attempt to solve the problem
Ask whether they can see or try something immediately
Workarounds are evidence that the problem is already competing for attention. They also reveal the real workflow, the language customers use, and the constraints your product must respect.
Do not confuse severity with frequency. A terrifying annual compliance problem may sustain a high-ticket product; a small daily workflow problem may support a low-cost tool. Either can work. The test is whether the value created is proportionate to the switching cost and price.
Use an evidence ladder
Not every positive response deserves the same weight.
| Signal | What it tells you | Strength |
|---|---|---|
| “That sounds cool” | Little; often social encouragement | Weak |
| Completed survey | Directional interest | Weak to moderate |
| Detailed story of a recent problem | The problem is real for this person | Moderate |
| Introduces you to another affected person | Some conviction and relevance | Moderate |
| Books a follow-up or shares workflow data | Willingness to invest time | Stronger |
| Uses a manual or prototype version | Actual behavior | Strong |
| Signs a pilot, pays a deposit, or prepays | Economic commitment | Strongest early signal |
This is not an argument to refuse qualitative research. Interviews are how you learn what to test. It is an argument not to graduate from “interesting conversations” to “we have product-market fit.” Strategyzer makes the same discovery-versus-validation distinction: early discovery is directional, while later validation asks for a more meaningful exchange. Read its explanation.
The five tests worth running before a full build
1. Problem interviews
Run 10–15 conversations with people who fit one segment and have recently encountered the problem. Your goal is not a statistically representative survey. Your goal is to learn whether there is a coherent pattern worth testing.
Write down exact phrases, current tools, frequency, stakes, and whether someone has already spent money. After every five conversations, review your notes. If the stories are diffuse, narrow the segment or reconsider the problem.
2. The smoke-test landing page
Write one page that names a specific customer, problem, outcome, and next step. Do not promise a feature inventory.
Weak: “AI-powered workflow automation for modern teams.”
Stronger: “Turn a completed customer interview into a shareable insight brief in ten minutes, without copying notes between tools.”
Send the page only to channels where the defined customer already spends time. Measure qualified actions: booked conversations, demo requests, replies with context, or applications for a pilot. A page with random traffic and a vague waitlist is not reliable evidence.
3. A concierge test
Deliver the promised outcome manually before automating it.
If you think you can create weekly competitive intelligence for ecommerce brands, produce it by hand for three brands. If you think you can turn support tickets into product insight, do the synthesis manually with their exported tickets. You will learn whether the output matters, what quality means, and which part deserves software.
This approach protects founders from building the wrong automation. It also creates the first real customer relationship.
4. A prototype usability test
Use a clickable mockup, short demo, or intentionally limited working product to test the workflow. Ask people to complete a real task while you observe.
Do not explain every screen. Confusion is data. The purpose is to learn whether the interface and mental model make sense—not to collect praise for visual polish.
5. A paid pilot or pre-commitment
The most revealing early test is a concrete commitment. Depending on your model, that can be a paid pilot, a letter of intent, a deposit, a pre-order, a procurement introduction, or permission to install the product in a real workflow.
The amount matters less than the cost of saying yes. A $50 prepayment, from the exact person you need to serve, can teach more than 500 casual waitlist signups.
| Test | What to do | What to look for |
|---|---|---|
| Problem interviews | Run 10–15 conversations with people who fit one segment and have recently encountered the problem. | Exact phrases, current tools, frequency, stakes, and whether someone has already spent money. |
| The smoke-test landing page | Write one page that names a specific customer, problem, outcome, and next step. | Booked conversations, demo requests, replies with context, or applications for a pilot. |
| A concierge test | Deliver the promised outcome manually before automating it. | Whether the output matters, what quality means, and which part deserves software. |
| A prototype usability test | Ask people to complete a real task while you observe. | Whether the interface and mental model make sense. |
| A paid pilot or pre-commitment | Ask for a paid pilot, a letter of intent, a deposit, a pre-order, a procurement introduction, or permission to install the product in a real workflow. | A concrete commitment. |
Price earlier than feels comfortable
Many founders postpone pricing because it makes an early conversation feel awkward. But willingness to pay is often the central business question.
You do not need a final pricing page to learn. Offer a clear early arrangement: “We are testing this with five teams at $___ per month; in return, you get hands-on onboarding and influence over the product.” Then listen carefully to the response.
A refusal is useful when it contains a reason:
“We have no budget owner for this.”
“We would buy this if it integrated with X.”
“This is useful, but it only happens twice a year.”
“Our current agency already handles it.”
Those are business-model facts. They are more valuable than generic feedback.
Stripe’s founder guidance on getting the first customers is useful here: early sales work is hands-on, specific, and inseparable from learning. Do not delegate the learning too soon.
Set the decision rule before the experiment
Experiments fail when founders decide what the result means after seeing it.
Write a small test card before launching:
Hypothesis: Solo B2B SaaS founders who recently launched will pay to turn launch feedback into a prioritized follow-up plan.
Test: Offer a manually produced feedback synthesis to 20 qualified founders.
Success: At least 6 reply, 3 book a call, and 2 agree to a paid $99 pilot.
Failure: Fewer than 2 qualified calls, or the recurring objection is that the problem is too infrequent.
Decision: Continue, change segment/message, or stop.The numbers will vary. The discipline is what matters. Define a result that changes your next action.
A four-week validation sprint
Week 1: Map risk and recruit
Write the top five assumptions.
Rank them by impact and evidence.
Choose one customer segment.
Recruit 10–15 interviewees through direct outreach, communities, former colleagues, and warm introductions.
Prepare a neutral interview guide.
Week 2: conduct interviews and synthesize
Run the conversations.
Record recurring jobs, triggers, workarounds, language, and purchasing constraints.
Write a one-page problem brief: customer, painful moment, existing approach, consequence, and open questions.
Kill assumptions that do not survive the evidence.
Week 3: test the promise
Build a single-purpose landing page or prototype.
Create one concise outreach message for the segment.
Run a concierge test with the most promising respondents.
Track meaningful actions, not page views alone.
Week 4: ask for commitment and decide
Offer a pilot or prepayment.
Document objections word-for-word.
Compare results with the prewritten success rule.
Choose: build the narrowest useful version, retest with a changed hypothesis, or stop.
| Week | Focus | Actions |
|---|---|---|
| Week 1 | Map risk and recruit | Write the top five assumptions; rank them by impact and evidence; choose one customer segment; recruit 10–15 interviewees; prepare a neutral interview guide. |
| Week 2 | Conduct interviews and synthesize | Run the conversations; record recurring jobs, triggers, workarounds, language, and purchasing constraints; write a one-page problem brief; kill assumptions that do not survive the evidence. |
| Week 3 | Test the promise | Build a single-purpose landing page or prototype; create one concise outreach message; run a concierge test; track meaningful actions. |
| Week 4 | Ask for commitment and decide | Offer a pilot or prepayment; document objections word-for-word; compare results with the prewritten success rule; build the narrowest useful version, retest with a changed hypothesis, or stop. |
Stopping is not wasted work when it prevents six months of building the wrong thing.
Common traps
Testing the solution before the problem. A prototype can make an unclear problem feel persuasive for 20 minutes. Start with behavior.
Using friends as the market. Friends are useful for referrals and encouragement, not neutral evidence.
Asking for preferences instead of commitments. “Which feature would you use?” is less useful than “Will you try this next Tuesday with your own data?”
Counting an audience that cannot buy. Readers, followers, and users may differ from buyers. Identify the buyer early.
Treating AI output as customer research. AI can help create interview guides, summarize notes, or generate alternatives. It cannot replace conversations with the people whose behavior you need to understand.
Keeping the scope broad to preserve optionality. Broad messaging often makes every result ambiguous. Narrow tests produce clearer decisions.
The goal is not certainty
No early test proves a company will work. Validation reduces uncertainty; it does not remove it.
The right outcome is a better next decision: build a smaller thing, change the customer, raise the price, choose a different channel, or walk away before sunk cost becomes strategy.
Once you have a narrow product people are using, you can prepare the public story: a clear product page, honest maker context, screenshots, categories, and a feedback path. Crowdstax’s launch playbook is designed for that later transition from validation to launch.
A founder’s advantage comes from testing intuition against reality early enough to change course.