The Leakable Metric
Pick the one metric your customer would be delighted to discover you'd been measuring all along
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 6
- Confidence
- 95%
Weinstein's test for a good product metric: if you accidentally leaked your dashboard to your customers, would they be ecstatic to learn that's what you were measuring? Most instrumentation is internally-oriented (logins, events, machine health) because that's what falls out of your database for free. The Leakable Metric forces you to work backwards from the value the customer is trying to get, express it as a single binary cohort number, then let every tactic be a sub-metric owned by an engineer.
Origin
Developed by Jeff Weinstein while turning around Stripe Atlas. Reading Atlas support tickets in his first week, he realised nobody with a support ticket would ever recommend the product to a friend — and word-of-mouth was the entire go-to-market, because founders ask their friends how to start a company. So the metric became 'percentage of founders who complete incorporation with zero support tickets'. Weinstein explicitly notes the metric only works because it lines up with Atlas's go-to-market; he would not blindly export it.
Core principles
- 01Metrics at their best are a numerical representation of the value you are producing for the customer, measured from the customer's perspective.
- 02Counting is cheap now, so the privilege — and the whole job — is choosing what to count.
- 03Look at multiple metrics, but optimise around exactly one. A small number of metrics forces the tradeoffs and decisions that otherwise get argued about forever.
- 04The metric's name is currency inside the company — brevity and customer-mindedness in the chart title drive cultural buy-in more than the underlying SQL does.
- 05Metrics are almost always wrong for weeks; you have to live in one before you believe it.
- 06A binary cohort measure ('zero support tickets') beats an average ('0.3 tickets') because averages don't map to whether the customer would recommend you.
How to run it
- 1
Ask why anyone would recommend you to a friend
Start from the recommendation question, not from your event schema. Work backwards: what would have to be true, end to end, for this customer to tell a friend about this? For Atlas: they'd need to get their company, get their tax ID from the IRS, and handle the downstream admin — without pain.
Pro tip Read the support tickets first, in bulk. Ask a blunt question: are these happy tickets ('I love this, can you do more?') or sad tickets? The answer usually names your metric for you.
- 2
Define one binary, customer-perspective cohort metric
Convert the answer into a single number measured across a cohort with a hard yes/no per customer. Atlas measured: of founders who started the application, what percentage got all the way through — including the government and IRS waits, plus a two-week buffer — with zero support tickets. Any ticket at all is a no.
Pro tip Apply the leak test: if this dashboard were screenshotted and posted publicly, would customers feel the company was taking its promise to them seriously?
Watch out Averages hide the thing you care about. An average of 0.3 tickets does not tell you whether founders will recommend you; the zero-ticket percentage does.
- 3
Name it so people feel something
Title the chart in plain, short, customer language — 'companies with zero support tickets' — not a database field name stuffed with underscores, mins and maxes. The name should feel good to say out loud in a meeting.
Pro tip Also apply basic hygiene: no meaningless significant digits, and keep every measure on the dashboard on the same x-axis. These aesthetic choices raise how often people voluntarily open the dashboard.
- 4
Put it in one canonical, discoverable place and refuse to look anywhere else
Stripe has an internal 'go/metrics' service. Weinstein's personal rule: if it's not on go/metrics, he won't look at it — no one-off queries, screenshots, or charts pasted into presentations. Bring the URL up in team meetings, every time, not a screenshot of it.
Pro tip Expect stages of grief — week one excitement, week two confusion, week three 'we've been counting it wrong', week four acceptance. Push through; that ritual is what brings the metric into the decision-making culture.
Watch out One-off charts can't be interrogated and never rise to the level of trust required to actually decide anything.
- 5
Choose your tactics, and give each one its own owned sub-metric
Don't let the team find its own path to the number — that's how perverse incentives appear. Decide the tactics deliberately, then set a specific KR per tactic owned by an individual engineer. For Atlas, one driver of tickets was slow risk review, so the tactics were: reduce time-to-final-decision, and reduce overturned rejections.
Pro tip Aim for charts that go up and to the LEFT: for last month's cohort, what percentage got a final decision by day N? You want the curve to climb toward 100% as early as possible. Atlas went from a long tail to ~100% of risk reviews inside an hour.
Watch out This is the guard against the Airbnb failure mode Lenny describes — a team told to reduce support contacts simply made support harder to contact. Explicitly choosing the tactic forecloses the perverse one.
- 6
Put the tactic down when it's won, and hand the tickets to engineers
Once a tactic reaches a level you're comfortable with, stop it and pick it back up later if needed. Meanwhile, assign engineers whole ticket topics: come up with the spec, the scope and the solution, and reply directly to the support email to find out what the customer needed.
Pro tip This turns your engineers into PMs. Weinstein found it more motivating for the team and it freed him from being the single bottleneck scoping and assigning every idea.
In the wild
On taking over Stripe Atlas, Weinstein pulled all the support tickets and found they were uniformly sad — DocuSigns stuck in inboxes, missing co-founder addresses, unreachable 83(b) filing instructions. He set a single metric: percentage of founders completing incorporation with zero support tickets, measured from first page load through the IRS wait plus a two-week buffer. Only 15% qualified. Engineers were each handed ticket topics and built the fixes into the product — automated 83(b) elections, an in-house signing service, everything turned into a click.
→ Over ~18 months the number went from 15% to 85%, and Atlas market share plotted on the same timeframe traced the same shape. One in six new Delaware corporations are now started on Stripe Atlas.
Because Stripe must screen business types and sanctions lists, some Atlas applications went to review, and 'what's happening with my review?' was a major ticket driver. Rather than let the team game the headline number, Weinstein set an engineer-owned KR: for each monthly cohort, drive up the percentage receiving a final decision within N days, and reduce overturned rejections.
→ Essentially 100% of applicants now get their risk decision within an hour, down from a long tail. The tactic was then put down.
Common mistakes
Measuring what your database already emits
Logins are sitting right there as a single event; 'people who accomplished what they came to do' is not. The easy metric is internally-oriented by construction, and optimising it teaches the team to serve the machine rather than the customer.
Optimising a metric without naming the tactic
Hand a team a number and no chosen path and they will find the cheapest path — like hiding the support contact link. Choosing tactics explicitly, each with its own owned sub-metric, is the structural fix.
Exporting someone else's metric
Weinstein warns he would not fully export zero-support-tickets to everyone. It works for Atlas because Atlas's go-to-market is founders recommending it to friends. Your metric, your tactic and your go-to-market all have to line up.
Trusting a metric in its first weeks
Metrics are almost always wrong for many weeks — the definition is subtly off. Teams that make big calls off a brand-new chart, or that quietly abandon it once it looks confusing, never get the compounding benefit of one shared number.
Is it for you?
Best for
A product leader inheriting an existing product with real usage, who needs one number a whole team can wake up to and act on without re-deciding priorities every month
Not ideal for
Very early exploration where you have no customers yet and no repeatable value delivery to count — talk to people instead
From the transcript
“I think metrics at their best are a numerical representation of the value we're prod providing for the for the customer”
“I think you have to find a measure by which it speaks directly to the to what the customer wanted and that if you by…”
“we looked and only 15% of Founders were getting through Atlas with zero support tickets”
“over about 18 months we took that number from 15% to 85 uh we basically just flipped it”
“we look at multiple metrics but we will optimize around one”
“specific KR that was owned by an engineer which is the tactic that we're going to do and so we would not allow ourselves the…”
“my rule is if it's not on go metrics I'm not going to look at it”
From the episode
Building product at Stripe: craft, metrics, and customer obsession
Jeff Weinstein (Product lead)