dashboard-structuring

Name: dashboard-structuring
Author: Productfculty-aipm

70stars33forks

How to install dashboard-structuring?

productfculty-aipm/pm-copilot-by-product-faculty/dashboard-structuring

$npx -y skills add Productfculty-aipm/PM-Copilot-by-Product-Faculty --skill dashboard-structuring

Installs into the current project.

Summary

Use this skill when the user asks to "design a metrics dashboard", "what should be on my PM dashboard", "structure our analytics dashboard", "what metrics to track", "what should I put on a product dashboard", "build a metrics framework", or wants to design a coherent set of metr

Files · 1

View on GitHub

SKILL.md

1	# Dashboard Structuring
2
3	You are helping the user design a metrics dashboard that drives good product decisions — not one that generates activity reports. The test of a good dashboard: does looking at it every Monday morning tell the PM exactly where to focus that week?
4
5	Framework: Lenny Rachitsky (North Star + supporting metrics), Dave McClure (AARRR), Amplitude/Mixpanel best practices.
6
7	## Step 1 — Load Context
8
9	Read `memory/user-profile.md` for North Star, product stage, business model, and analytics tool. Read `context/company/analytics-baseline.md` for existing metric definitions and baselines.
10
11	## Step 2 — Dashboard Design Principles
12
13	Before building the dashboard, establish the principles:
14
15	1. One North Star, always visible: Every dashboard starts with the NSM. If it's trending well, the team can be more experimental. If it's dropping, everything else is secondary.
16
17	2. Hierarchy of metrics: NSM → Supporting metrics → Diagnostic metrics. Don't mix levels on the same visual.
18
19	3. Actionability over completeness: Only include a metric if someone would change their behavior based on seeing it. "Interesting but I wouldn't do anything differently" = cut it.
20
21	4. Benchmarks alongside data: Raw numbers without benchmarks are useless. Every metric needs: current value, baseline, target, and trend direction.
22
23	5. Weekly as the default cadence: Most product metrics are meaningful on a 7-day rolling basis. Daily is too noisy; monthly is too slow to act on.
24
25	## Step 3 — Metrics Hierarchy
26
27	Structure the dashboard in tiers:
28
29	Tier 1 — North Star (top of dashboard):
30	- NSM value: current week vs. last week vs. same week last quarter
31	- NSM trend: 90-day rolling chart
32	- Alert threshold: if NSM drops > X%, trigger investigation
33
34	Tier 2 — Growth inputs (what drives the NSM up):
35	- Acquisition: new users per week, by channel
36	- Activation: % of new users who hit the "aha moment" action within first 7 days
37	- Engagement: core action frequency (daily/weekly active users doing [core action])
38	- Retention: D7 and D30 retention rates
39
40	Tier 3 — Health metrics (guardrails):
41	- Revenue: MRR, ARR, or transaction volume
42	- Churn / downgrade rate
43	- NPS or CSAT score (if tracked)
44	- Bug and incident rate (if tracked)
45
46	Tier 4 — Diagnostic metrics (when investigating specific problems):
47	These don't go on the primary dashboard — they live in drill-down views. Include only when investigating a specific drop in Tier 1–3.
48
49	## Step 4 — Dashboard Layout
50
51	For each analytics tool, recommend the layout:
52
53	Amplitude / Mixpanel: Use a chart grid. NSM at top-left (biggest card). Supporting metrics below in 2 columns. Add weekly comparison and 90-day trend for each.
54
55	Looker / Data Studio: Use a report format. Title with date range. KPI tiles at top with sparklines. Trend charts below. Segment breakdowns in tables at the bottom.
56
57	Notion / Manual tracking: Use a table format updated weekly. Columns: Metric \| This Week \| Last Week \| 4-Week Avg \| Target \| Status (On Track / Watch / Alert)
58
59	## Step 5 — Metric Definitions
60
61	For each metric on the dashboard, write a precise definition to prevent ambiguity:
62
63	Example: "Weekly Active Users" is ambiguous. Better: "Unique users who completed at least one [core action] in the past 7 calendar days. Excludes test accounts and internal users. Source: Amplitude 'completed_core_action' event."
64
65	Imprecise metric definitions lead to arguments about whether the number is "real." Precise definitions lead to debates about whether the metric is the right thing to measure — which is the right debate.
66
67	## Step 6 — Output
68
69	Produce:
70	- Dashboard structure (tiers with metric names, definitions, and visualization type)
71	- Weekly review ritual: 5-question checklist the PM asks every Monday morning when looking at the dashboard
72	- Alert thresholds: what would trigger an immediate investigation vs. a mention in the weekly update
73	- Metric definitions document (precise definitions for each metric)
74
75	Offer to save metric definitions to `context/company/analytics-baseline.md`.

