Monetization Validation
Willingness to Pay Validation: How to Test It Before You Build
Why interest is not payment, the five-rung signal ladder from polite words to real money, and a concrete pricing experiment you can run this week — before you write code.
· Updated · Yibud· 18 min read
On this page
Quick answer
Willingness to pay validation is the discipline of finding out whether a real person will trade real money for your solution before you build it. Interest is not payment. Need is not payment. Compliments are not payment. Only a real transaction tests whether a customer actually values the solution enough to spend on it — and that transaction is what you must set up before committing months of work.
The cheapest way to do it is a small pricing experiment: a one-paragraph offer, a Stripe checkout page, ten specific people in your audience, and a week of measuring what happens. The methodology is the same whether you sell to consumers or to B2B buyers, whether the price is $9 or $9,000, and whether the product is software, a service, or a physical good.
Key takeaways
- Interest, need, and compliments are not payment. A "would you buy this?" answer measures enthusiasm, not demand. The only honest test is a transaction.
- Five signals rank from weakest to strongest: email signup, reservation deposit, pre-order, letter of intent, and a real paid pilot. Each rung costs the customer more — and tells you more.
- The seven-step validation framework is Problem → Customer → Value → Price → Payment Signal. Skip a rung and the test stops measuring what you think it measures.
- Test at the real price first. Discounts contaminate the signal. If you cannot get ten paying customers at the planned price, you do not have a pricing problem; you have a value problem.
- The polite-yes problem is real. Researchers have documented the intention-behavior gap for decades. The only cure is a transaction.
- The cheapest experiment that fits your audience is the right one. A landing page, a manual service, a paid prototype, or a no-code tool — pick one this week, not next quarter.
Why this matters
I have watched three founders run the same sequence in 2025 and 2026. They each interviewed fifteen to twenty people about a tool or service. Each heard the same encouraging pattern: most respondents had the problem, most had tried workarounds, most said they would happily pay for something better. Each founder built, launched, and watched conversion rates between 8% and 18% — close to the worst-case they had planned for.
The pattern is not dishonesty. The respondents were not lying. They were answering a hypothetical question in a low-stakes moment with a hypothetical version of themselves, generous and well-budgeted. Three months later, the moment the credit card actually had to come out, the version of them that showed up was distracted, busy, and already paying for a workaround that was good enough.
This article is the smallest set of steps that prevents that pattern. Not pricing theory. Not "ten pricing tips." A concrete plan to find out, in seven days and for under fifty dollars, whether real people will trade real money for what you are about to build.
The deeper treatment — the seven pricing experiments ranked, the signal ladder explained with cases — lives in the pillar How to Test Willingness to Pay Before You Build. The canonical startup validation framework that puts this step in context is in How to Validate a Startup Idea Before Building. The vocabulary used in this article is defined in the Startup Validation glossary.
What is willingness to pay?
Willingness to pay is whether a specific person, in a specific moment, will trade a specific amount of money for a specific solution to a specific problem.
Three things make this definition harder than it looks.
It is a person's behavior, not a person's opinion. Surveys and interviews measure what people say they would do. Transactions measure what people do. The two diverge more often than founders expect. Rob Fitzpatrick, in The Mom Test (2013), made the canonical case that you should never ask whether someone would buy your product; the answer is unreliable. Ask them about the last time they tried to solve the problem instead. The book is short, free to read at momtestbook.com, and the rule still applies.
It depends on the alternative. A customer will pay $20/month for a tool when the alternative is a $200/month incumbent, and $0 when the alternative is a free spreadsheet. The willingness to pay is not a property of the customer. It is a property of the customer, the problem, and the alternative, all at once.
It changes over time. Willingness to pay rises when the problem becomes urgent (the tax deadline, the lost customer, the broken tool). It falls when workarounds improve. The right time to test is when the customer's pain is at its realistic peak, not when they are sitting comfortably in an interview.
A useful way to think about the concept: willingness to pay is the price at which the customer would buy today, not the price they would theoretically pay someday. That distinction is the entire reason a pricing experiment exists.
Why interest is not payment
Daniel Kahneman and colleagues spent decades documenting the gap between what people say they will do and what they actually do. The technical name is the intention–behavior gap. The practical name is "they said yes and then didn't show up."
The reasons are simple. Saying yes in a conversation is socially easy and costs nothing. Saying yes to a real charge is socially expensive and costs something. People default to yes when the cost is zero and to no when the cost is non-zero. The same person who said "I'd happily pay for that" in a Tuesday interview will decline a Stripe checkout on a Friday afternoon because the budget moved, the workaround was fine, the priorities shifted, and the problem was not actually painful enough to remember.
This is not cynicism. People are not lying to you. They are accurately reporting what they would do under conditions that do not exist. The test fails because the conditions are wrong, not because the people are wrong.
The cure is structural. Build a situation where the only honest answer involves money. The whole field of pricing validation is a set of techniques for setting up that situation at small cost.
Why startups need pricing validation
Three reasons, in increasing order of consequence.
First, false demand signals are common. Indie hackers, Reddit threads, Twitter polls, Product Hunt upvotes — every channel that lets someone express interest without paying produces signal that is real but misleading. Three thousand Twitter likes is not the same as three thousand paying customers. The gap between them is what pricing validation closes.
Second, building without buyers is the most expensive failure mode. A founder who builds before validating can spend three to nine months of runway on a product that has no real market. The cost is not just the months. It is the opportunity cost of the next idea, the morale damage of the failed launch, and the statistical fact that founders who launch once rarely launch again. The first failed launch is recoverable. The second one usually is not.
Third, pricing assumptions are the assumption nobody tests. Most founders test the problem and the customer. Few test the price. They pick a number, set a Stripe checkout, launch, and discover that the price was either too low (they cannot support the cost) or too high (nobody buys). Pricing validation is what catches the price assumption before the launch, not after.
How to validate willingness to pay
There are five methods that produce useful signal. They run from cheapest to most expensive, and they roughly track the strength of the signal they produce.
1. Customer interviews about workarounds
The cheapest, weakest, and most often misread method.
The right question is not "would you pay for this?" The right question is "what did you do last time you had this problem, and how much did that cost you?" Rob Fitzpatrick's Mom Test (2013) lays out the discipline: ask about their life, not your idea. A customer who paid a freelancer $300 to solve the problem last Tuesday has demonstrated willingness to pay $300 for a solution, regardless of what they say in an interview about your specific product.
The output of an interview is a number — what the customer currently spends on the workaround — and a list of complaints about the workaround. Both are signal. Neither is proof.
The interview is the cheapest way to find out whether the problem is real and what people currently pay to solve it. It is not a willingness-to-pay test. It is a problem-validation test that incidentally produces a price anchor.
2. Pricing experiments
The middle method, and the one most worth running this week.
A pricing experiment is a controlled setup that puts a real price in front of real customers and counts what happens. There are four variants.
-
A landing page with a checkout. Describe the product, show what it does, state a price, add Stripe Checkout, drive some traffic. Measure how many visitors pay. The point is not to convert at scale; the point is to find the conversion rate at one price point.
-
A Stripe payment page with no product. Even simpler. A clear description of what you are building, a price, a payment form, a note that pre-orders will ship when the product is ready. If people pay, you have evidence. If they do not, you have a different kind of evidence.
-
A manual service. Find three people who would be your customers. Offer to do the work for them, by hand, before you have built anything. If they pay for the manual version, the value is real and the price is acceptable. If they do not, no amount of automation will make them pay for the automated version later.
-
Paid consulting. Offer an hour with five target customers at $50, $100, or $200 on the exact topic your product would address. If they pay, you have validated both demand and a price point. If they do not, the topic is not yet painful enough to be worth their money.
The cheapest experiment that fits your audience is the right one. The wrong choice is to spend another week choosing.
3. Landing page tests
A landing page test is the cheapest method for showing that the description of the product can convert. It is not, strictly, a willingness-to-pay test, because a landing page test usually measures email signup or waitlist join, not payment.
A landing page test becomes a willingness-to-pay test when the CTA is "Buy now" rather than "Join the waitlist." The distinction is small but real. A waitlist measures curiosity. A checkout measures commitment.
The pattern works. Joel Gascoigne ran a two-page Buffer site in 2010 with pricing tiers and a checkout. Real money changed hands before any code was written. Drew Houston recorded a three-minute Dropbox demo video and posted it on Hacker News; the waitlist exploded. The video was not a product. It was a way to test whether people who had not used the product would still want to use it. They did.
A landing page test is the cheapest method for testing a new idea at scale. The downside is that the conversion rate at low traffic is noisy. A 2% conversion rate on 100 visitors is not the same as a 2% conversion rate on 10,000 visitors. Plan to drive at least 500 qualified visitors before concluding there is no demand.
4. Pre-orders
A pre-order is a stronger signal than a landing page test. The customer has agreed to pay full price (or close to it) for a product that does not exist yet, on a stated delivery date, with a real refund policy if it does not ship.
The pre-order model works well when the product is describable without screenshots. Email tools, scheduling tools, simple workflow tools. It works less well for products that need to be seen to be evaluated: design tools, video editors, complex dashboards.
A pre-order test has three components. A clear description of what will be built. A clear delivery date. A clear refund policy. The price is the price you intend to charge at launch, not a discounted launch price. Discounts contaminate the signal — see Common Mistakes below.
5. Paid pilots
The strongest pre-build signal, especially for B2B.
A paid pilot is a small group of customers who pay you, in advance, for an early version of the product, with the understanding that they will give feedback and you reserve the right to refund if it does not work out.
The pattern is well-documented. Superhuman ran a private beta by design for years: you could not sign up, you had to be referred, you joined a waitlist once invited, and you paid $30/month for an unfinished email client once accepted. The willingness to pay for an unfinished product was the test. The product did not ship publicly until they had validated demand at scale, and they validated at scale through payment, not signups.
A paid pilot is the right method when the deal size is large enough that you cannot get to ten transactions in a week, but small enough that the customer can say yes without a procurement cycle. For enterprise software with annual contracts above $50,000, a paid pilot is usually a paid proof-of-concept for two to four weeks at a fraction of the eventual price.
The validation framework: Problem → Customer → Value → Price → Payment Signal
The five-step framework below is what every pricing experiment is a sub-test of. Each rung must hold for the next rung to be meaningful.
Problem. A specific person has a specific problem often enough that solving it is worth their time. If this rung fails, the rest is irrelevant. The cheapest test is a customer interview that asks "what did you do last time?" The output is a count of how many people have the problem and how often.
Customer. A specific, reachable group of people have the problem and are not currently well-served by alternatives. The cheapest test is a customer-discovery conversation that asks "what are you using today, and what do you hate about it?" The output is a list of complaints and a list of where these people gather (subreddits, Slack groups, conferences).
Value. A proposed solution would meaningfully improve the customer's situation. The cheapest test is a solution interview that asks "if a tool did X, would that change what you do?" The output is a count of how many respondents describe a behavior change, not just an opinion.
Price. A specific dollar amount, paid at a specific cadence, would make the exchange worthwhile for both sides. The cheapest test is the pricing experiment described above. The output is a conversion rate at one price point, or a list of objections that show up in replies.
Payment Signal. A specific transaction, by a specific person, with a specific payment method, has actually happened. The cheapest test is the paid pilot or pre-order described above. The output is a count of real paying customers and a list of who they are.
The framework is sequential. A founder who has not tested the customer rung should not run a pricing experiment yet, because they will not know whether a low conversion rate is a price problem or an audience problem. A founder who has not tested the value rung should not run a paid pilot, because they will not know whether low retention is a value problem or a delivery problem.
The framework is also cumulative. Each rung produces evidence that the next rung depends on. A founder who skips the interview rung and jumps straight to a Stripe checkout can still learn something — they will learn the conversion rate at one price point — but they will not know whether the conversion rate is high because the audience is good or because the price is too low.
Common mistakes
These are the failure modes I see in roughly the order founders make them.
Asking "would you buy this?" in an interview. The single most common mistake. Rob Fitzpatrick documented the failure mode in 2013; founders keep making it in 2026. The answer is unreliable. Ask about their life instead.
Confusing compliments with demand. "This sounds great!" is not the same as "I will pay you $50/month for this." Compliments measure enthusiasm. Demand measures transactions. The two are independent.
Choosing a price at random. Many founders pick a round number ($9, $29, $99) without testing it. The right price is the price at which a real customer pays today, not a guess based on competitor pricing or industry averages. Test it.
Charging too late. Many founders wait until the product is "ready" before asking anyone to pay. The product is never ready. There is always one more feature. By the time you ask, you have trained your audience to expect the product for free. Charge the first moment you have something anyone could pay for. Even a manual version. Even a clickable prototype.
Discounting immediately. The instinct to offer 50% off the first year, a "founder's price," or "early-adopter pricing" comes from fear. It is almost always a mistake. The discount trains customers to expect the lower price and makes the test inconclusive: you do not know whether they would have paid full price or only the discounted price. Test at full price first.
Ignoring existing spending. If your target customer already pays $200/month for a tool that does not quite solve the problem, that is a budget you have already partially de-risked. Many founders underprice because they do not realize how much money is already flowing in the adjacent space. Look at what your customers already pay. Price in that range, not below it.
Confusing a quiet launch with low demand. If you build a landing page, drive 100 visitors, and nobody pays, the problem might be the offer, the audience, or the price — not the willingness to pay. Drive 500 qualified visitors before concluding there is no demand. If they still do not pay, you have signal.
Changing the product based on the first "no." One person saying "I would not pay for this" is not a market signal. Three pre-orders and one refund is not a market signal. Look for patterns. Do not react to single data points.
Treating ability to pay as willingness to pay. A common conflation. Ability to pay is whether the customer has the money. Willingness to pay is whether they would spend it on your solution specifically. The two are independent. A customer can have the money and not want to spend it on you. A customer can want to spend it on you and not have the money. Willingness is what you test with a real charge.
Stopping at "interest." Email signup, waitlist join, "sounds great" — these are not payments. They are polite noises. The signal you need is a transaction. Keep going until you have one.
FAQ
What is willingness to pay validation?
Willingness to pay validation is the discipline of finding out whether a real person will trade real money for your solution before you build it. It is the step between "people say they want this" and "people actually pay for this." The only honest test is a transaction. Surveys and interviews measure enthusiasm, not demand. The full framework lives in How to Test Willingness to Pay Before You Build.
How do startups validate pricing?
The cheapest method that fits your audience. Most founders run a one-week experiment: a one-paragraph offer, a Stripe checkout page, ten specific people in the audience, and a measurement of who pays. The offer is described clearly, the price is the planned launch price (no discounts), and the audience is specific enough that you can reach ten of them by email or DM. The output is a conversion rate at one price point and a list of objections in the replies. If three or more of ten pay, the price is roughly right and you have evidence to keep building. If zero of ten pay, the offer or the audience is the problem, not necessarily the price.
What is customer willingness to pay?
Customer willingness to pay is the price at which a specific customer, in a specific moment, would buy a specific solution to a specific problem, given the alternatives they currently use. The phrase "customer willingness to pay" emphasizes that the willingness belongs to a specific person, not to a market segment. A segment does not pay; a person pays. The cheapest test is a transaction with a specific person.
How do you test if customers will pay?
Set up a small pricing experiment. Describe the offer in one paragraph. Build a payment page (Stripe Checkout is fine). Reach ten people in your audience by email or DM. Ask them to pay. Measure what happens. The whole thing takes a week and costs less than $50 in tooling. If three or more of ten pay, you have evidence. If zero of ten pay, you have learned something — usually about the offer or the audience, not necessarily the willingness to pay itself.
Is customer interest enough?
No. Customer interest is necessary but not sufficient. Many founders have watched fourteen out of twenty interview respondents say "I'd happily pay" and then watched two out of fourteen actually pay at launch. The polite-yes problem is real. The cure is a transaction. Interest is the input; a transaction is the output. Stop when you have a transaction, not when you have interest.
When should founders test pricing?
Before they build anything that costs more than a week of work. The seven-day pricing experiment (one-paragraph offer, payment page, ten specific people, one price point) can be run as soon as you have an audience or a way to reach one. The cost is under $50 and a week of effort. The output is either a real conversion rate or a real list of objections. Either is useful. Both beat guessing.
What's the difference between willingness to pay and ability to pay?
Ability to pay is whether the customer has the money. Willingness to pay is whether they would spend it on your solution specifically. The two are independent. A customer can have the money and not want to spend it on you (high ability, low willingness). A customer can want to spend it on you and not have the money (high willingness, low ability). Pricing validation tests willingness, not ability. The mistake is testing the wrong one and treating the result as the right one.
What is a paid pilot?
A paid pilot is a small group of customers who pay you, in advance, for an early version of the product, with the understanding that they will give feedback and you reserve the right to refund if it does not work out. A paid pilot is the strongest pre-build pricing signal, especially in B2B, because the customer has done the thing that actually matters: they have given you money. The pattern was used at length by Superhuman from 2015 to 2018: a private beta you could only enter by referral, paid waitlist once invited, slow onboarding by design. The willingness to pay for an unfinished product was the test. The canonical definition lives in the Startup Validation glossary.
How is willingness to pay different from price elasticity?
Willingness to pay is a binary question for a specific customer at a specific moment: would they pay this price? Price elasticity is a market-level question: how does demand change as price changes? A pricing experiment produces a willingness-to-pay result. A series of pricing experiments at different prices produces a price-elasticity curve. For solo founders and indie hackers, the willingness-to-pay result is what matters. The curve is useful when you already have hundreds of customers and want to optimize revenue.
Summary
Willingness to pay validation is the discipline of converting polite interest into real payment before you build. Interest is not payment. Need is not payment. Compliments are not payment. Only a real transaction tests whether a customer values the solution enough to spend on it. The five signal strengths, from weakest to strongest, are email signup, reservation deposit, pre-order, letter of intent, and a paid pilot. The seven-step framework is Problem → Customer → Value → Price → Payment Signal, and each rung must hold for the next rung to be meaningful.
The cheapest experiment that fits your audience is the right one. Run it this week. Test at the planned price. Do not discount. Reach ten specific people. Measure what happens. If three or more pay, you have evidence. If zero pay, you have learned something useful. Either way, you have less uncertainty than you had before, and you have spent a week instead of three months.
The goal is not to convince people to buy. The goal is to find out whether they already value solving the problem. Revenue is stronger than compliments. Conversations reveal problems. Payments reveal priorities. The gap between "I think this might work" and "someone paid me to find out" is the gap that separates an idea from a business.
Related reading
- How to Test Willingness to Pay Before You Build — the deep playbook on the six pricing experiments, the polite-yes problem, and the seven-day payment plan.
- Problem-Solution Fit Validation — the rung before willingness to pay: confirms the proposed solution addresses a real, recurring problem the customer has already tried to solve with workarounds.
- How to Validate a Startup Idea Before Building — the canonical four-stage validation framework this article sits inside.
- Startup Validation Checklist — the operational checklist that turns the framework into a week-by-week plan.
- How to Find Your First Customers Before You Build — the conversation discipline that produces the audience you test the offer against.
- The Startup Validation hub — the full reading path and topical taxonomy.
- The Startup Validation glossary — plain-language definitions of willingness to pay, pricing validation, paid pilot, value proposition, and customer demand.
- Startup MRI Methodology — how the rule engine surfaces pricing assumptions in the structured report.
What to do next
If you have read this far, the question is what you will do in the next seven days.
The smallest useful action is a one-paragraph offer and a Stripe checkout page. The next is reaching ten specific people. The third is asking them to pay. None of these requires a finished product. None requires permission. None requires a team.
If you would like a structured second opinion on which assumptions in your idea carry the most pricing risk before you start asking for money, Startup MRI's validation analysis helps. It takes about five minutes and surfaces the parts of your idea most likely to break under real-world pressure, so the pricing experiment you run this week is the one with the highest signal.
For a worked example of what a real validation report looks like, see the SaaS validation report example, the AI startup validation report example, or the mobile app validation report example. Each shows every section your own report will contain, including the pricing-assumption callout.
The right validator landing depends on the audience: the Startup Idea Validator for general ideas, the Startup Idea Evaluator for founders who use "evaluate" as the verb, and the Startup Score Calculator for a numeric 0–100 read on the same six dimensions.
Revenue is stronger than compliments. Run the experiment. See who pays. Build what they already value.
Continue learning
Where to go from here
These pieces are grouped by topic, not publication date — pick the one that matches the question you are working on right now.
More in ValidationSee all topics →
Validation Guide
Startup Failure Analysis: How to Read a Failed Startup the Right Way
Startup failure analysis is the discipline of converting documented startup failures into testable assumptions. Five real cases — Quibi, Webvan, Juicero, Homejoy, WeWork — analyzed with a seven-rung framework, then turned into the validation experiments a solo founder can run this week.
26 min read
Validation Guide
Lean Startup Validation: How To Choose, Design and Interpret Validation Experiments
How to use Eric Ries's Build-Measure-Learn loop to pick the next validation experiment — including the five-question decision framework, decision-threshold thinking, three labeled hypothetical examples, and the failure modes that distort the loop before the founder notices them.
17 min read
Validation Guide
Problem-Solution Fit: How to Know Your Solution Solves a Real Problem Before You Build It
Problem-solution fit is the state where a defined customer has a defined problem and a defined solution would meaningfully improve their situation. The five rungs of evidence that prove the fit is real, the six failure modes that show it isn't, and the 14-day validation framework that separates real pain from polite enthusiasm.
22 min read
Validation Guide
MVP Validation: How to Test a Minimum Viable Product Before You Build It
MVP validation is the discipline of testing the smallest useful version of your idea before committing months to a full build. Six methods, a five-step framework, and the seven failure modes that show up before the founder notices them.
20 min read
Validation Guide
Product-Market Fit Validation: How to Know You Have It Before You Announce It
Product-market fit is observed, not declared. The four signals that show you have it, the seven failure modes that show you do not, and a 30-day validation framework that separates real retention from paid acquisition.
22 min read
Validation Guide
How to Validate an API Startup Idea Before You Build It
The API- and developer-tool-specific tests for technical buyers, integration cost, trust, documentation prototypes, and design-partner pilots — before you write the first endpoint. A practical handbook for API founders, SDK builders, infrastructure product teams, and developer-tool indie hackers.
18 min read
Validation Guide
How to Validate a B2B Startup Idea Before You Build It
The B2B-specific tests for buying committees, procurement, ROI proof, founder-led sales, and the manual pilot — before you write code. A practical handbook for SaaS founders selling to businesses, enterprise software teams, and technical founders.
17 min read
Validation Guide
How to Validate a Chrome Extension Idea Before You Build It
The browser-extension-specific tests for Manifest V3 fit, Chrome Web Store policy, distribution outside store search, willingness to pay, and unlisted pre-launch testing — before you ship a packaged extension. A practical handbook for indie hackers, SaaS founders, AI tool builders, and browser extension developers.
16 min read
Validation Guide
How to Validate a Mobile App Idea Before You Build It
The mobile-app-specific tests for problem, retention, onboarding, distribution, and willingness to pay — before you ship a binary to the App Store. A practical handbook for consumer, productivity, lifestyle, health, education, and local-service apps.
17 min read
Validation Guide
How to Validate a Marketplace Startup Before You Build It
The marketplace-specific tests for supply, demand, liquidity, take rate, and two-sided interviews — before you build the platform. A practical handbook for B2B, consumer, local, creator, and talent marketplaces.
17 min read
Validation Guide
AI Startup vs SaaS Startup: How Validation Is Different
Why AI startups need workflow, output-quality, and dependency tests on top of every SaaS validation question — and the cheapest experiment that proves each one before you build.
18 min read
Validation Guide
How to Validate an AI Startup Idea
Validate an AI startup idea by testing workflow demand, output quality, pricing, model dependency, distribution, and defensibility before building.
21 min read
Validation Guide
How to Validate a SaaS Idea Before You Build It
The five recurring-revenue assumptions that decide whether a SaaS product survives month six, and the cheapest experiment that tests each one — before you write code.
16 min read
Monetization Validation
How to Test Willingness to Pay Before You Build
The polite-yes problem, six pricing experiments you can run this week, and a seven-day plan to ask for money — before you build.
17 min read
Validation Guide
Startup Validation Checklist: Before You Build
21 concrete checks across four validation stages — problem, customer, business, execution — with how to test each one, the common mistake to avoid, and a printable summary.
17 min read
Validation Guide
How to Validate a Startup Idea Before You Build
The four assumptions every startup depends on, the four questions that test them, and the cheapest experiments that produce evidence in 2–4 weeks — before you build.
15 min read
Next in the reading path
Product-Market Fit Validation: How to Know You Have It Before You Announce It
Product-market fit is observed, not declared. The four signals that show you have it, the seven failure modes that show you do not, and a 30-day validation framework that separates real retention from paid acquisition.
MVP Validation: How to Test a Minimum Viable Product Before You Build It
MVP validation is the discipline of testing the smallest useful version of your idea before committing months to a full build. Six methods, a five-step framework, and the seven failure modes that show up before the founder notices them.
Lean Startup Validation: How To Choose, Design and Interpret Validation Experiments
How to use Eric Ries's Build-Measure-Learn loop to pick the next validation experiment — including the five-question decision framework, decision-threshold thinking, three labeled hypothetical examples, and the failure modes that distort the loop before the founder notices them.
See every article on startup validation in one place.
Open the Startup Validation hub →