What Is Validated Learning?

Validated learning is a lesson about your business that's been confirmed by evidence from real customers, not by opinion, a forecast, or the team's enthusiasm. It's the unit of progress in the Lean Startup method. A startup that has shipped three releases and learned nothing about what customers will pay for hasn't progressed much. A startup that has shipped nothing but has proven, with customer behavior, that a core belief was wrong has.

The phrase comes from Eric Ries, and it's one of the most quoted and least practiced ideas in early-stage company building. People nod at it, then go back to tracking signups and shipping features. This guide explains what the term means, how it differs from ordinary measurement, how to design an experiment that produces a validated lesson, and the traps that quietly turn "learning" back into guessing.

What validated learning means

On the Lean Startup principles page, Ries sets validated learning against the way other industries measure progress. His comparison is that progress in manufacturing is measured by the production of high quality goods, while the unit of progress for Lean Startups is validated learning, which he calls a rigorous method for demonstrating progress when one is embedded in the soil of extreme uncertainty.

Two ideas sit inside that definition.

Progress is a change in what you know. A new company doesn't yet know who its customer is, what they'll pay, or how to reach them. Writing code, hiring, and polishing a brand are activities. They only count as progress if they reduce one of those unknowns.

"Validated" means tested against behavior. In an earlier post on validated learning about customers, Ries describes validation as data showing that the key risks in the business have been addressed by the current product. That data doesn't have to be revenue. It might be engagement, retention, or viral spread, whatever tells a believable economic story about the business.

The difference is easy to feel with two statements about the same product:

• "Customers love it. We got great feedback in our demos."
• "Of the 40 trial accounts opened in March, 14 were still using it weekly in May, and 9 of those asked to be invoiced."

The first is a feeling. The second is a lesson that someone else can check, and it points at a decision. Both are about the same product, and only one is validated.

Key Facts: Validated Learning

• Validated learning is one of the principles of the Lean Startup method, and the official site calls it the unit of progress for Lean Startups.
• The same site describes the startup's fundamental activity as turning ideas into products, measuring how customers respond, and learning whether to pivot or persevere.
• Ries describes validation as data that the key risks in the business have been addressed by the current product, and says it needn't be revenue.
• Ries argues that vanity metrics lack causality: a big number doesn't tell you what caused it or how to get more of it.
• A randomized trial of 116 Italian startups found that founders trained to test hypotheses like scientists performed better and were more likely to pivot, without being more likely to drop out early.
• There's no single standard format for a validated-learning experiment. Thresholds and metrics vary by business and stage.

How it differs from ordinary measurement

Most teams already measure things. The difference is what the measurement is for.

A dashboard shows you what happened. A validated-learning experiment tests whether you understood why. If you can't say in advance what result would change your plans, you're reporting, not learning.

The build-measure-learn loop

Validated learning is produced by a loop. The Lean Startup site puts the fundamental activity of a startup as turning ideas into products, measuring how customers respond, and then learning whether to pivot or persevere. Our article on the Lean Startup method covers the full method. Here's the part that matters for this topic.

1. Idea. State a belief that matters, such as "small accounting firms will pay to automate client document collection."
2. Build. Make the smallest thing that can test it. That might be a working prototype, but it might equally be a landing page, a concierge service you run by hand, or a sketch you walk a customer through. A minimum viable product is sized by the question, not by a feature list.
3. Measure. Watch what real customers do. What they do is stronger evidence than what they say.
4. Learn. Compare the result with the prediction. Decide whether to continue as planned or change something.

The trap is treating "build" as the goal. The loop only produces validated learning if "measure" and "learn" are given as much attention as "build". Teams that skip them are shipping, and shipping isn't learning.

It also helps to plan the loop backwards. Decide what you need to learn, then which measurement would show it, then build only as much as that measurement requires. That order is the reason the riskiest assumption test is such a useful companion: it picks the belief to test first.

Vanity metrics versus actionable metrics

Validated learning depends on metrics you can read honestly. Ries's post on why vanity metrics are dangerous makes the case. His favorite example of a vanity metric is "hits". He says it violates the "metrics are people, too" rule: it counts a technical process, not a number of human beings.

His second objection is about causality. If you get a million hits this month, what caused them, and how could you generate more? A single large number can't answer either question. Actionable metrics are the alternative, built from the sub-metrics that do answer those questions.

The table below is our own framing of the idea, not a quote from Ries.

The pattern in the right-hand column is cohorts and rates. Group customers by when they started, then compare groups. If a new onboarding flow works, the cohort that saw it should behave differently from the cohort before it. That comparison is where causal evidence comes from. A running total can't give you that.

Innovation accounting

Ordinary accounting measures a business that already exists. A new venture has no stable base to compare against. The Lean Startup site frames innovation accounting as a response to this: to improve entrepreneurial outcomes and hold entrepreneurs accountable, you need to focus on how to measure progress, how to set milestones, and how to prioritize work.

In practice, teams usually structure this as three steps. This is a common way to apply the idea, not an official specification:

