No, Then Go
Pre-mortem the risks, understand the breaking points, and then move decisively
- Difficulty
- Easy
- Time to result
- ~days to results
- Steps
- 5
- Confidence
- 93%
No, Then Go is a compact pre-mortem for fast-moving product teams. Before proceeding, the team mentally argues the negative case: what could fail, where scale would break, what unexpected effects might appear, and how the strategy would change under different results. The team does not need to eliminate every possible risk. It needs to understand the meaningful ones, preempt what is inexpensive to prevent, and recognize the signals that would require a response. Once that bounded analysis is complete, the team moves. This converts systems thinking from a reason to delay into a source of speed: anticipated problems produce better experiments and fewer surprises, while less material concerns stop generating endless alignment work. The output is an informed decision and a practical response posture, not a risk-free plan.
Origin
Extracted from Lenny's Podcast as an internal Whatnot moniker Tom Verrilli uses to teach systems thinking without sacrificing execution speed.
Core principles
- 01Think through failure before committing
- 02Distinguish understanding a risk from eliminating it
- 03Model second-order effects and scale limits
- 04Use foresight to accelerate action rather than delay it
- 05Prefer decisive movement after bounded analysis
How to run it
- 1
Define the Move
Describe the decision, expected result, and assumptions clearly enough to test. Avoid debating risks around a vague proposal.
- 2
Argue the Negative Case
List how the move could fail, harm another system, or create an unexpected behavior. Include effects outside the team's immediate scope.
- 3
Plan for Opposite Results
Decide what the team will do if the result is positive and what it will do if the result is negative. If neither outcome changes strategy, reconsider whether the test is useful.
- 4
Preempt Material Failures
Address the highest-impact or easiest-to-prevent risks and define indicators for the rest. Accept that some uncertainty must remain.
- 5
Go
Make the decision and execute once the important failure modes are understood. Use observed results to update the next move.
In the wild
A team proposes an experiment expected to alter discovery behavior. Before launch, it specifies what it will do if the result is green, what it will do if it is red, how the change might behave at far greater adoption, and which downstream systems could be affected. It mitigates the major risks and launches rather than waiting for certainty.
→ The experiment produces actionable learning with fewer unexpected downstream effects.
Common mistakes
Risk Listing Without a Decision
The purpose is to enable informed movement, not to create a comprehensive catalog of reasons to wait.
Solving Every Hypothetical
Teams only need to preempt material risks and understand the others; complete certainty is not the standard.
Ignoring the Next Decision
An experiment has weak strategic value when the team cannot explain what it will do under either result.
Is it for you?
Best for
It is best for teams making fast, consequential decisions under uncertainty.
Not ideal for
It is not ideal for irreversible safety-critical decisions that require formal assurance, testing, or regulatory approval.
From the transcript
“And I think one of the monikers we use internally is no, then go.”
“You don't have to solve all of them. You've just got to think through all of them, and then you end up solving more than…”
“One of the things I ask a lot in product review when someone says, Hey, we want to run an experiment is okay, what do…”
From the episode
This CPO regrets that product management exists