Phase 4: Validate

What: Reveal progressively according to the Exposure Plan and test each belief against reality. After each exposure level, decide whether to continue to the next level, adjust and retry, or cut to Decide.

Thinking mode: Critical thinking. Being honest about what the evidence actually says. On a team, everyone should look at the results, not just the person who framed the hypothesis. Engineers often catch things PMs miss (and vice versa) because they bring different lenses. Solo builders: this is the discipline that separates you from someone who's just shipping and hoping. Show it to real users. Look at the data. Be willing to be wrong.

Methods:

• Internal validation: Does the code work? Do the tests pass? Did it drift from the spec?
• Customer validation: Do users actually care? Does the behavior solve the problem?
• Learning validation: What surprised us? What changed our minds?

Output: Evidence (quantitative or qualitative) that resolves the hypothesis, accumulated across exposure levels.

The reveal cycle

Validate is not a single pass. It runs the Exposure Plan level by level: reveal level 1 to the target audience, observe, collect evidence on the belief, and then make a micro-decision:

• Continue: The belief held. Advance to the next exposure level.
• Adjust and retry: The belief was wrong, but the hypothesis might still hold. Modify the feature or the exposure and retest the same level.
• Cut to Decide: The evidence invalidates the hypothesis or changes the question. Stop revealing and move to Decide with what you know.

This micro-decision after each level is what prevents the Exposure Plan from becoming a checklist you follow mechanically. A belief that fails at level 1 can save you from revealing levels 2 and 3 to a broader audience with a flawed assumption baked in. The whole point of progressive exposure is that you can stop early.

What counts as evidence

LDD doesn't prescribe a universal standard for validation. Different hypotheses require different kinds of evidence, and the right bar depends on the risk you're managing. But good evidence shares a few traits: it comes from outside your head, it can surprise you, and it connects to the hypothesis you actually framed.

Some examples:

• Problem hypothesis ("Users struggle to find relevant results"): Five customer conversations where the pain surfaces unprompted. Not "do you think search could be better?" but watching them search and seeing where they get stuck. If you have to lead the witness, you haven't validated.
• Usability hypothesis ("A filters sidebar will reduce search time"): Three users complete a task with the new UI faster than before, or abandon less. Session recordings or timed tests, not just "looks good" feedback.
• Value hypothesis ("Teams will pay for advanced analytics"): A prospect says "when can I buy this?" or signs a letter of intent. Not a thumbs-up on a demo, not "interesting, keep me posted."
• Technical hypothesis ("The API can handle 10x load"): Load test results that either confirm or break the assumption. Actual numbers, not "it felt fast."

The pattern across all of these: good evidence captures what people do, not what they say they'd do. And the bar scales with the stakes. A solo builder testing a weekend project needs less evidence than a team betting a quarter on a new product line.

Anti-patterns: when you haven't actually validated

• Internal applause: Your team liked the demo. That's not validation, that's consensus.
• Vanity metrics: Pageviews went up. But did anyone do the thing you wanted them to do?
• Leading questions: "Would you use this if it had X?" People say yes to be polite.
• N of 1: One enthusiastic user is signal, not proof. Look for patterns.
• Skipping the uncomfortable test: If your hypothesis has an obvious way to be disproven and you avoided testing it, you validated your comfort, not the hypothesis.