The 10X test (Template inside)
March 12, 2026
Hi Everyone,
When a new initiative gets approved, the team, the budget, and the timeline are usually clear.
What's almost never written down is the conditions under which you'd stop. And that missing piece is why bad bets drag on.
This issue covers a one-page brief that puts those conditions on paper before the work even starts.
What goes on the brief
Before your next initiative gets funded, require this document. It should take less than an hour to write, and the act of writing it often changes the decision.
1. What are you actually betting on?
Write what you believe in a single sentence.
For example, "we believe that adding an AI-powered onboarding flow will reduce time-to-value for mid-market customers by 40% and improve 90-day retention."
If you can't get the thesis into one sentence, the idea isn't clear enough to fund yet. A vague thesis like "we should invest in AI capabilities" gives you nothing to measure against later.
2. Put a number on what winning looks like
This can be revenue, retention improvement, time saved, market share gained – whatever matters for this bet.
Be specific and tie it to a timeframe. "We expect this to add $2M in ARR within 18 months" is useful but "This will drive growth" is not.
3. How much does failure cost?
Write down what you lose if this fails completely.
Include the dollar burn, the team hours, and any operational exposure (like pulling engineers off a core product).
Ramp's CTO Karim Atiyeh uses a simple screen for evaluating bets: look for situations where success delivers roughly 10X the reward while failure costs roughly 1X. If the upside doesn't dramatically outweigh the downside, the bet probably isn't worth taking.
There's an important condition here – your company needs to be able to absorb the loss without endangering core operations. If losing $200K on a failed pilot would cause real damage, that's a different kind of risk than if it's an uncomfortable but manageable write-off.
4. Decide when you'll stop before you start
This is the most important field and the one that's skipped most often.
Write down the specific, measurable conditions under which you will stop the project – before it starts.
Pick at least three from these five categories, making sure you cover more than one type:
- Financial – a revenue or margin target with a clear kill line below it.
- Adoption – a usage or expansion threshold that tells you whether the product has traction.
- ROI / time horizon – a deadline for when the project needs to show measurable returns, compressed for high-burn work like AI pilots.
- Operational – cost or reliability triggers tied to vendors, infrastructure, or delivery capacity.
- Customer sentiment – a satisfaction floor that tells you whether the product is functional but not valued.
Write these criteria collaboratively with the people who'll build and run the project. When the team agrees to the stop conditions upfront, killing the project later becomes a process, not a political fight.
5. Make sure a bad bet stays contained
Write down how you'll protect the rest of the business if this doesn't work out.
That might mean:
- Giving it a small, separate team instead of borrowing people from the existing product
- Testing in a separate environment so nothing touches your live systems and data
- Using different tools and vendors so that shutting it down doesn't pull threads out of your main setup.
The goal is to make sure that when you shut something down, the shutdown is clean and contained.
Fill this in before your next bet
We built a one-page investment brief template based on what's in this issue.
Pick one initiative your team is currently considering and fill it in, especially the kill criteria.
If you can't complete that section, that's the conversation you need to have before anything else moves forward.
Go deeper
👉 Ramp: How we built Ramp by taking asymmetric risks – Karim Atiyeh explains the 10×-to-1× framework they use to evaluate bets across hiring, vendors, and product
👉 McKinsey: Bias Busters — Knowing when to kill a project – how one company cut its project portfolio from 560 to 200 by appointing a full-time "project killer" with clear criteria
👉 Churn FM: What SaaS founders should know before going multi-product – Kovai's founder on shutting down Churn360 and the real cost of pursuing a new product without clear stop conditions
Coming up tomorrow
Tomorrow, we'll look at why leaders are usually the last to notice their own burnout and what to track instead of how you feel.
That's it for today!
P.S. What's the hardest part of killing a project at your company – the data, the politics, or something else? Let us know – we love hearing from you.