The Metric Overload Problem
Most product teams I have seen have the same disease: metric overload. They track DAU, WAU, MAU, D1/D7/D30 retention, session length, pages per session, conversion rate, NPS, CSAT, time-to-value, feature adoption, activation rate...
And somehow, with all this data, decisions still get made in meetings based on whoever argues loudest.
The problem isn't insufficient data. It's insufficient decision architecture — the connection between a metric moving and a team taking action.
My Three-Metric Framework
From my internships so far (self-reported; I have no public artifacts from them) and the products I build myself, I've landed on a framework I reach for first:
1. The Health Metric (Are we okay?)
This is the one number that tells you whether the product is fundamentally working. It should:
- Be measurable weekly
- Have a clear "danger zone"
- Not be gameable by a single team
Examples: 7-day retention for consumer apps. Net revenue retention for B2B. Task completion rate for tools.
Illustrative example, not a product I worked on: for a subscription meal-kit service, a good health metric is the share of active subscribers who skipped two or more deliveries in a row. A team might set the danger line at one in five (an invented threshold): above it, the problem is systemic, not a set of isolated cases. For a product where people should come back on their own, a cohort retention floor works too; see Cohorts Before Dashboards.
2. The Focus Metric (What are we improving?)
This is the OKR-level metric your team owns for this quarter. It should:
- Be directly influenced by the team's work
- Move within 4-8 weeks of shipping changes
- Connect to the health metric via a clear hypothesis
Example (hypothetical numbers): "If we improve onboarding completion from 40% to 65%, we expect D7 retention to improve by 10pp because users who complete onboarding are 3x more likely to return."
This is where most teams fail. They pick focus metrics that are too lagging (revenue), too leading (button clicks), or too disconnected from the health metric.
3. The Guardrail Metric (What can't we break?)
Every improvement has a cost. The guardrail tells you when you've gone too far:
- Speed improvements can't hurt accuracy
- Engagement can't come from dark patterns
- Conversion can't sacrifice long-term retention
Illustrative example: a team reallocating paid marketing spend might use customer acquisition cost (CAC) payback period as its guardrail. Budget moves freely between channels, but if payback exceeds an agreed limit (say six months, an invented figure) on any cohort, the team has overcorrected. To test a focus-metric hypothesis without fooling yourself on the way, see Designing a Self-Hosted Experimentation Platform.
Why Three, Not Ten
Three metrics fit in working memory. A PM should be able to answer three questions without opening a dashboard:
- "Is the product healthy?" (Health metric: green/yellow/red)
- "Is our current bet working?" (Focus metric: trending up/flat/down)
- "Are we breaking anything?" (Guardrail: within bounds/approaching limit)
If you need to open a dashboard to answer these, your metrics aren't embedded in the team's workflow. They're just charts.
Implementing This in Practice
Weekly: Check health metric. 30 seconds. If green, ignore it. If yellow, dig deeper.
Bi-weekly: Report focus metric progress. Connect it to specific shipped changes. If it's flat despite shipping, your hypothesis might be wrong.
On every launch: Check guardrails. Did this feature improve the focus metric without triggering the guardrail? Ship and move on. Did it trigger the guardrail? Roll back and understand why.
The Meta-Lesson
The hardest part of this framework isn't picking the three metrics. It's saying no to the others. Teams love to add "just one more metric" until they're back to tracking 40 things and acting on none.
Resist. Three metrics. Three questions. Three decisions. Everything else is analysis, not product management.
