Skip to content

Dashboard Requirements

Try it: /pm-skills:measure-dashboard-requirements "Your context here"

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 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
  • 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

Invoke the skill by name (/pm-skills:measure-dashboard-requirements on Claude Code, $measure-dashboard-requirements on Codex):

/pm-skills:measure-dashboard-requirements "Your context here"

Or reference the skill file directly: skills/measure-dashboard-requirements/SKILL.md

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.

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.

See references/EXAMPLE.md for a completed example.

Dashboard Name: [Name] Requestor: [Who requested this] Date: [When requirements captured] Priority: [High/Medium/Low] Target Delivery: [When needed]


  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?”]
  • [Decision 1]
  • [Decision 2]
  • [Decision 3]
  • [Out of scope item 1]
  • [Out of scope item 2]

AudienceUsage FrequencyPrimary 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]

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”]


AttributeValue
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]
AttributeValue
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]
AttributeValue
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]
MetricDefinitionSourceTarget
[Metric 1][Short definition][Source][Target]
[Metric 2][Short definition][Source][Target]
[Metric 3][Short definition][Source][Target]
[Metric 4][Short definition][Source][Target]

AttributeValue
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.]
AttributeValue
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.]
AttributeValue
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.]
┌─────────────────────────────────────────────────┐
│ [KPI Card 1] [KPI Card 2] [KPI Card 3] │
├────────────────────────┬────────────────────────┤
│ │ │
│ [Chart 1: Trend] │ [Chart 2: Funnel] │
│ │ │
├────────────────────────┴────────────────────────┤
│ │
│ [Chart 3: Detailed Table] │
│ │
└─────────────────────────────────────────────────┘

FilterTypeDefault ValueOptions
Date RangeDate pickerLast 30 daysCustom, presets
[Filter 2][Dropdown/Multi-select][Default][Options]
[Filter 3][Dropdown/Multi-select][Default][Options]
ChartFilterType
[Chart 1][Filter][Type]
[Chart 2][Filter][Type]
Segment NameDefinitionUse Case
[Segment 1][Criteria][When to use]
[Segment 2][Criteria][When to use]

SourceTypeOwnerLatencyQuality 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]

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”]

  • [Known data quality issue 1 and how to handle]
  • [Known data quality issue 2 and how to handle]

Role/GroupAccess LevelRestrictions
[Group 1]Full accessNone
[Group 2]View onlyCannot export
[Group 3]LimitedOnly sees [section]
Data ElementSensitivityHandling
[Element 1][PII/Confidential/etc.][Mask/Aggregate/Restrict]

ConditionThresholdActionRecipients
[Metric 1] drops below[Value]Send email[Who]
[Metric 2] exceeds[Value]Slack alert[Channel]

  • 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

  • [Question 1 for data team]
  • [Question 2 needing clarification]

  • [Link to related dashboard 1]
  • [Link to related dashboard 2]
  • [Link to metric definitions]
  • [Link to data dictionary]

Requirements version 1.0. Update as needs evolve.

Dashboard Requirements: Product Health Dashboard

Dashboard Requirements: Product Health Dashboard

Section titled “Dashboard Requirements: Product Health Dashboard”

Dashboard Name: Product Health Dashboard Requestor: Maya Johnson, Product Manager Date: January 2026 Priority: High Target Delivery: End of Q1 2026


  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?
  • 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
  • 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)

AudienceUsage FrequencyPrimary Questions
Product TeamDailyFeature adoption, user friction
LeadershipWeeklyOverall health trends, KPIs
EngineeringWeeklyError rates, performance impact on UX
Customer SuccessDailyAccount health signals

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

AttributeValue
Business DefinitionUnique users who performed any meaningful action in the product on a given day
CalculationCOUNT(DISTINCT user_id) WHERE action_type NOT IN (‘login’, ‘logout’) AND event_date = date
Data Sourceevents.user_actions table
GranularityDaily
Current Baseline12,400
Target15,000 by end of Q2
NotesExcludes bot accounts and internal users
AttributeValue
Business DefinitionRatio of daily active users to monthly active users, indicating how often users return
CalculationDAU / MAU (rolling 30-day MAU)
Data SourceDerived from events.user_actions
GranularityDaily
Current Baseline0.32 (32%)
Target0.40 (40%)
NotesIndustry benchmark for SaaS is 0.20-0.40
AttributeValue
Business DefinitionPercentage of MAU who have used each core feature at least once in the past 30 days
CalculationCOUNT(DISTINCT users who used feature) / MAU
Data Sourceevents.feature_usage table
GranularityDaily (rolling 30-day)
Current BaselineVaries by feature (see chart)
TargetTop 5 features > 50% adoption
NotesBreakdown by feature; shows per-feature adoption
AttributeValue
Business DefinitionPercentage 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 Sourceevents.user_actions + users.signups
GranularityWeekly cohorts, measured at D7, D14, D30, D60, D90
Current BaselineD30: 42%
TargetD30: 55%
NotesCompare cohorts over time to see if retention is improving
AttributeValue
Business DefinitionTime from signup to completing first meaningful action (creating first project)
CalculationMEDIAN(first_project_created_at - signup_at)
Data Sourceusers.signups + events.project_created
GranularityDaily (rolling 7-day average)
Current Baseline2.3 days
Target< 1 day
NotesUsers who never create a project counted as NULL/excluded
MetricDefinitionSourceTarget
DAUUnique users with meaningful actionevents.user_actions15,000
DAU/MAUStickiness ratioDerived40%
Feature Adoption% MAU using each featureevents.feature_usageTop 5 > 50%
D30 RetentionUsers active 30 days post-signupevents + users55%
TTFVTime to first project creationevents + users< 1 day