People who liked this also viewed

6 picks

Type

dashboard-structuring

70stars33forks

View on GitHub

How to install dashboard-structuring?

productfculty-aipm/pm-copilot-by-product-faculty/dashboard-structuring

$npx -y skills add Productfculty-aipm/PM-Copilot-by-Product-Faculty --skill dashboard-structuring

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Dashboard Structuring
2
3	You are helping the user design a metrics dashboard that drives good product decisions — not one that generates activity reports. The test of a good dashboard: does looking at it every Monday morning tell the PM exactly where to focus that week?
4
5	Framework: Lenny Rachitsky (North Star + supporting metrics), Dave McClure (AARRR), Amplitude/Mixpanel best practices.
6
7	## Step 1 — Load Context
8
9	Read `memory/user-profile.md` for North Star, product stage, business model, and analytics tool. Read `context/company/analytics-baseline.md` for existing metric definitions and baselines.
10
11	## Step 2 — Dashboard Design Principles
12
13	Before building the dashboard, establish the principles:
14
15	1. One North Star, always visible: Every dashboard starts with the NSM. If it's trending well, the team can be more experimental. If it's dropping, everything else is secondary.
16
17	2. Hierarchy of metrics: NSM → Supporting metrics → Diagnostic metrics. Don't mix levels on the same visual.
18
19	3. Actionability over completeness: Only include a metric if someone would change their behavior based on seeing it. "Interesting but I wouldn't do anything differently" = cut it.
20
21	4. Benchmarks alongside data: Raw numbers without benchmarks are useless. Every metric needs: current value, baseline, target, and trend direction.
22
23	5. Weekly as the default cadence: Most product metrics are meaningful on a 7-day rolling basis. Daily is too noisy; monthly is too slow to act on.
24
25	## Step 3 — Metrics Hierarchy
26
27	Structure the dashboard in tiers:
28
29	Tier 1 — North Star (top of dashboard):
30	- NSM value: current week vs. last week vs. same week last quarter
31	- NSM trend: 90-day rolling chart
32	- Alert threshold: if NSM drops > X%, trigger investigation
33
34	Tier 2 — Growth inputs (what drives the NSM up):
35	- Acquisition: new users per week, by channel
36	- Activation: % of new users who hit the "aha moment" action within first 7 days
37	- Engagement: core action frequency (daily/weekly active users doing [core action])
38	- Retention: D7 and D30 retention rates
39
40	Tier 3 — Health metrics (guardrails):
41	- Revenue: MRR, ARR, or transaction volume
42	- Churn / downgrade rate
43	- NPS or CSAT score (if tracked)
44	- Bug and incident rate (if tracked)
45
46	Tier 4 — Diagnostic metrics (when investigating specific problems):
47	These don't go on the primary dashboard — they live in drill-down views. Include only when investigating a specific drop in Tier 1–3.
48
49	## Step 4 — Dashboard Layout
50
51	For each analytics tool, recommend the layout:
52
53	Amplitude / Mixpanel: Use a chart grid. NSM at top-left (biggest card). Supporting metrics below in 2 columns. Add weekly comparison and 90-day trend for each.
54
55	Looker / Data Studio: Use a report format. Title with date range. KPI tiles at top with sparklines. Trend charts below. Segment breakdowns in tables at the bottom.
56
57	Notion / Manual tracking: Use a table format updated weekly. Columns: Metric \| This Week \| Last Week \| 4-Week Avg \| Target \| Status (On Track / Watch / Alert)
58
59	## Step 5 — Metric Definitions
60
61	For each metric on the dashboard, write a precise definition to prevent ambiguity:
62
63	Example: "Weekly Active Users" is ambiguous. Better: "Unique users who completed at least one [core action] in the past 7 calendar days. Excludes test accounts and internal users. Source: Amplitude 'completed_core_action' event."
64
65	Imprecise metric definitions lead to arguments about whether the number is "real." Precise definitions lead to debates about whether the metric is the right thing to measure — which is the right debate.
66
67	## Step 6 — Output
68
69	Produce:
70	- Dashboard structure (tiers with metric names, definitions, and visualization type)
71	- Weekly review ritual: 5-question checklist the PM asks every Monday morning when looking at the dashboard
72	- Alert thresholds: what would trigger an immediate investigation vs. a mention in the weekly update
73	- Metric definitions document (precise definitions for each metric)
74
75	Offer to save metric definitions to `context/company/analytics-baseline.md`.

People who liked this also viewed

6 picks

Type