measure-dashboard-requirements

Name: measure-dashboard-requirements
Author: product-on-purpose

486stars64forks

How to install measure-dashboard-requirements?

product-on-purpose/pm-skills/measure-dashboard-requirements

$npx -y skills add product-on-purpose/pm-skills --skill measure-dashboard-requirements

Installs into the current project.

Summary

Specifies what questions a dashboard must answer and the metrics, visualizations, filters, and data sources it needs, so data teams build something that informs decisions rather than displaying numbers. Use when requesting a dashboard or formalizing ad-hoc reporting. For the even

Files · 1

View on GitHub

SKILL.md

1	<!-- PM-Skills \| https://github.com/product-on-purpose/pm-skills \| Apache 2.0 -->
2	# Dashboard Requirements
3
4	A dashboard requirements document specifies what questions a dashboard should answer, what metrics it displays, and how data should be visualized. Clear requirements help data teams build dashboards that actually inform decisions rather than just displaying numbers.
5
6	## When to Use
7
8	- When requesting a new dashboard from data/analytics teams
9	- To define KPI tracking for a product, feature, or team
10	- When formalizing ad-hoc reporting into a persistent dashboard
11	- Before quarterly planning to specify what visibility you need
12	- When onboarding stakeholders who need self-serve analytics
13
14	## When NOT to Use
15
16	- You need the event tracking that feeds dashboards -> use `measure-instrumentation-spec`; instrument first, visualize second
17	- You are designing an experiment readout, not a standing dashboard -> use `measure-experiment-design` and `measure-experiment-results`
18	- You want OKR progress scored at cycle close -> use `measure-okr-grader`
19	- The questions the dashboard should answer are not yet agreed -> frame outcomes first with `foundation-okr-writer` or `define-problem-statement`
20
21	## Instructions
22
23	When asked to specify dashboard requirements, follow these steps:
24
25	1. Define the Purpose
26	Start with the questions this dashboard should answer, not the charts it should show. What decisions will this dashboard inform? A dashboard without clear purpose becomes a vanity metrics display.
27
28	2. Identify the Audience
29	Specify who will use this dashboard, how often, and in what context. An executive weekly review has different needs than a team's daily standup board.
30
31	3. Specify Key Metrics
32	For each metric, document: name, business definition (in plain language), calculation formula, data source, and baseline/target values. Ambiguous metrics lead to misaligned dashboards.
33
34	4. Design Visualizations
35	Recommend chart types based on what the data should communicate. Time trends need line charts; comparisons need bar charts; compositions need pie/treemaps. Include dimension breakdowns.
36
37	5. Define Filters and Segments
38	Specify what drill-downs users need: date ranges, user segments, product areas, geographic regions. Anticipate the "slice and dice" questions users will ask.
39
40	6. Document Data Sources
41	Identify where data comes from and any known data quality issues. Note latency requirements.does the dashboard need real-time data or is daily refresh sufficient?
42
43	7. Set Permissions and Access
44	Determine who can view what. Some metrics may need restricted access. Consider both security requirements and organizational politics.
45
46	## Output Format
47
48	Use the template in `references/TEMPLATE.md` to structure the output. A complete spec fills every template section: Overview; Purpose and Questions; Audience; Key Metrics; Visualization Specifications; Filters and Segments; Data Sources; Access and Permissions; Alerts and Thresholds; Acceptance Criteria; Open Questions; and Appendix.
49
50	## Quality Checklist
51
52	Before finalizing, verify:
53
54	- [ ] Purpose is framed as questions to answer, not charts to build
55	- [ ] All metrics have clear definitions and calculation formulas
56	- [ ] Data sources are identified and accessible
57	- [ ] Visualization choices match the type of insight needed
58	- [ ] Filters enable the drill-downs users will want
59	- [ ] Refresh frequency matches decision-making cadence
60
61	## Examples
62
63	See `references/EXAMPLE.md` for a completed example.

People who liked this also viewed

6 picks

Type

measure-dashboard-requirements

486stars64forks

View on GitHub

How to install measure-dashboard-requirements?

product-on-purpose/pm-skills/measure-dashboard-requirements

$npx -y skills add product-on-purpose/pm-skills --skill measure-dashboard-requirements

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	<!-- PM-Skills \| https://github.com/product-on-purpose/pm-skills \| Apache 2.0 -->
2	# Dashboard Requirements
3
4	A dashboard requirements document specifies what questions a dashboard should answer, what metrics it displays, and how data should be visualized. Clear requirements help data teams build dashboards that actually inform decisions rather than just displaying numbers.
5
6	## When to Use
7
8	- When requesting a new dashboard from data/analytics teams
9	- To define KPI tracking for a product, feature, or team
10	- When formalizing ad-hoc reporting into a persistent dashboard
11	- Before quarterly planning to specify what visibility you need
12	- When onboarding stakeholders who need self-serve analytics
13
14	## When NOT to Use
15
16	- You need the event tracking that feeds dashboards -> use `measure-instrumentation-spec`; instrument first, visualize second
17	- You are designing an experiment readout, not a standing dashboard -> use `measure-experiment-design` and `measure-experiment-results`
18	- You want OKR progress scored at cycle close -> use `measure-okr-grader`
19	- The questions the dashboard should answer are not yet agreed -> frame outcomes first with `foundation-okr-writer` or `define-problem-statement`
20
21	## Instructions
22
23	When asked to specify dashboard requirements, follow these steps:
24
25	1. Define the Purpose
26	Start with the questions this dashboard should answer, not the charts it should show. What decisions will this dashboard inform? A dashboard without clear purpose becomes a vanity metrics display.
27
28	2. Identify the Audience
29	Specify who will use this dashboard, how often, and in what context. An executive weekly review has different needs than a team's daily standup board.
30
31	3. Specify Key Metrics
32	For each metric, document: name, business definition (in plain language), calculation formula, data source, and baseline/target values. Ambiguous metrics lead to misaligned dashboards.
33
34	4. Design Visualizations
35	Recommend chart types based on what the data should communicate. Time trends need line charts; comparisons need bar charts; compositions need pie/treemaps. Include dimension breakdowns.
36
37	5. Define Filters and Segments
38	Specify what drill-downs users need: date ranges, user segments, product areas, geographic regions. Anticipate the "slice and dice" questions users will ask.
39
40	6. Document Data Sources
41	Identify where data comes from and any known data quality issues. Note latency requirements.does the dashboard need real-time data or is daily refresh sufficient?
42
43	7. Set Permissions and Access
44	Determine who can view what. Some metrics may need restricted access. Consider both security requirements and organizational politics.
45
46	## Output Format
47
48	Use the template in `references/TEMPLATE.md` to structure the output. A complete spec fills every template section: Overview; Purpose and Questions; Audience; Key Metrics; Visualization Specifications; Filters and Segments; Data Sources; Access and Permissions; Alerts and Thresholds; Acceptance Criteria; Open Questions; and Appendix.
49
50	## Quality Checklist
51
52	Before finalizing, verify:
53
54	- [ ] Purpose is framed as questions to answer, not charts to build
55	- [ ] All metrics have clear definitions and calculation formulas
56	- [ ] Data sources are identified and accessible
57	- [ ] Visualization choices match the type of insight needed
58	- [ ] Filters enable the drill-downs users will want
59	- [ ] Refresh frequency matches decision-making cadence
60
61	## Examples
62
63	See `references/EXAMPLE.md` for a completed example.

People who liked this also viewed

6 picks

Type