How to Measure Product Success: Metrics Every PM Should Know
Features don’t ship themselves into success. A product that launches without a clear measurement framework is a product that improves by luck — the team ships, observes a vague sense of whether things got better or worse, and moves on to the next thing without really knowing. Learning how to measure product success is one of the most useful skills a PM can build, and it’s less about picking a favorite number than about building a framework that survives contact with real tradeoffs.
This guide covers the full metrics stack — from the North Star Metric at the top to feature-level success criteria at the bottom — and gives a practical framework for deciding what to measure and why.
A “metrics dashboard” that’s really just a wall of 40 numbers nobody can explain is a common inheritance for a PM joining an existing team, and rebuilding it always starts the same way: cutting, not adding.
Why Most Product Teams Measure the Wrong Things
The most common measurement mistake in product development is tracking vanity metrics — numbers that go up and feel good but don’t tell you whether users are getting value.
Total signups look great in a board deck. But if 80% of those users never come back, the metric is hiding the real story. Pageviews, downloads, social followers — these metrics are easy to produce and easy to inflate. They’re also largely useless for product decision-making.
The second most common mistake is measuring too much. When a team tracks 40 metrics, they’re effectively tracking nothing. No one knows which number to optimize when there’s a tradeoff, and priorities become invisible. Two people citing two different metrics to argue for opposite priorities in the same roadmap review — both technically true — is exactly the failure mode an unranked pile of 40 numbers produces.
Good product measurement solves both problems: it focuses on metrics that are genuinely connected to customer value, and it limits the number of metrics that the team actively manages.
The Three Layers of a Product Success Metrics Framework
A mature product metrics framework has three layers:
Layer 1 — North Star Metric (NSM): The single metric that best represents the core value the product delivers. It’s the measure to look at first to understand whether the product is succeeding or failing. See the full guide on what is a North Star Metric for how to define one.
Layer 2 — Input Metrics (Driver Metrics): The 3–5 metrics that, when moved, tend to move the NSM. These are what product squads and teams own. Each product area can trace its work to a specific input metric.
Layer 3 — Feature and Experiment Metrics: The specific success criteria for individual features, experiments, and releases. These are short-term, tightly scoped, and often include guardrail metrics to ensure changes don’t create unintended side effects.
The Core Categories of Product Metrics
Acquisition Metrics
Acquisition metrics measure how users find and arrive at a product.
- New users / signups: How many new users joined in a given period?
- Acquisition channel breakdown: Where are users coming from (organic search, paid, referral, social)?
- Cost per acquisition (CPA): How much does it cost to acquire one user?
Acquisition metrics tell you about the top of the funnel. They’re important context but rarely the right primary focus for a product team — marketing usually has more direct control over acquisition than product does.
Activation Metrics
Activation measures whether new users reach the core value moment of a product — the first time they experience what the product is actually for.
- Activation rate: What percentage of new signups complete the key activation event?
- Time to activation: How long does it take the average new user to reach the core value moment?
- Onboarding completion rate: What percentage of users complete the onboarding flow?
Activation is one of the highest-leverage areas for product improvement. A product with strong acquisition but low activation is a leaky bucket — money is spent acquiring users who leave before they understand the product’s value.
A typical activation event might be: completing a first project (for a project management tool), sending a first message to a colleague (for a communication tool), or getting the first recommendation correct (for a recommendations engine).
Engagement and Retention Metrics
These are the most important product metrics for most products. Engagement measures how often and how deeply users interact with the product. Retention measures whether they come back.
- Daily Active Users (DAU) / Weekly Active Users (WAU) / Monthly Active Users (MAU): The raw counts of users taking at least one meaningful action in each period. DAU/MAU ratios tell you about stickiness — a DAU/MAU ratio above 20% is generally considered healthy for a consumer app.
- Retention rate: Of users who were active N days/weeks ago, what percentage are still active today?
- Churn rate: The inverse of retention — what percentage of users stopped using the product in a given period?
- Session frequency: How often do users return to the product in a given period?
- Session depth / feature breadth: Are users discovering and using multiple features, or are they stuck in a narrow usage pattern?
The most important retention chart to understand is the retention curve: plot the percentage of users who are still active after 1 day, 7 days, 14 days, 30 days, and 90 days. A healthy retention curve flattens out at some point — meaning a core of users sticks with the product long-term. A curve that keeps declining toward zero means the product hasn’t found a sustainable user base.
Lenny Rachitsky’s newsletter publishes useful retention benchmarks: for consumer social products, retention rates above 25% at day 30 are strong; for SaaS products, monthly churn below 2–3% is generally healthy. Treat those as sanity checks rather than targets — a benchmark from a different category of product can send a team chasing the wrong number.
Revenue and Business Metrics
Revenue metrics connect product success to business outcomes.
- Monthly Recurring Revenue (MRR) / Annual Recurring Revenue (ARR): The baseline revenue measurement for subscription businesses.
- Average Revenue Per User (ARPU): Revenue divided by active users. Tells you about monetization efficiency.
- Conversion rate (free to paid): For freemium products, the percentage of free users who convert to a paid plan.
- Expansion revenue: Revenue from existing customers upgrading or expanding their usage. Often a leading indicator of product satisfaction.
- Net Revenue Retention (NRR): Revenue from existing customers at the end of a period vs. the beginning, including expansions and contractions. An NRR above 100% means the business is growing even without acquiring new customers.
Satisfaction and Quality Metrics
These metrics capture the qualitative dimension of product success.
- Net Promoter Score (NPS): “On a scale of 0–10, how likely are you to recommend this product to a friend?” Scores above 50 are considered excellent for most product categories.
- Customer Satisfaction Score (CSAT): A direct satisfaction rating, typically collected post-interaction or at a moment in the product flow.
- Customer Effort Score (CES): How easy was it to accomplish your goal? Lower effort scores correlate with higher retention.
- App store ratings: A lagging but publicly visible satisfaction signal.
- Support ticket volume and category: High ticket volume on specific topics often signals product experience failures.
A Worked Example: Picking Metrics for an Onboarding Redesign
A 25-person B2B SaaS company redesigns onboarding for a project management tool. Before the redesign ships, here’s the concrete decision a PM has to make, not just the abstract framework.
Primary success metric: percentage of new signups who create and assign their first task within 48 hours — the team’s defined activation event. Not “engagement” in general, that one specific action, because it’s the one earlier cohort analysis tied most tightly to 90-day retention.
Guardrail metrics: support ticket volume tagged “onboarding confusion” (shouldn’t rise even if activation does), and time-to-first-task for existing power users re-entering the flow via a referral (shouldn’t get slower just because the new-user path got more guided).
Measurement window: three weeks, chosen in advance, specifically because this team’s signup volume is roughly 40 new accounts a week — smaller samples than that produce noisy activation percentages that swing 10+ points from normal variance alone, not from anything the redesign did.
The failure mode this setup exists to prevent: checking the activation number after four days, seeing it up 15 points, and calling the redesign a win in a leadership update — only to watch it regress to roughly flat by the end of week two, once the small early sample of highly-motivated signups washes out. Committing to the measurement window before looking at the data is what prevents exactly that mistake.
How to Define Success Criteria for a Feature
Before shipping any feature, a product manager should define what success looks like. This means answering three questions:
1. What is the primary success metric? The single number that will tell you whether this feature achieved its goal. For an onboarding improvement, it might be the activation rate. For a new collaboration feature, it might be the number of shared documents per active team.
2. What are the guardrail metrics? The metrics that should not go down as a result of this change. A feature that increases activation but also increases support ticket volume might not be net positive. Guardrail metrics protect against unintended side effects.
3. What is the measurement window? How long will the experiment run or the data get observed before making a decision? Set this in advance to avoid the common mistake of stopping an A/B test as soon as it shows the result the team hoped for.
Connecting feature success criteria to OKRs ensures that individual feature work is tied to team-level goals, which are tied to company-level outcomes.
Setting Up a Product Success Metrics Dashboard
A product metrics dashboard should answer three questions at a glance:
- Is the North Star Metric up or down week-over-week?
- Which input metrics are driving the change?
- Are any key metrics in an abnormal state?
For most product teams, product analytics tools like Amplitude, Mixpanel, or PostHog provide the infrastructure for this. The key is not the tool — it’s having a consistent, shared view of the metrics that the whole team looks at regularly. Building the dashboard is only half the job; the guide on how to read a product metrics dashboard covers the harder skill of interpreting what it’s actually telling you week to week.
Best practices for a product metrics dashboard:
- Update automatically (don’t rely on manual data pulls)
- Show week-over-week trends, not just point-in-time snapshots
- Include anomaly detection or alerts for significant drops
- Be visible to the whole team, not just the PM
Product Metrics and Product-Market Fit
The strongest signal of product-market fit is a retention curve that flattens — meaning users keep coming back. Before that happens, none of the other metrics matter much. Acquisition and activation can be optimized endlessly, but if users churn at a constant rate, the underlying product problem isn’t solved.
Once retention is real, metrics shift from “do users find value?” to “how do we create more value for more users?” That’s when the full metrics framework in this guide becomes relevant — and when the difference between a team that’s merely instrumented and one that’s actually data-informed starts to show up in the decisions that get made, not just the dashboards that get built.
Where a Product Success Metrics Framework Breaks Down
Optimizing for a metric that doesn’t reflect value. If the NSM is sessions per user but users are having more sessions because they’re frustrated and re-trying failed actions, the team is measuring confusion, not engagement. This exact pattern has a habit of showing up as a “win” in a weekly review before anyone thinks to check what the extra sessions actually consisted of.
Picking metrics after seeing the data. Define success criteria before the experiment or launch. Choosing metrics after the results are in is p-hacking — it looks rigorous but isn’t, and it’s rarely intentional; it’s usually a well-meaning PM reaching for whichever number happens to look good after the fact.
Ignoring qualitative signals. Quantitative metrics tell you what is happening. User research tells you why. A drop in activation rate is a signal to investigate; a series of user interviews is what tells you what to fix.
Treating all users equally. Segment your metrics. Power users behave differently from casual users; new users behave differently from long-tenured ones. Aggregate metrics often hide the most important signals — an average that’s flat can easily be masking one segment improving and another getting worse.
Product Success Metrics at a Glance
| Layer | Examples | Owned By | Update Cadence |
|---|---|---|---|
| North Star Metric | Weekly active teams completing a core action | Head of Product / leadership | Weekly |
| Input metrics | Activation rate, retention rate, session depth | Product squads | Weekly |
| Feature metrics | Feature-specific adoption, guardrail metrics | Individual PM / team | Per experiment window |
| Business metrics | MRR, NRR, ARPU, conversion rate | Product + finance | Monthly |
| Satisfaction metrics | NPS, CSAT, CES, support ticket volume | Product + support | Quarterly / ongoing |
References
- Amplitude — Product Analytics Blog
- Reforge. Metrics and Analytics Program. reforge.com.
- Rachitsky, Lenny. “What are good retention rates?” Lenny’s Newsletter.
Pull up your own dashboard this week and count how many of the numbers on it could actually be defended in a room — why it’s there, what decision it drives, and what would change if it moved. Anything that can’t be defended is a candidate to cut, not a reason to add a 41st metric next to it.
