Example of a product KPI dashboard for a growth team must solve a problem most dashboards create: the more metrics you show, the less clearly you communicate what requires action.
A growth team KPI dashboard that shows 40 metrics is a data warehouse with a chart renderer. A dashboard that shows 8 metrics — each with a target, a trend, and an anomaly alert — is a decision-making tool.
The Growth Dashboard Design Principles
Principle 1: Every metric on the dashboard has an owner. If no one is responsible for a metric, it should not be on the dashboard. Unowned metrics generate discussion but not decisions.
Principle 2: Every metric has a target and a trend. The metric alone means nothing. You need to know if it's moving toward the target or away from it.
Principle 3: The dashboard is organized by decision horizon. Leading indicators at the top, lagging outcomes at the bottom. The leading indicators drive weekly decisions; the lagging outcomes tell you if the decisions are working.
Principle 4: Anomalies are highlighted, not buried. The dashboard should flag metrics that are moving faster or slower than expected. Green/yellow/red status reduces cognitive load.
The Growth Team KPI Dashboard Structure
H3: Layer 1 — Acquisition (Top of Funnel)
| Metric | Owner | Target | Status | |---|---|---|---| | Weekly new signups | Growth PM | +10% WoW | 🟢 | | Activation rate (new users) | Growth PM | 45% | 🟡 | | CAC by channel | Growth PM | <$X | 🟢 | | Trial-to-paid conversion | Growth PM | 25% | 🔴 |
H3: Layer 2 — Engagement (Core Product Usage)
| Metric | Owner | Target | Status | |---|---|---|---| | WAU / MAU ratio | Product PM | >40% | 🟢 | | Core action frequency | Product PM | 3x/week | 🟡 | | Feature adoption (new features, D30) | Product PM | 30% | 🟢 |
H3: Layer 3 — Retention (Business Health)
| Metric | Owner | Target | Status | |---|---|---|---| | D30 retention (new cohort) | Growth PM | 35% | 🔴 | | Monthly churn rate | CS/PM | <2% | 🟡 | | NRR | CS | >110% | 🟢 |
H3: Layer 4 — Revenue (Lagging Outcome)
| Metric | Owner | Target | Status | |---|---|---|---| | MRR | Finance/PM | $X | 🟢 | | MRR growth rate | Growth PM | 10% MoM | 🟡 | | Average contract value | Product/Sales | $X | 🟢 |
According to Lenny Rachitsky on his newsletter, the growth team dashboards that drive the most consistent weekly action are the ones structured by decision horizon — leading indicators like activation rate and core action frequency are the dials growth teams can turn this week, while lagging outcomes like MRR tell you if the turning worked.
Dashboard Anomaly Detection
For each metric, set two thresholds:
- Yellow alert: Metric is 10–20% off target (watch closely, investigate if it continues)
- Red alert: Metric is >20% off target (immediate investigation required, escalate to leadership)
Configure automated alerts in your analytics tool to notify the metric owner when a red alert triggers. Dashboards that require manual checking get checked inconsistently.
According to Shreyas Doshi on Lenny's Podcast, the growth teams that respond to metric movements fastest are the ones with automated anomaly detection rather than manual dashboard reviews — by the time a PM manually notices a 3-week declining activation rate in a weekly review, the cohort that churned has already been onboarded.
Weekly Dashboard Review Protocol
Before the meeting (async):
- Metric owners review their metrics and update status (green/yellow/red)
- Any red metrics require a written root cause hypothesis before the meeting
In the meeting (20 minutes):
- Skip all green metrics
- Review yellow metrics: do we know why? Is it trending back?
- Deep-dive red metrics: root cause, proposed action, owner, and deadline
After the meeting:
- Log decisions made and metrics that triggered them in the decision log
According to Gibson Biddle on Lenny's Podcast, the growth dashboards that generate the most decision velocity are the ones with an explicit skip-green policy — teams that review every metric regardless of status spend meeting time confirming what is working rather than fixing what is not.
FAQ
Q: How many KPIs should a growth team dashboard have? A: 8–12 metrics across acquisition, engagement, retention, and revenue. More than 12 creates decision paralysis; fewer than 8 misses important signals in the funnel.
Q: What is the most important growth team KPI? A: D30 retention for new cohorts. All other metrics — activation, engagement, revenue — are downstream of whether your product retains users past the first month.
Q: How often should a growth team review its KPI dashboard? A: Weekly for anomaly-triggered reviews. Daily for high-velocity growth teams running experiments. Monthly for strategic trend analysis. Don't review all metrics at all three cadences — that's metrics theater.
Q: What tools are best for building a growth team KPI dashboard? A: Amplitude or Mixpanel for behavioral metrics, Stripe or Chargebee for revenue metrics, and Looker or Mode for cross-source dashboards. For early-stage teams: Notion or Airtable with manual updates is better than no dashboard.
Q: How do you prevent a KPI dashboard from becoming a vanity metrics board? A: Require every metric to have an owner, a target, and a defined action the team will take when the metric goes red. Metrics without owners and without actions are vanity metrics by definition.
HowTo: Build a Product KPI Dashboard for a Growth Team
- Select 8 to 12 metrics across acquisition, engagement, retention, and revenue — each with a designated owner and a target
- Organize the dashboard by decision horizon: leading indicators at the top and lagging outcomes at the bottom
- Display each metric with its current value, target, trend direction, and green/yellow/red status based on percentage off target
- Configure automated anomaly alerts for red status thresholds so metric owners are notified without manual dashboard checking
- Implement a skip-green meeting protocol where weekly reviews only discuss yellow and red metrics with written root cause hypotheses for red metrics prepared before the meeting
- Log every decision triggered by a metric movement in a decision log to build calibration over time about which metrics most reliably predict outcomes