The Execution-Idea Review
Separate how well a team worked from whether the bet was right
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 5
- Confidence
- 97%
Armstrong argues that innovative organisations must distinguish a wrong idea executed well from a right idea executed poorly. If every unsuccessful product becomes a black mark, employees learn not to take the risks needed for a company's next act. He cites his understanding of Amazon's Fire Phone: despite the product failure, the team had shipped a phone quickly, so its execution capability could be recognised and redirected; he says he understands that team later became the successful Kindle team. The review therefore examines the bet and the team's work on separate axes, identifies what actually failed, and preserves strong operators for a better opportunity. Tolerance applies to honest, disciplined experiments—not misconduct, hidden risks, or consistently poor execution.
Origin
Armstrong uses Amazon's Fire Phone as an example, while explicitly presenting the internal account as his understanding rather than firsthand knowledge.
Core principles
- 01A failed product does not prove that the team executed poorly
- 02Punishing every failed bet removes the risk tolerance innovation requires
- 03Good execution can be redeployed toward a better idea
- 04Idea quality and execution quality need separate evidence
How to run it
- 1
Reconstruct the bet
State the original thesis, intended outcome, constraints, and evidence available when the decision was made. Avoid judging solely with hindsight.
Pro tip Use the pre-launch decision record where one exists.
- 2
Score execution
Evaluate delivery quality, speed, learning, coordination, and control of known risks. Keep the market outcome out of this first assessment.
Pro tip Ask what the team controlled and whether it handled those factors well.
- 3
Score the idea
Assess whether the customer need, timing, positioning, or strategic premise was sound. Use post-launch evidence without rewriting what was knowable beforehand.
- 4
Classify the failure
Decide whether the main issue was the idea, execution, both, or an external condition. Name evidence for the classification.
Pro tip Allow uncertainty when evidence cannot cleanly separate the causes.
- 5
Respond to the right cause
Recognise and redeploy strong execution when the bet was wrong; coach or change execution when delivery failed. Carry the learning into the next decision.
Pro tip Make the treatment of disciplined failure visible enough to preserve risk tolerance.
Watch out Do not use innovation tolerance to excuse negligence or ethical breaches.
In the wild
Armstrong says his understanding is that Amazon viewed the Fire Phone as a wrong idea with good execution: the team shipped a phone in a short period and was not simply discarded because the product failed. He says he understands that team later became the Kindle team.
→ Execution capability could be preserved and redirected instead of being erased by one product outcome.
Common mistakes
Equating outcome with execution
A poor market result can arise from a flawed premise even when the team delivered the intended product well.
Removing accountability
Separating the axes should improve diagnosis, not protect poor execution from scrutiny.
Is it for you?
Best for
Leaders reviewing experiments, product launches, or strategic bets with uncertain outcomes.
Not ideal for
Failures involving misconduct, concealed evidence, reckless controls, or repeated execution defects.
From the transcript
“there's a difference between they had good execution towards the wrong idea or they had the right idea but bad execution”
“tolerance for failure recognize good execution even toward the wrong idea”
From the episode
Coinbase Founder: The Crazy Journey Of Building A $100 Billion Company: Brian Armstrong