The short version
Pick three product KPIs: one acquisition, one value-delivery, one retention or expansion. Some products need a fourth: cost or margin. Watch them every morning for five minutes. For each KPI, write down the healthy band, the investigation threshold, the escalation threshold, and the OKR threshold (sustained miss elevates it from a daily KPI to a quarterly OKR). Most PMs can't name three numbers that, if they moved tomorrow, would change what they ship next week. The product builder can. The instrumentation isn't the hard part anymore. Choice is. Pick three KPIs this week, automate the dashboard with Claude Code next week, install the ritual permanently.
The KPI question I ask every PM I meet
"What are the three numbers that, if they moved tomorrow, would change what you ship next week?"
About 10 percent of PMs I ask have a clean answer. The rest say something like "it depends on the team," or list ten metrics, or describe a dashboard they don't actually look at every day. Some name vanity metrics. Some name lagging KPIs that won't tell them anything actionable until next quarter.
This is the gap between a product manager and a product builder. The builder runs against a small, sharp set of KPIs they look at every single morning. They use the trend in those numbers to decide what to change today. And when one of them is falling behind, they elevate it to an OKR so the whole team can see it slipping and pile in.
This post is how I think about that practice in 2026, when the speed of signal has changed everything about how we steer products.
What a product KPI actually is
A product KPI is a number that, if it moves, tells you the product is succeeding or failing at the thing it's supposed to do. That's the whole definition. Three things follow from it.
It maps to an outcome, not an output. "Features shipped" is an output. "Percentage of new users who reach the second session" is an outcome. The KPI lives at the outcome layer. If you can ship a feature without moving the KPI, the KPI is correct and the feature was the wrong bet.
It moves on a timescale you can act on. Lagging metrics like quarterly retention or annual revenue are real, but they aren't daily KPIs. The daily KPI is the leading indicator that, if it moves, will eventually move retention. "Time-to-first-success in onboarding" is a daily KPI. "Quarterly logo retention" is a board metric. Different artifacts. Both matter. Don't confuse them.
It's specific enough to argue about. "Engagement" is not a KPI. "Daily active users who completed at least one core action" is. The first is a vibe. The second is a number two people can look at and disagree about whether it's healthy.
In the era of product builders, the KPI also has one more property: it has to be cheap to measure. If you can't get the number daily without a person running a manual query, you don't have a KPI. You have a research project pretending to be a KPI.
Three is the right number
I've tried five. I've tried ten. I've tried "the KPI tree." None of them worked for daily use. What works is three. Sometimes four. Never more.
Three KPIs forces real choices. It makes you say what your product is actually for. It also makes the daily ritual sustainable. I can read three numbers in 90 seconds with my coffee. I can't read fifteen.
For most products, the three break down like this:
One acquisition KPI. The number that tells you the front door is working. Not "signups." Signups are a vanity number. Activated signups (people who hit the moment of value) is the right number. Or trial-to-paid conversion. Or qualified pipeline added. Pick one that you'd defend as "the front door is working at this rate."
One value-delivery KPI. The number that tells you the product is doing the thing it's for. Sessions completed successfully. Documents processed. Tickets resolved. Conversations completed. Whatever your product's actual job-to-be-done is, count the times it gets done well. This is the one most teams skip because it's harder to define than acquisition.
One retention or expansion KPI. The number that tells you customers stay or grow. Could be 30-day repeat rate, weekly active retention, expansion ARR per cohort, NPS-passive-to-promoter conversion. Pick one. Watch it daily even if it moves slowly. The daily ritual is what teaches you which interventions actually nudge it.
Some products legitimately need a fourth KPI: a cost or margin number. If you're shipping AI features (you probably are), cost-per-successful-action belongs in your daily three. See Gross Margin Is Your Job Now for why.
The daily ritual
Every morning, before the first meeting, I look at three numbers. Same three. Same dashboard. Five minutes.
I'm not looking at the absolute number. I'm looking at the trend and the delta from yesterday. I ask three questions:
- Did anything move outside the noise band?
- If yes, what changed in the product, the market, the funnel, or our cost line that could explain it?
- What do I need to investigate today, and who do I need to pull in?
That's the entire ritual. Most days the answer is "nothing material, keep shipping." Some days the answer is "something moved, drop everything else." The ritual is what makes the second case possible. Without it, the move that mattered today gets noticed in next week's metrics review, by which time the cause is buried under five new things.
I started this ritual at SOCi about six years ago. I was missing things in our weekly review because the signal was a 3-day blip that had already ended by Monday. I switched to daily. Within a month I was catching things 5-6 days earlier. Within a quarter the team was operating differently. Faster decisions, fewer surprises.
The ritual doesn't require a fancy tool. A Notion page with three numbers and 7-day sparklines beats a Looker dashboard you don't open. Whatever gets you to look at the three numbers every morning is the right tool.
What to do when a KPI is falling behind
This is where most PMs hesitate. They see the number drop. They say "let's keep watching." A week later it's worse. Two weeks later they have a problem with no diagnosis.
The product builder's move is: define the response before you need it.
For each of your three KPIs, write down:
- The healthy band (what range is normal week-to-week noise).
- The investigation threshold (one move outside the noise band triggers investigation).
- The escalation threshold (sustained drop triggers a team-wide response).
- The OKR threshold (sustained miss elevates this from a KPI to an OKR for next quarter).
When a KPI crosses the investigation threshold, I don't call a meeting. I open the customer signal digest (see Continuous Listening) and look for the explanation in the qualitative data. Most of the time the explanation is sitting in support tickets and call recordings from the last 7 days. The KPI moved because customers are telling us something we hadn't heard yet.
If the KPI stays below the band for two weeks, I run a 60-minute team session with engineering and design. We look at the qualitative signal together. We ship one prototype within 48 hours that tries to address the most likely cause. We measure for a week. We learn.
If the KPI is still missing its band at the end of the next 4-week cycle, I escalate it to an OKR. I'll come back to that in a moment.
The KPI to OKR escalation
Here's the move most teams haven't quite figured out yet. KPIs and OKRs are not the same thing, and they aren't supposed to be. KPIs are the steady-state numbers you watch daily. OKRs are the things you've decided to push hard on this quarter because they aren't where they need to be.
The relationship between them: OKRs are KPIs that earned the spotlight.
When a KPI is healthy, it sits in your daily review. Quiet. Operating. You watch the trend. You don't make it the team's quarterly focus, because it doesn't need to be.
When a KPI starts missing its band consistently, you elevate it to an OKR. Now it's not just a number you watch. It's the thing the team is committed to moving this quarter. Resources reallocate. Other initiatives get deprioritized. The whole team has the same metric in their face for 90 days.
The mechanics:
- KPI miss its band for 4 weeks → next OKR cycle, that KPI becomes an objective.
- The objective is "move KPI X from current to target by end of quarter."
- Key results are the leading indicators that would predict the KPI moving (faster proxies you can measure weekly).
- The team commits. Other bets move down the priority list to make room.
- At the end of the quarter, the KPI either moved (it returns to KPI status) or it didn't (you escalate again or kill the surface).
This is the discipline most companies are missing. They have OKRs that are lagging indicators (revenue, NPS) and KPIs that are vanity numbers (signups, page views). The OKRs and the KPIs aren't connected. So the OKR cycle and the daily product practice are happening in parallel, in different rooms, for different audiences.
When KPIs and OKRs are connected through the escalation pipe, the daily practice and the quarterly planning become the same conversation, just at different timescales. The KPI is the canary. When the canary stops singing, the OKR is the response.
The Era of product builders changes the cadence
A few years ago, this whole post would have been about building dashboards. The hard part was instrumentation. You needed a data team to set up the pipeline. You needed an analyst to define the metric. You needed a quarterly review to look at the numbers because pulling them was expensive.
In 2026 the hard part isn't instrumentation. The hard part is choice.
You can instrument almost anything in an afternoon. You can have an agent compute and post your three KPIs to Slack every morning by Tuesday of next week if you started today. The bottleneck has moved from "can we measure it" to "do we know what to measure" and "are we willing to act on what it says."
The product builder treats this as a feature of the role. Picking the three KPIs is a primary decision, not an analytics task. Watching them daily is a primary ritual, not a side activity. Acting on them is a primary motion, not a quarterly review.
If you've been operating at a slower KPI cadence because that's what was possible with the old tooling, you're operating against a constraint that no longer exists. The companies you're competing with have already adjusted. So has the pace of signal in your market.
Pick one thing this week
You don't need a quarter to start this. You need an afternoon.
- Write down the three KPIs that, if they moved tomorrow, would change what you ship next week. If you can't get to three, that's the discovery exercise. Keep working at it until you have three.
- For each one, write down: the current value, the healthy band, the investigation threshold, the escalation threshold.
- Put the three numbers on a single page. Notion is fine. A Google Doc is fine. Don't wait for a perfect dashboard.
- Set a calendar reminder for every weekday morning at 8:30am, 5 minutes. "Read the three KPIs."
- Do it for two weeks. Notice what happens to your decision speed.
After two weeks, automate it. An agent that posts the three numbers to Slack every morning at 8am is a 30-minute build with Claude Code. Once that's running, you've installed the ritual permanently.
The product builders I respect most all do some version of this. None of them invented it. They all take it more seriously than the average PM does. That's the only thing that separates the practice.
Pick the three numbers this week. Watch them every morning. Elevate them when they slip. That's the operating discipline of a product builder, in three sentences.