1. Set a baseline. Run a minimal version of the product or offer and record the real numbers, however poor. That's the starting point.
2. Tune toward a target. Run experiments that try to move one metric from the baseline toward the model you need for the business to work.
3. Decide. If the metric moves, persevere. If repeated experiments leave it flat, the model may need to change, which is the question behind a pivot.

This is why validated learning isn't the same as "being data driven". The aim isn't more data. It's a short list of numbers that show whether the business model is getting closer to working.

How to design a validated-learning experiment

A usable experiment fits on a few lines. Write it before you start.

1. Hypothesis. One belief, phrased so it can be wrong. "People in this segment have this problem often enough to pay for a fix" is testable. "Our product is useful" isn't.
2. Test. The smallest action that produces real behavior from real prospects: interviews that end in a request, a landing page with a clear offer, a manual service, a paid pilot.
3. Metric. One number you'll read the same way no matter who's looking. Prefer a rate over a total.
4. Threshold. What result means go, what means stop, and what means "inconclusive, redesign". Set this before you see data.
5. Time box and sample. How long you'll run it and how many people you need to reach before you judge.
6. Decision rule. What you'll do under each outcome. If every outcome leads to the same next step, the experiment isn't informing anything.

Here's a hypothetical example, with invented numbers to show the format. A team believes accounting firms with fewer than 20 staff will pay to automate collecting client documents.

Notice the test doesn't involve building software. The learning comes from asking for a commitment, not from a prototype. For how to run the conversations themselves, see customer discovery.

Evidence that the scientific approach helps

It's reasonable to ask whether testing beliefs this way actually changes outcomes. One of the few controlled studies on the question is Camuffo, Cordova, Gambardella, and Spina's paper in Management Science, "A Scientific Approach to Entrepreneurial Decision Making: Evidence from a Randomized Control Trial".

The authors ran a randomized control trial with 116 Italian startups, collecting 16 data points over about a year. Both the treatment group and the control group received 10 sessions of general training on getting feedback from the market and gauging the feasibility of their idea. The treated startups were also taught to build frameworks for predicting how their idea would perform and to test their hypotheses rigorously, much as scientists do. The control group followed their own intuitions.

The authors report that entrepreneurs who behaved like scientists performed better, were more likely to pivot to a different idea, and were not more likely to drop out in the early stages. They describe the mechanism as improved precision: a scientific approach reduces the odds of pursuing projects with false positive returns and increases the odds of pursuing projects with false negative returns.

Treat this as one study of one sample, not a guarantee. But the pivot result is the interesting one. The treated founders weren't more cautious or more stubborn. They changed direction more often, because they had evidence to act on.

Common traps

1. Testing opinions. "Would you use this?" costs the answerer nothing. Look for behavior: a signup, a deposit, a shared document, a pilot.
2. Setting the threshold after the data arrives. Any result can be framed as a win after the fact. Write the pass line down first.
3. Measuring totals. A number that only goes up can't tell you whether anything you did mattered. Use cohorts and rates.
4. Testing the comfortable thing. Teams like testing what they can build quickly. Test the belief that would end the idea if wrong.
5. Bundling beliefs. If a test covers price, need, and usability at once and fails, you won't know which one broke.
6. Asking friends and family. They're polite. Recruit from the segment you actually plan to serve.
7. Confusing activity with learning. A shipped release, a launch, or a press mention isn't learning unless it changed what you believe.
8. Calling an inconclusive test a pass. If the sample was too small or the wrong people took part, say so and rerun it.
9. Learning without acting. A validated lesson that changes nothing was an expensive status report.

How validated learning connects to other startup ideas

• MVP. The minimum viable product is the tool for getting a lesson. The test of a good one is whether it produces a decision-grade answer quickly.
• Riskiest assumption test. Picks which belief to test next. Validated learning is the broader habit of requiring evidence for every belief that matters.
• Pivot. The decision that follows when repeated experiments show the current model isn't moving. Steve Blank describes a startup as an organization formed to search for a repeatable and scalable business model, and notes that most startups change their model several times before they find one.
• Problem-solution fit. The stage where the lessons add up to evidence that a real problem exists and your solution addresses it. See problem-solution fit.
• Traction. Eventually the lessons show up as signs of demand in the numbers. Our article on what traction is covers how to recognize it.
• Product-market fit surveys. The Sean Ellis test is one structured way to turn customer sentiment into a number you can track.

Validated learning isn't a stage you finish. A company with a product and growing revenue still has beliefs it hasn't tested, about new segments, pricing, and channels. The loop just moves to a different question.

Quick checklist

Before your next experiment, check that you can answer these:

• What single belief are we testing, and what happens if it's false?
• What real behavior from real prospects would count as evidence?
• Is the metric a rate or cohort figure, not a running total?
• What's the pass, fail, and inconclusive line, written before we start?
• What will we do differently under each result?
• Who needs to see the result so it changes a decision?

Related reading

• Lean startup method
• Riskiest assumption test
• Customer discovery
• What is a pivot