The 70% Decision, Reward the Learning
Commit at 70% confidence with an explicit hypothesis, then iterate — and reward learning, not outcomes.
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 5
- Confidence
- 95%
Gupta's decision doctrine: it's not about making the right decision, it's about making the decision. You always operate on imprecise information, and only commitment produces high-fidelity new information. Commit when the decision is roughly 70% right, make the underlying hypotheses explicit so everyone can learn from them, and build a risk-taking culture by rewarding the learning rather than the outcome.
Origin
Anneka Gupta; her parting advice to her LiveRamp colleague Rachel Wan was 'it's not about making the right decision, it's about making the decision.' The learning-over-outcome culture point echoes Meta's ship-and-learn culture, which Lenny Rachitsky attributes to Zuckerberg on the episode.
Core principles
- 01Product leaders always operate on imprecise information — more data points are usually an excuse.
- 02You only get high-fidelity information after committing; before that, everything is hypothetical.
- 0370% right is enough — the remaining 20-30% is iterable in either direction.
- 04A decision without a stated hypothesis can't be learned from when it fails.
- 05Reward learning, not outcomes, or nobody will make a bet again.
How to run it
- 1
Name the analysis paralysis
When you catch yourself saying 'if I just had this one more data point, then I could decide', recognise it as paralysis, not diligence.
- 2
Write the hypothesis stack
Before committing, state the hypothesis or series of hypotheses and assumptions informing the decision — e.g. 'this segment will pay for this because it solves an urgent enough need; here is the evidence we have, and here is what we don't know.'
Pro tip Explicitly list what you don't know alongside the evidence — that's the part you'll test.
Watch out A decision made without an articulated hypothesis produces no learnable signal when it fails.
- 3
Commit at ~70%
Once the decision is roughly 70% right, commit. Don't make it uninformed, but stop waiting. The commitment itself is what generates the high-quality information you were waiting for.
- 4
Test the hypothesis and iterate the remaining 30%
Keep checking whether the hypothesis holds and shift direction accordingly. Accept that you may throw away 20% of the work — that's cheaper than making no decision at all.
- 5
Post-mortem against the original hypothesis, and reward the learning
When something doesn't work, go back to the stated hypothesis and identify what you learned that you didn't know before. Reward that learning explicitly, not the outcome, so people keep taking bets.
Pro tip Even a bad decision teaches you something about your customers or business that you can use in an unrelated context.
Watch out If you reward outcomes, the rational move for your team is to make no decisions at all.
In the wild
Gupta's team built a genuinely high-value product and decided not to monetize it. After launch they realised they should have. They then had to work out how to package new capabilities to monetize it without clawing back what existing customers already had.
→ A costly correction — but the learning about monetization only became available after shipping, which was exactly the point of committing.
Repeatedly, Gupta's teams built capabilities for a new persona's problems, then discovered they had misunderstood how hard it would be to sell to that persona through their own organization.
→ She now insists on knowing how something will be sold and who will sell it before building it — otherwise the best product gets zero adoption.
Common mistakes
Waiting for the one more data point
The extra data point rarely arrives and never resolves the ambiguity. Meanwhile you generate zero high-fidelity information, because only commitment produces it.
Building before you know who will sell it
Gupta made this mistake many times: teams ship capabilities for a new persona without validating that anyone in the organization is ready or able to sell to that persona, and adoption is zero regardless of product quality.
Rewarding outcomes in a risk-taking culture
If a bad outcome is punished even where the hypothesis was well-formed and the learning was real, people stop making decisions — which is the worst outcome of all.
Is it for you?
Best for
Product leaders and managers stuck in analysis paralysis, and leaders trying to build a culture where teams take real bets.
Not ideal for
Irreversible, high-blast-radius decisions (security, regulatory, one-way doors) where the cost of a 30% error is not iterable.
From the transcript
“it's very easy to get into analysis paralysis before making a decision and say well if I just had this one more data point”
“as long as your decision is like 70% right you can iterate on that 20 30% in either direction”
“just make a decision don't make it uninformed but have a strong hypothesis and then just keep testing whether that hypothesis is accurate or not”
“I think the way to make a culture of risk-taking and people willing to make these bets and go out on a limb is to…”
From the episode
Becoming more strategic, navigating difficult colleagues, harnessing founder mode, and more
Anneka Gupta (Chief Product Officer at Rubrik)