measure-dashboard-requirements
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
Install
npx skills add https://github.com/product-on-purpose/pm-skills/tree/main/skills/measure-dashboard-requirements
claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install product-on-purpose-pm-skills@llmmart
git clone https://github.com/product-on-purpose/pm-skills.git
The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole product-on-purpose/pm-skills collection as a plugin from our marketplace. Git is the plain clone.
Skill manifest
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
When NOT to Use
- You need the event tracking that feeds dashboards -> use
measure-instrumentation-spec; instrument first, visualize second - You are designing an experiment readout, not a standing dashboard -> use
measure-experiment-designandmeasure-experiment-results - You want OKR progress scored at cycle close -> use
measure-okr-grader - The questions the dashboard should answer are not yet agreed -> frame outcomes first with
foundation-okr-writerordefine-problem-statement
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. 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.
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.
Files (pm-skills)
-
evals
-
trigger-fixtures.json 4.1 KB
{ "schema": 1, "skill": "measure-dashboard-requirements", "runs_per_query": 3, "trigger_threshold": 0.5, "queries": [ { "q": "Write dashboard requirements for tracking activation funnel health for the growth team", "expect": "trigger", "split": "train" }, { "q": "The data team asked what we actually need on the new retention dashboard. Spec the metrics, charts, and filters.", "expect": "trigger", "split": "train" }, { "q": "I keep pulling the same ad-hoc numbers every Monday. Turn this into requirements for a persistent self-serve dashboard.", "expect": "trigger", "split": "train" }, { "q": "Define the KPI tracking view for the checkout redesign: which metrics, definitions, breakdowns, and refresh cadence", "expect": "trigger", "split": "train" }, { "q": "Spec out an executive dashboard that answers whether the marketplace is healthy, before quarterly planning", "expect": "trigger", "split": "train" }, { "q": "Document the reporting needs for support leadership: ticket volume trends, segment drill-downs, and who gets access", "expect": "trigger", "split": "train" }, { "q": "Our analytics team needs a requirements doc for the subscription revenue dashboard, including data sources and known quality issues", "expect": "trigger", "split": "validation" }, { "q": "Put together what the mobile team's daily standup board should show: crash rate, DAU, release adoption, with drill-downs", "expect": "trigger", "split": "validation" }, { "q": "I want stakeholders to self-serve product usage numbers instead of pinging me. Specify the dashboard they need.", "expect": "trigger", "split": "validation" }, { "q": "Define requirements for a North Star metric dashboard with supporting input metrics and segment filters", "expect": "trigger", "split": "validation" }, { "q": "Define which events and properties we need to start tracking in the checkout flow so we can measure it later", "expect": "no-trigger", "split": "train", "near_miss_of": "measure-instrumentation-spec", "notes": "Event tracking feeds dashboards; instrument first, visualize second" }, { "q": "Score our Q2 OKRs now that the quarter closed and tell me which key results actually landed", "expect": "no-trigger", "split": "train", "near_miss_of": "measure-okr-grader", "notes": "OKR scoring at cycle close, not standing visibility" }, { "q": "Design an A/B test for the new onboarding checklist with sample size and duration", "expect": "no-trigger", "split": "train" }, { "q": "Why is my Grafana panel showing 'No data' for this Prometheus query?", "expect": "no-trigger", "split": "train" }, { "q": "Analyze the NPS survey responses we collected last month and pull out the themes", "expect": "no-trigger", "split": "train" }, { "q": "Write OKRs for the data platform team for next quarter", "expect": "no-trigger", "split": "train" }, { "q": "Engineering is about to build the referral feature. Document the analytics events contract they should implement.", "expect": "no-trigger", "split": "validation", "near_miss_of": "measure-instrumentation-spec", "notes": "Implementation-side tracking contract, not the dashboard layer" }, { "q": "The pricing experiment just finished. Write the readout with significance and a ship recommendation.", "expect": "no-trigger", "split": "validation", "near_miss_of": "measure-experiment-results", "notes": "Experiment readout, not a standing dashboard" }, { "q": "Order new monitors for the analytics team's war room", "expect": "no-trigger", "split": "validation" }, { "q": "Frame the problem statement for why nobody trusts our metrics before we build anything", "expect": "no-trigger", "split": "validation" } ] }
-
-
references
-
EXAMPLE.md 13.9 KB
--- artifact: dashboard-requirements version: "1.0" created: 2026-01-14 status: complete context: Product health dashboard for SaaS platform --- # Dashboard Requirements: Product Health Dashboard ## Overview **Dashboard Name:** Product Health Dashboard **Requestor:** Maya Johnson, Product Manager **Date:** January 2026 **Priority:** High **Target Delivery:** End of Q1 2026 --- ## Purpose and Questions ### Primary Questions This Dashboard Answers 1. **Are users healthy?** What is our overall user engagement and are users getting value from the product? 2. **Where do users struggle?** Which parts of the product have the highest friction or drop-off? 3. **What features drive retention?** Which features, when adopted, correlate with long-term retention? 4. **Are we trending up or down?** How do key metrics compare to previous periods? ### Decisions This Will Inform - Prioritization of product improvements based on friction points - Feature investment decisions based on retention correlation - Resource allocation to high-impact areas - Early warning on user health problems before they hit revenue ### What This Dashboard Is NOT For - Deep-dive analysis on specific features (separate feature dashboards exist) - Real-time operational monitoring (use DataDog for that) - Individual user support (use admin tools) - Financial/revenue metrics (finance owns that dashboard) --- ## Audience | Audience | Usage Frequency | Primary Questions | |----------|-----------------|-------------------| | Product Team | Daily | Feature adoption, user friction | | Leadership | Weekly | Overall health trends, KPIs | | Engineering | Weekly | Error rates, performance impact on UX | | Customer Success | Daily | Account health signals | ### Usage Context **When will this be viewed?** - Product team: Daily standup (quick KPI check) and weekly deep-dive - Leadership: Weekly product review meeting - CS: Before customer calls to assess account health **What device/format?** - Desktop browser (primary) - Shared on TV in product team area - Exported to PDF for monthly board reports --- ## Key Metrics ### Metric 1: Daily Active Users (DAU) | Attribute | Value | |-----------|-------| | **Business Definition** | Unique users who performed any meaningful action in the product on a given day | | **Calculation** | COUNT(DISTINCT user_id) WHERE action_type NOT IN ('login', 'logout') AND event_date = date | | **Data Source** | events.user_actions table | | **Granularity** | Daily | | **Current Baseline** | 12,400 | | **Target** | 15,000 by end of Q2 | | **Notes** | Excludes bot accounts and internal users | ### Metric 2: DAU/MAU Ratio (Stickiness) | Attribute | Value | |-----------|-------| | **Business Definition** | Ratio of daily active users to monthly active users, indicating how often users return | | **Calculation** | DAU / MAU (rolling 30-day MAU) | | **Data Source** | Derived from events.user_actions | | **Granularity** | Daily | | **Current Baseline** | 0.32 (32%) | | **Target** | 0.40 (40%) | | **Notes** | Industry benchmark for SaaS is 0.20-0.40 | ### Metric 3: Feature Adoption Rate | Attribute | Value | |-----------|-------| | **Business Definition** | Percentage of MAU who have used each core feature at least once in the past 30 days | | **Calculation** | COUNT(DISTINCT users who used feature) / MAU | | **Data Source** | events.feature_usage table | | **Granularity** | Daily (rolling 30-day) | | **Current Baseline** | Varies by feature (see chart) | | **Target** | Top 5 features > 50% adoption | | **Notes** | Breakdown by feature; shows per-feature adoption | ### Metric 4: User Retention (Cohort-based) | Attribute | Value | |-----------|-------| | **Business Definition** | Percentage of users from a signup cohort who are still active after N days | | **Calculation** | (Active users in cohort at day N) / (Total users in cohort) | | **Data Source** | events.user_actions + users.signups | | **Granularity** | Weekly cohorts, measured at D7, D14, D30, D60, D90 | | **Current Baseline** | D30: 42% | | **Target** | D30: 55% | | **Notes** | Compare cohorts over time to see if retention is improving | ### Metric 5: Time to First Value (TTFV) | Attribute | Value | |-----------|-------| | **Business Definition** | Time from signup to completing first meaningful action (creating first project) | | **Calculation** | MEDIAN(first_project_created_at - signup_at) | | **Data Source** | users.signups + events.project_created | | **Granularity** | Daily (rolling 7-day average) | | **Current Baseline** | 2.3 days | | **Target** | < 1 day | | **Notes** | Users who never create a project counted as NULL/excluded | ### Metrics Summary Table | Metric | Definition | Source | Target | |--------|------------|--------|--------| | DAU | Unique users with meaningful action | events.user_actions | 15,000 | | DAU/MAU | Stickiness ratio | Derived | 40% | | Feature Adoption | % MAU using each feature | events.feature_usage | Top 5 > 50% | | D30 Retention | Users active 30 days post-signup | events + users | 55% | | TTFV | Time to first project creation | events + users | < 1 day | --- ## Visualization Specifications ### Chart 1: KPI Summary Cards | Attribute | Value | |-----------|-------| | **Purpose** | At-a-glance health check of key metrics | | **Chart Type** | KPI Cards (4 cards in a row) | | **Metrics Shown** | DAU, DAU/MAU, D30 Retention, TTFV | | **Comparison** | Show vs. previous period and vs. target | | **Interactivity** | Click card to see trend chart | | **Position** | Top of dashboard, most prominent | ### Chart 2: Engagement Trend | Attribute | Value | |-----------|-------| | **Purpose** | Show DAU and MAU trends over time | | **Chart Type** | Line chart with dual axis | | **X-Axis** | Date (daily) | | **Y-Axis** | Left: DAU, Right: DAU/MAU ratio | | **Series/Breakdown** | DAU line, MAU line, DAU/MAU line | | **Interactivity** | Hover for values, zoom on date range | | **Position** | Top-left main section | ### Chart 3: Feature Adoption Breakdown | Attribute | Value | |-----------|-------| | **Purpose** | Show which features users are/aren't adopting | | **Chart Type** | Horizontal bar chart | | **X-Axis** | Adoption rate (%) | | **Y-Axis** | Feature name | | **Series/Breakdown** | Single series, sorted by adoption | | **Interactivity** | Click bar to see feature trend over time | | **Position** | Top-right main section | ### Chart 4: Retention Cohort Heatmap | Attribute | Value | |-----------|-------| | **Purpose** | Compare retention across weekly cohorts | | **Chart Type** | Cohort heatmap (weeks × retention periods) | | **X-Axis** | Days since signup (D1, D7, D14, D30, D60, D90) | | **Y-Axis** | Signup week cohort | | **Series/Breakdown** | Color intensity = retention % | | **Interactivity** | Hover for exact values | | **Position** | Middle section, full width | ### Chart 5: Funnel Drop-off Analysis | Attribute | Value | |-----------|-------| | **Purpose** | Identify where users struggle in key flows | | **Chart Type** | Funnel chart | | **X-Axis** | Funnel step | | **Y-Axis** | Users (absolute and %) | | **Series/Breakdown** | Steps: Signup → Onboarding Complete → First Project → Invited Team → Paid | | **Interactivity** | Click step to see breakdown by segment | | **Position** | Bottom-left | ### Chart 6: Detailed Metrics Table | Attribute | Value | |-----------|-------| | **Purpose** | Detailed view for deep-dive analysis | | **Chart Type** | Data table with sorting | | **Columns** | Date, DAU, MAU, DAU/MAU, New Signups, Churned Users, Feature 1-5 adoption | | **Interactivity** | Sort by any column, export to CSV | | **Position** | Bottom section, collapsible | ### Dashboard Layout Sketch ``` ┌─────────────────────────────────────────────────────────────────────┐ │ [DAU: 12.4K] [Stickiness: 32%] [D30 Ret: 42%] [TTFV: 2.3d] │ │ ▲ +5% ▼ -2% ▲ +3% ▼ +0.2d │ ├────────────────────────────────┬────────────────────────────────────┤ │ │ │ │ 📈 Engagement Trend │ 📊 Feature Adoption │ │ [Line chart: DAU/MAU] │ [Horizontal bars by feature] │ │ │ │ ├────────────────────────────────┴────────────────────────────────────┤ │ │ │ 🔲 Retention Cohort Heatmap │ │ [Week cohorts × D1/D7/D14/D30/D60/D90] │ │ │ ├────────────────────────────────┬────────────────────────────────────┤ │ │ │ │ ⬇️ Funnel Analysis │ 📋 Detailed Data Table │ │ [Signup → Value funnel] │ [Sortable metric table] │ │ │ │ └────────────────────────────────┴────────────────────────────────────┘ ``` --- ## Filters and Segments ### Global Filters | Filter | Type | Default Value | Options | |--------|------|---------------|---------| | Date Range | Date picker | Last 30 days | Last 7/30/90 days, MTD, QTD, Custom | | Plan Type | Multi-select | All | Free, Starter, Professional, Enterprise | | User Segment | Multi-select | All | New (<30d), Active, At-risk, Churned | | Platform | Dropdown | All | Web, iOS, Android | ### Chart-Specific Filters | Chart | Filter | Type | |-------|--------|------| | Feature Adoption | Feature category | Dropdown (Core, Advanced, Admin) | | Funnel | Entry point | Dropdown (Organic, Paid, Referral) | ### Segment Definitions | Segment Name | Definition | Use Case | |--------------|------------|----------| | New Users | Signed up within last 30 days | Track onboarding effectiveness | | At-Risk | No login in 14+ days but not churned | Target for re-engagement | | Power Users | > 20 sessions per month | Understand ideal user behavior | | Enterprise | On Enterprise plan | Compare enterprise vs. SMB health | --- ## Data Sources ### Primary Sources | Source | Type | Owner | Latency | Quality Notes | |--------|------|-------|---------|---------------| | events.user_actions | Snowflake table | Data Engineering | 1 hour | 99.9% complete | | events.feature_usage | Snowflake table | Data Engineering | 1 hour | Some features not instrumented | | users.signups | Snowflake table | Data Engineering | Real-time | Authoritative source | | users.subscriptions | Snowflake table | Data Engineering | Daily | Synced from Stripe | ### Data Pipeline Requirements **Refresh Frequency:** Hourly during business hours, daily overnight **Refresh Time:** Dashboard current as of top-of-hour; overnight refresh complete by 6am UTC **Historical Data Needed:** Last 24 months **Data Retention:** Aggregated data retained indefinitely; raw events 24 months ### Data Quality Considerations - Bot traffic filtered but occasional false positives; flag if DAU spikes >20% unexpectedly - Feature usage for "Reports" feature incomplete before Nov 2025 (instrumentation added) - Enterprise accounts have multiple users; user_id is individual, account_id needed for account-level views --- ## Access and Permissions ### Access Levels | Role/Group | Access Level | Restrictions | |------------|--------------|--------------| | Product Team | Full access | None | | Engineering | Full access | None | | Leadership | Full access | None | | Customer Success | Limited | Cannot see individual user data | | Sales | View only | Cannot export, account-level only | ### Sensitive Data | Data Element | Sensitivity | Handling | |--------------|-------------|----------| | User email | PII | Not displayed; use user_id | | Account name | Confidential | Visible to CS/Sales only | --- ## Alerts and Thresholds | Condition | Threshold | Action | Recipients | |-----------|-----------|--------|------------| | DAU drops below | 10,000 | Email + Slack | Product team | | D30 retention drops below | 35% | Email | PM + Leadership | | TTFV exceeds | 5 days | Slack | Onboarding squad | | Feature adoption (any) drops | >10% week-over-week | Email | Feature owner | --- ## Acceptance Criteria - [ ] All 5 core metrics display correctly and match manual SQL verification - [ ] Cohort retention heatmap shows at least 12 weeks of historical cohorts - [ ] All filters work across all charts simultaneously - [ ] Dashboard loads in under 5 seconds on standard connection - [ ] Data refreshes correctly by 7am UTC each morning - [ ] CS team confirms they can access account-level data - [ ] Export to CSV works for detailed table - [ ] Mobile-responsive for leadership checking on phones --- ## Open Questions - Should we include revenue/MRR on this dashboard or keep it separate? - Do we need real-time DAU or is hourly sufficient? - Should cohorts be weekly or monthly granularity? --- ## Appendix ### Related Dashboards - Feature Deep-Dive: Reporting (dashboard link) - Onboarding Funnel Dashboard (dashboard link) - Finance & Revenue Dashboard (dashboard link) ### Reference Documents - Metric Definitions Wiki (internal link) - Data Dictionary (internal link) - Instrumentation Spec for Feature Tracking (internal link) --- *Requirements version 1.0. Update as needs evolve.* -
TEMPLATE.md 8.2 KB
--- artifact: dashboard-requirements version: "1.0" created: YYYY-MM-DD status: draft --- # Dashboard Requirements: [Dashboard Name] ## Overview **Dashboard Name:** [Name] **Requestor:** [Who requested this] **Date:** [When requirements captured] **Priority:** [High/Medium/Low] **Target Delivery:** [When needed] --- ## Purpose and Questions ### Primary Questions This Dashboard Answers <!-- Frame as questions, not metrics --> 1. [Question 1 - e.g., "Are users successfully completing onboarding?"] 2. [Question 2 - e.g., "Where do users drop off in the funnel?"] 3. [Question 3 - e.g., "Which cohorts have the best retention?"] ### Decisions This Will Inform <!-- What actions will stakeholders take based on this dashboard --> - [Decision 1] - [Decision 2] - [Decision 3] ### What This Dashboard Is NOT For <!-- Clarify scope boundaries --> - [Out of scope item 1] - [Out of scope item 2] --- ## Audience | Audience | Usage Frequency | Primary Questions | |----------|-----------------|-------------------| | [Role/Team 1] | [Daily/Weekly/Monthly] | [What they care about] | | [Role/Team 2] | [Daily/Weekly/Monthly] | [What they care about] | | [Role/Team 3] | [Daily/Weekly/Monthly] | [What they care about] | ### Usage Context **When will this be viewed?** [E.g., "Weekly team meeting review", "Daily morning check", "Monthly board prep"] **What device/format?** [E.g., "Desktop browser", "TV screen in office", "Mobile for on-the-go"] --- ## Key Metrics ### Metric 1: [Metric Name] | Attribute | Value | |-----------|-------| | **Business Definition** | [Plain language explanation] | | **Calculation** | [Formula: numerator / denominator, etc.] | | **Data Source** | [Where data comes from] | | **Granularity** | [Daily/Weekly/Monthly] | | **Current Baseline** | [Current value if known] | | **Target** | [Goal value] | | **Notes** | [Edge cases, known issues] | ### Metric 2: [Metric Name] | Attribute | Value | |-----------|-------| | **Business Definition** | [Plain language explanation] | | **Calculation** | [Formula: numerator / denominator, etc.] | | **Data Source** | [Where data comes from] | | **Granularity** | [Daily/Weekly/Monthly] | | **Current Baseline** | [Current value if known] | | **Target** | [Goal value] | | **Notes** | [Edge cases, known issues] | ### Metric 3: [Metric Name] | Attribute | Value | |-----------|-------| | **Business Definition** | [Plain language explanation] | | **Calculation** | [Formula: numerator / denominator, etc.] | | **Data Source** | [Where data comes from] | | **Granularity** | [Daily/Weekly/Monthly] | | **Current Baseline** | [Current value if known] | | **Target** | [Goal value] | | **Notes** | [Edge cases, known issues] | ### Metrics Summary Table | Metric | Definition | Source | Target | |--------|------------|--------|--------| | [Metric 1] | [Short definition] | [Source] | [Target] | | [Metric 2] | [Short definition] | [Source] | [Target] | | [Metric 3] | [Short definition] | [Source] | [Target] | | [Metric 4] | [Short definition] | [Source] | [Target] | --- ## Visualization Specifications ### Chart 1: [Chart Title] | Attribute | Value | |-----------|-------| | **Purpose** | [What question this answers] | | **Chart Type** | [Line/Bar/Pie/Table/etc.] | | **X-Axis** | [Dimension - e.g., Date, Category] | | **Y-Axis** | [Metric(s)] | | **Series/Breakdown** | [How data is grouped] | | **Interactivity** | [Tooltips, drill-down, click actions] | | **Position** | [Top-left, prominent, etc.] | ### Chart 2: [Chart Title] | Attribute | Value | |-----------|-------| | **Purpose** | [What question this answers] | | **Chart Type** | [Line/Bar/Pie/Table/etc.] | | **X-Axis** | [Dimension - e.g., Date, Category] | | **Y-Axis** | [Metric(s)] | | **Series/Breakdown** | [How data is grouped] | | **Interactivity** | [Tooltips, drill-down, click actions] | | **Position** | [Top-left, prominent, etc.] | ### Chart 3: [Chart Title] | Attribute | Value | |-----------|-------| | **Purpose** | [What question this answers] | | **Chart Type** | [Line/Bar/Pie/Table/etc.] | | **X-Axis** | [Dimension - e.g., Date, Category] | | **Y-Axis** | [Metric(s)] | | **Series/Breakdown** | [How data is grouped] | | **Interactivity** | [Tooltips, drill-down, click actions] | | **Position** | [Top-left, prominent, etc.] | ### Dashboard Layout Sketch <!-- ASCII layout or link to mockup --> ``` ┌─────────────────────────────────────────────────┐ │ [KPI Card 1] [KPI Card 2] [KPI Card 3] │ ├────────────────────────┬────────────────────────┤ │ │ │ │ [Chart 1: Trend] │ [Chart 2: Funnel] │ │ │ │ ├────────────────────────┴────────────────────────┤ │ │ │ [Chart 3: Detailed Table] │ │ │ └─────────────────────────────────────────────────┘ ``` --- ## Filters and Segments ### Global Filters <!-- Filters that apply to entire dashboard --> | Filter | Type | Default Value | Options | |--------|------|---------------|---------| | Date Range | Date picker | Last 30 days | Custom, presets | | [Filter 2] | [Dropdown/Multi-select] | [Default] | [Options] | | [Filter 3] | [Dropdown/Multi-select] | [Default] | [Options] | ### Chart-Specific Filters <!-- Filters for individual charts --> | Chart | Filter | Type | |-------|--------|------| | [Chart 1] | [Filter] | [Type] | | [Chart 2] | [Filter] | [Type] | ### Segment Definitions <!-- Pre-defined segments for analysis --> | Segment Name | Definition | Use Case | |--------------|------------|----------| | [Segment 1] | [Criteria] | [When to use] | | [Segment 2] | [Criteria] | [When to use] | --- ## Data Sources ### Primary Sources | Source | Type | Owner | Latency | Quality Notes | |--------|------|-------|---------|---------------| | [Source 1] | [Database/API/File] | [Team] | [Real-time/Daily/etc.] | [Known issues] | | [Source 2] | [Database/API/File] | [Team] | [Real-time/Daily/etc.] | [Known issues] | ### Data Pipeline Requirements **Refresh Frequency:** [Real-time / Hourly / Daily / Weekly] **Refresh Time:** [When refresh should complete, e.g., "by 6am UTC"] **Historical Data Needed:** [How far back, e.g., "Last 12 months"] **Data Retention:** [How long to keep, e.g., "Rolling 2 years"] ### Data Quality Considerations - [Known data quality issue 1 and how to handle] - [Known data quality issue 2 and how to handle] --- ## Access and Permissions ### Access Levels | Role/Group | Access Level | Restrictions | |------------|--------------|--------------| | [Group 1] | Full access | None | | [Group 2] | View only | Cannot export | | [Group 3] | Limited | Only sees [section] | ### Sensitive Data | Data Element | Sensitivity | Handling | |--------------|-------------|----------| | [Element 1] | [PII/Confidential/etc.] | [Mask/Aggregate/Restrict] | --- ## Alerts and Thresholds <!-- Optional: automated notifications --> | Condition | Threshold | Action | Recipients | |-----------|-----------|--------|------------| | [Metric 1] drops below | [Value] | Send email | [Who] | | [Metric 2] exceeds | [Value] | Slack alert | [Channel] | --- ## Acceptance Criteria <!-- How do we know the dashboard is complete and correct --> - [ ] All metrics match definitions when spot-checked - [ ] Filters work correctly across all charts - [ ] Dashboard loads in under [X] seconds - [ ] All users can access with correct permissions - [ ] Data refreshes by [time] each day --- ## Open Questions - [Question 1 for data team] - [Question 2 needing clarification] --- ## Appendix ### Related Dashboards - [Link to related dashboard 1] - [Link to related dashboard 2] ### Reference Documents - [Link to metric definitions] - [Link to data dictionary] --- *Requirements version 1.0. Update as needs evolve.*
-
-
HISTORY.md 1.9 KB
# measure-dashboard-requirements - Version History | Version | Date | Release | Effort | Type | Summary | |---------|------|---------|--------|------|---------| | 2.2.0 | 2026-07-04 | v2.30.0 | M-35 | minor | Rewrote the frontmatter description: added the "questions before charts" framing and the sibling deflection to `measure-instrumentation-spec`, a real collision pair with near-identical original wording. One of the four additional Batch 5 skills selected for this release. | | 2.1.0 | 2026-06-10 | v2.26.0 | F-12-batch-4 | minor | Quality convergence: When NOT to Use + output-contract enumeration (F-12 Batch 4) | | 2.0.0 | 2026-01-26 | - | - | baseline | Prior published version | ## 2.2.0 (2026-07-04) Released in [v2.30.0](../../site/src/content/docs/releases/Release_v2.30.0.md). Effort: M-35 (trust repair sweep). The 2026-07-04 deep audit named the catalog's ~8 weakest early-cohort descriptions for rewrite (Batch 5). This skill and its companion `measure-instrumentation-spec` were picked as a pair: both original descriptions used the near-identical template ("Specifies requirements for X ... Use when Y, Z, or W") with no cross-reference between them, despite both being real measure-phase neighbors already tested by each other's trigger fixtures. ### Changes - Rewrote the frontmatter description (Batch 5, WS-T8e) to lead with "questions before charts" and surface the `measure-instrumentation-spec` deflection already present in the "When NOT to Use" section. No change to the Instructions, Output Format, or Quality Checklist. ## 2.1.0 (2026-06-10) Quality-convergence minor (F-12 Batch 4): added a "When NOT to Use" section with boundary pointers to neighboring skills, and the Output Format now enumerates the template sections a complete artifact fills. No template or example changes. ## 2.0.0 (2026-01-26) Baseline row for the prior published version; see git history for its changes. -
SKILL.md 4.1 KB
--- name: measure-dashboard-requirements description: 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 event tracking that feeds the dashboard, use measure-instrumentation-spec instead; instrument first, visualize second. license: Apache-2.0 metadata: phase: measure version: "2.2.0" updated: 2026-07-04 category: validation frameworks: [triple-diamond, lean-startup, design-thinking] author: product-on-purpose --- <!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 --> # 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 ## When NOT to Use - You need the event tracking that feeds dashboards -> use `measure-instrumentation-spec`; instrument first, visualize second - You are designing an experiment readout, not a standing dashboard -> use `measure-experiment-design` and `measure-experiment-results` - You want OKR progress scored at cycle close -> use `measure-okr-grader` - The questions the dashboard should answer are not yet agreed -> frame outcomes first with `foundation-okr-writer` or `define-problem-statement` ## Instructions When asked to specify dashboard requirements, follow these steps: 1. **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. 2. **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. 3. **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. 4. **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. 5. **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. 6. **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? 7. **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. 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. ## 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.
Comments (0)
Sign in to join the conversation.
Reviews (0)
No reviews yet.
No comments yet.