AI Product Metrics Dashboard Designer

Most Dashboards Are Graveyards of Good Intentions

Open your analytics tool right now. Count the dashboards. How many do you actually check this week? At Amplitude, where I'd expect people to live inside their own product, even they've admitted that "dashboard sprawl" is a real problem. Teams create dashboards for every launch, every experiment, every exec request. Six months later, nobody remembers which chart matters.

The issue isn't the tool. It's the thinking — or lack of it — behind what gets measured.

The Metrics Hierarchy Problem

There's a famous Amazon practice: every team has a single "input metric" they own. Not a dashboard with 40 charts. One number that, if it moves, means the team is winning. Everything else is a supporting indicator or a guardrail.

Most product teams do the opposite. They track everything because tracking is easy. A 2024 Mixpanel survey found that the average product team tracks 47 metrics across their dashboards but can only articulate what 8 of them mean for the business. That's a 6:1 noise-to-signal ratio.

The consequence is decision paralysis. When your dashboard shows 12 metrics and 3 are up, 4 are down, and 5 are flat — what do you do? Nothing, usually. You wait for the next sprint review and hope the picture clarifies. Gibson Biddle, former VP of Product at Netflix, has written extensively about the "metric that matters" concept: if you can't explain how your North Star connects to your team's daily decisions, your measurement system is decoration.

The other trap is vanity metrics. Total sign-ups. Page views. "Engagement" without a definition. These numbers feel good in dashboards but don't connect to retention or revenue. They're the product equivalent of measuring lines of code.

How This Prompt Helps

This prompt designs a metrics dashboard from scratch, starting with the question that should come first: what is your product's North Star metric, and why? It builds a hierarchy from North Star down to primary metrics (the 3-4 numbers that directly influence the North Star), secondary metrics (leading indicators), and guardrail metrics (things you don't want to break while optimizing).

For each metric, it specifies the data source, measurement frequency, alert thresholds, and the team that owns it. This isn't a theoretical framework — it's a blueprint you can hand to your data engineering team on Monday morning.

When to Reach for This

• You're defining metrics for a new product or feature and want to get the hierarchy right from the start
• Your existing dashboard has grown unwieldy and you need to prune it back to what matters
• You're preparing for a board meeting or investor update and need to explain your metric framework
• You just hit product-market fit and need to shift from discovery metrics to growth metrics
• A new PM joined the team and you need to onboard them on what to watch and why

What Good Looks Like

A strong output produces a clear hierarchy where you can trace every metric back to the North Star through a causal chain. It should include "so what?" annotations — not just "track 7-day retention" but "7-day retention is your primary growth lever because a 5% improvement maps to X annual revenue based on your current cohort sizes." The monitoring plan should specify who looks at what, how often, and what action a threshold breach triggers.

Sources

• The Metric That Matters — Gibson Biddle
• 2024 Product Analytics Benchmark Report — Mixpanel
• Working Backwards: Insights from Inside Amazon — Colin Bryar & Bill Carr