Building before you have earned the right to build is the most expensive mistake in early-stage ventures. Discovery discipline is not slowing down. It replaces hope with evidence thresholds and sunk-cost momentum with explicit kill criteria.
Discovery is not a phase you exit
Teams treat discovery as something that ends at MVP. Mature ventures treat it as a permanent capability: a structured way to decide what deserves engineering time, what deserves a conversation, and what deserves a stop.
Hypothesis cards
A hypothesis card is a single, testable claim, not a feature idea dressed up as strategy. If you cannot state what would falsify it, it is not a hypothesis. It is a preference.
Card structure
One card, one claim. Keep them small enough to test in days or weeks, not quarters.
Core idea: The card is a contract between discovery and build: evidence in, build authorization out.
- We believe [specific user segment] experiences [specific struggle] when [specific context]
- We will know we are right when [observable signal] within [time box]
- We will know we are wrong when [falsification signal]
- If wrong: [kill, narrow, or pivot action]
- Limit active cards to what the team can actually test, usually three to five
- Stack rank by risk to the thesis, not by excitement
- Archive killed cards visibly; they are organizational memory
- Never merge two hypotheses into one card to avoid a hard decision
Evidence thresholds
Evidence without thresholds becomes anecdote. Thresholds without evidence becomes theater. Define both before you run interviews, landing pages, or concierge tests.
Set the bar before the test
Write down what "enough evidence" looks like, qual and quant, while you are still objective.
- Minimum number of independent conversations for a pattern
- Behaviors that count vs. opinions that do not
- What would make you pause build even if enthusiasm is high
Separate signal from noise
Polite interest is noise. Time spent, workaround abandoned, or budget reallocated is signal.
- Ask what they did last time the problem appeared
- Look for repeated action across interviews, not vivid single stories
- Weight evidence from people who pay today for partial solutions
Publish the verdict
End every test cycle with a written pass, fail, or inconclusive, with next action.
- Link evidence to the card; name what changed in the thesis
- If inconclusive, narrow the hypothesis, do not widen scope to salvage it
Interview discipline
Customer conversations fail when they become pitches. The job is to understand the struggle someone is already paying for, in time, money, or reputational risk, not to validate your roadmap.
Interview hygiene
Operational rules that keep discovery honest across a growing team.
- Ask about past behavior: last time the problem cost them something real
- Two-person minimum: one asks, one captures verbatim notes
- Debrief within 24 hours; tag notes to hypothesis cards, not feature names
- Rotate interviewers to reduce founder confirmation bias
Kill criteria
Kill criteria are pre-committed stop conditions. They exist because sunk-cost drift is human, and teams will rationalize one more sprint indefinitely unless the rules were set when minds were clear.
- Define kill triggers on the hypothesis card before testing begins
- Time boxes are kills: no signal by date X means stop or narrow
- Segment kills: if only one customer type shows pull, drop the rest explicitly
- Complexity kills: if delivery requires capabilities you do not have, pause, do not hero-build
Pivot vs. persevere
Persevere when evidence tightens around the same constraint and the same buyer, execution is the bottleneck. Pivot when evidence refutes a core assumption on the card, not when morale dips or a competitor ships a feature.
Persevere signals
Indicators that the thesis is intact and build should deepen.
- Repeatable pull from a defined segment
- Workarounds collapsing toward your proposed job
- Unit-level viability plausible at reachable scale
- Kill criteria not triggered; thresholds trending toward pass
Pivot signals
Indicators that the card, or the segment, should change.
- Strong problem, wrong buyer or wrong moment in workflow
- Desirability without a path to delivery you can own
- Evidence clusters on a adjacent job you did not name in the thesis
- Thresholds failed cleanly, not ambiguously
In our studio practice, discovery discipline gates architecture work: build authorization is earned, not assumed. The outcome of good discovery is not certainty. It is clarity about what you are betting on, what would prove you wrong, and what you will stop doing when the evidence says stop.