AttributeValue
PurposeAt-a-glance health check of key metrics
Chart TypeKPI Cards (4 cards in a row)
Metrics ShownDAU, DAU/MAU, D30 Retention, TTFV
ComparisonShow vs. previous period and vs. target
InteractivityClick card to see trend chart
PositionTop of dashboard, most prominent
AttributeValue
PurposeShow DAU and MAU trends over time
Chart TypeLine chart with dual axis
X-AxisDate (daily)
Y-AxisLeft: DAU, Right: DAU/MAU ratio
Series/BreakdownDAU line, MAU line, DAU/MAU line
InteractivityHover for values, zoom on date range
PositionTop-left main section
AttributeValue
PurposeShow which features users are/aren’t adopting
Chart TypeHorizontal bar chart
X-AxisAdoption rate (%)
Y-AxisFeature name
Series/BreakdownSingle series, sorted by adoption
InteractivityClick bar to see feature trend over time
PositionTop-right main section
AttributeValue
PurposeCompare retention across weekly cohorts
Chart TypeCohort heatmap (weeks × retention periods)
X-AxisDays since signup (D1, D7, D14, D30, D60, D90)
Y-AxisSignup week cohort
Series/BreakdownColor intensity = retention %
InteractivityHover for exact values
PositionMiddle section, full width
AttributeValue
PurposeIdentify where users struggle in key flows
Chart TypeFunnel chart
X-AxisFunnel step
Y-AxisUsers (absolute and %)
Series/BreakdownSteps: Signup → Onboarding Complete → First Project → Invited Team → Paid
InteractivityClick step to see breakdown by segment
PositionBottom-left
AttributeValue
PurposeDetailed view for deep-dive analysis
Chart TypeData table with sorting
ColumnsDate, DAU, MAU, DAU/MAU, New Signups, Churned Users, Feature 1-5 adoption
InteractivitySort by any column, export to CSV
PositionBottom section, collapsible
┌─────────────────────────────────────────────────────────────────────┐
│ [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] │
│ │ │
└────────────────────────────────┴────────────────────────────────────┘

FilterTypeDefault ValueOptions
Date RangeDate pickerLast 30 daysLast 7/30/90 days, MTD, QTD, Custom
Plan TypeMulti-selectAllFree, Starter, Professional, Enterprise
User SegmentMulti-selectAllNew (<30d), Active, At-risk, Churned
PlatformDropdownAllWeb, iOS, Android
ChartFilterType
Feature AdoptionFeature categoryDropdown (Core, Advanced, Admin)
FunnelEntry pointDropdown (Organic, Paid, Referral)
Segment NameDefinitionUse Case
New UsersSigned up within last 30 daysTrack onboarding effectiveness
At-RiskNo login in 14+ days but not churnedTarget for re-engagement
Power Users> 20 sessions per monthUnderstand ideal user behavior
EnterpriseOn Enterprise planCompare enterprise vs. SMB health

SourceTypeOwnerLatencyQuality Notes
events.user_actionsSnowflake tableData Engineering1 hour99.9% complete
events.feature_usageSnowflake tableData Engineering1 hourSome features not instrumented
users.signupsSnowflake tableData EngineeringReal-timeAuthoritative source
users.subscriptionsSnowflake tableData EngineeringDailySynced from Stripe

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

  • 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

Role/GroupAccess LevelRestrictions
Product TeamFull accessNone
EngineeringFull accessNone
LeadershipFull accessNone
Customer SuccessLimitedCannot see individual user data
SalesView onlyCannot export, account-level only
Data ElementSensitivityHandling
User emailPIINot displayed; use user_id
Account nameConfidentialVisible to CS/Sales only

