Measure Dashboard Requirements
Scannednpx machina-cli add skill product-on-purpose/pm-skills/measure-dashboard-requirements --openclawname: measure-dashboard-requirements description: Specifies requirements for an analytics dashboard including metrics, visualizations, filters, and data sources. Use when requesting dashboards from data teams, defining KPI tracking, or documenting reporting needs. phase: measure version: "2.0.0" updated: 2026-01-26 license: Apache-2.0 metadata: category: validation frameworks: [triple-diamond, lean-startup, design-thinking] author: product-on-purpose
Dashboard Requirements
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.
When to Use
- When requesting a new dashboard from data/analytics teams
- To define KPI tracking for a product, feature, or team
- When formalizing ad-hoc reporting into a persistent dashboard
- Before quarterly planning to specify what visibility you need
- When onboarding stakeholders who need self-serve analytics
Instructions
When asked to specify dashboard requirements, follow these steps:
-
Define the Purpose 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.
-
Identify the Audience 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.
-
Specify Key Metrics For each metric, document: name, business definition (in plain language), calculation formula, data source, and baseline/target values. Ambiguous metrics lead to misaligned dashboards.
-
Design Visualizations 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.
-
Define Filters and Segments Specify what drill-downs users need: date ranges, user segments, product areas, geographic regions. Anticipate the "slice and dice" questions users will ask.
-
Document Data Sources 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?
-
Set Permissions and Access Determine who can view what. Some metrics may need restricted access. Consider both security requirements and organizational politics.
Output Format
Use the template in references/TEMPLATE.md to structure the output.
Quality Checklist
Before finalizing, verify:
- Purpose is framed as questions to answer, not charts to build
- All metrics have clear definitions and calculation formulas
- Data sources are identified and accessible
- Visualization choices match the type of insight needed
- Filters enable the drill-downs users will want
- Refresh frequency matches decision-making cadence
Examples
See references/EXAMPLE.md for a completed example.
Source
git clone https://github.com/product-on-purpose/pm-skills/blob/main/skills/measure-dashboard-requirements/SKILL.mdView on GitHub Overview
Measure Dashboard Requirements creates a blueprint for dashboards by specifying the questions to answer, the metrics to display, and how data should be visualized. It helps teams request dashboards from data/analytics, define KPI tracking, and turn ad-hoc reporting into persistent, decision-ready views. Clear requirements prevent vanity metrics and ensure dashboards actually inform decisions.
How This Skill Works
Start by stating the dashboard’s purpose as the questions to answer, then identify the intended audience and cadence. For every metric, document a plain-language definition, calculation formula, data source, and targets; select visuals that communicate the insight (line charts for trends, bars for comparisons, pies/treemaps for composition) and specify filters. Conclude with data sources, latency needs, and access permissions to govern usage.
When to Use It
- When requesting a new dashboard from data/analytics teams
- To define KPI tracking for a product, feature, or team
- When formalizing ad-hoc reporting into a persistent dashboard
- Before quarterly planning to specify what visibility you need
- When onboarding stakeholders who need self-serve analytics
Quick Start
- Step 1: Define the dashboard’s purpose by listing the questions it should answer.
- Step 2: Identify the audience and how often they will use the dashboard.
- Step 3: Document metrics with definitions, formulas, data sources, targets; choose visuals; list required filters and data latency.
Best Practices
- Frame the purpose as questions to answer, not charts to build.
- Define metrics with clear definitions and calculation formulas.
- Identify data sources and note data quality issues and latency.
- Choose visuals that match the insight needed (line for trends, bar for comparisons, pie/treemap for composition) and include dimension breakdowns.
- Define filters and access early to support drill-downs and governance.
Example Use Cases
- Executive weekly dashboard showing revenue, ARR, and customer health metrics.
- Product feature adoption dashboard tracking activation rate and time-to-value.
- Ad-hoc reporting formalized into a persistent KPI dashboard for a product area.
- Quarterly planning view that surfaces required visibility for decision-makers.
- Self-serve analytics onboarding dashboard with role-based access for stakeholders.