ConditionThresholdActionRecipients
DAU drops below10,000Email + SlackProduct team
D30 retention drops below35%EmailPM + Leadership
TTFV exceeds5 daysSlackOnboarding squad
Feature adoption (any) drops>10% week-over-weekEmailFeature owner

  • 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

  • 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?

  • Feature Deep-Dive: Reporting (dashboard link)
  • Onboarding Funnel Dashboard (dashboard link)
  • Finance & Revenue Dashboard (dashboard link)
  • Metric Definitions Wiki (internal link)
  • Data Dictionary (internal link)
  • Instrumentation Spec for Feature Tracking (internal link)

Requirements version 1.0. Update as needs evolve.

See this skill applied to three different product contexts:

Storevine (B2B): Storevine B2B ecommerce platform . Campaigns adoption and revenue analytics dashboard requirements

Prompt:

measure-dashboard-requirements
Dashboard: Campaigns adoption and revenue . post-GA monitoring
Audience: Growth PM (daily), Merchant Success (weekly), Head of Product
(monthly board prep)
Key questions to answer:
1. Are non-adopter merchants sending their first campaign?
(primary hypothesis metric: first-send rate, 60-day window)
2. Is Campaigns driving measurable revenue for merchants?
(7-day attributed revenue per campaign send)
3. Is the email-related churn rate declining since GA?
(churn cohort analysis: merchants with and without Campaigns sends)
Metrics needed:
- First-send rate (60-day, non-adopter segment)
- Campaigns-attributed revenue (7-day window, rolling)
- Active Campaigns merchants (sent ≥1 campaign in last 30 days)
- Churn rate by Campaigns usage cohort
- Send failure rate and unsubscribe rate (guardrails)
Analytics platform: Amplitude (events) + Storevine order DB (revenue)
Need: full dashboard requirements doc with metric definitions,
visualizations, filters, data sources, and acceptance criteria.

Output:

Dashboard Requirements: Campaigns Adoption and Revenue

Section titled “Dashboard Requirements: Campaigns Adoption and Revenue”
Brainshelf (Consumer): Brainshelf consumer PKM app . Resurface experiment dashboard requirements for Amplitude

Prompt:

measure-dashboard-requirements
resurface experiment dashboard for amplitude. need it ready before
the a/b test starts (mar 9).
two audiences:
1. product team (priya, chloe, alex, jordan) . daily monitoring
during the 4-week test
2. marco (ceo) . weekly exec check-in, needs a single-screen summary
questions the dashboard should answer:
- is the treatment group returning more than control?
- are users clicking items in the digest?
- is the unsubscribe rate within the guardrail?
- what's the opt-in funnel conversion rate?
- are there segment differences (library size, cadence)?
charts i want:
1. 7-day return rate trend (treatment vs control, weekly)
2. email CTR trend (daily)
3. opt-in funnel (card viewed → opted in)
4. unsubscribe rate trend (weekly, with guardrail line)
5. segment breakdown table (library size, cadence)
filters: date range, experiment variant, library size segment.

Output:

Dashboard Requirements: Resurface Experiment Dashboard

Section titled “Dashboard Requirements: Resurface Experiment Dashboard”
Workbench (Enterprise): "Workbench enterprise collaboration platform: Blueprints post-launch monitoring dashboard requirements"

Prompt:

measure-dashboard-requirements
I need dashboard requirements for the Blueprints post-launch monitoring dashboard. Here's the context:
**Audiences:**
1. Rachel V. (PM) -- daily check: adoption trends, approval bottlenecks, template usage
2. Sandra C. (Head of Product) -- weekly review: executive summary, account growth, key health metrics
3. Karen L. (Engineering) -- real-time: system health, merge latency, error rates
**Key metrics from the PRD and experiment results:**
- Median time-to-approved (target: ≤2.5 days [fictional])
- Empty-section submission rate (target: ≤10% [fictional])
- Approval cycle count (target: ≤1.5 cycles [fictional])
- Blueprint adoption: monthly active Blueprint creators (target: 2,000 [fictional])
- Enterprise account growth (target: 500 → 650 in 12 months [fictional])
**Data sources:**
- Workbench analytics pipeline (event data from instrumentation spec)
- WebSocket provider telemetry (merge latency, connection count, error rate)
- CRM pipeline (account growth, enterprise tier)
- Support ticketing system (Blueprint-related ticket volume)
**Visualization preferences:**
- Time-to-approved: trend line over time (weekly median)
- Adoption: stacked area chart by department/template type
- Approval funnel: horizontal funnel chart
- System health: real-time gauges with alert thresholds
Please generate the full dashboard requirements including layout, filters, alerts, and acceptance criteria.

Output:

Dashboard Requirements: Blueprints Post-Launch Monitor

Section titled “Dashboard Requirements: Blueprints Post-Launch Monitor”

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