Measure Dashboard Requirements

Name: Measure Dashboard Requirements
Author: product-on-purpose

product-on-purpose/pm-skills

507 installs
518 repo stars
Updated August 4, 2026
product-on-purpose/pm-skills

measure-dashboard-requirements is a pm-skills agent skill that writes structured analytics dashboard specifications—metrics, chart types, filters, and data sources—for developers and PMs who need decision-oriented report

About

measure-dashboard-requirements is a pm-skills Measure-phase skill (version 2.1.0) that turns product questions into a dashboard requirements document data teams can implement. The workflow walks through seven steps: define purpose as questions to answer, identify audience and cadence, specify metrics with formulas and baselines, recommend visualization types, define filters and segments, document data sources and latency, and set access permissions. Output follows a template with eleven sections including Purpose and Questions, Key Metrics, Visualization Specifications, Alerts and Thresholds, and Acceptance Criteria. The skill sits in pm-skills alongside five other Measure skills such as experiment-design and instrumentation-spec. Reach for measure-dashboard-requirements when requesting a new Looker, Metabase, or internal analytics dashboard, formalizing KPI tracking before quarterly planning, or onboarding stakeholders to self-serve reporting.

measure-dashboard-requirements
AI & Agent Building
AI-coding skill

Measure Dashboard Requirements by the numbers

507 all-time installs (skills.sh)
+34 installs in the week ending Aug 4, 2026 (Skillselion tracking)
Ranked #1,752 of 16,546 AI & Agent Building skills by installs in the Skillselion catalog
Data as of Aug 5, 2026 (Skillselion catalog sync)

npx skills add https://github.com/product-on-purpose/pm-skills --skill measure-dashboard-requirements

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

[![Listed on Skillselion](https://skillselion.com/badge/skills/product-on-purpose/pm-skills/measure-dashboard-requirements.svg)](https://skillselion.com/skills/product-on-purpose/pm-skills/measure-dashboard-requirements)

Installs	507
repo stars	★ 518
Last updated	August 4, 2026
Repository	product-on-purpose/pm-skills ↗

How do you write analytics dashboard requirements for engineers?

Helps with ai & agent building tasks.

Who is it for?

Product managers and tech leads who must brief data or analytics engineers on a new KPI dashboard with unambiguous metric definitions.

Skip if: Developers who need event instrumentation specs or A/B experiment design rather than a standing dashboard requirements document.

When should I use this skill?

A developer or PM asks to specify dashboard metrics, define KPI tracking, or document reporting needs before handing work to a data team.

What you get

Dashboard requirements document with metric definitions, visualization specs, filter segments, data sources, access rules, and acceptance criteria.

dashboard requirements document
metric definition tables
visualization and filter specifications

By the numbers

Skill version 2.1.0 with a 7-step requirements workflow
Output template covers 11 specification sections
One of 6 skills in the pm-skills Measure validation phase

Files

SKILL.mdMarkdownGitHub ↗

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.

{
  "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"
    }
  ]
}

measure-dashboard-requirements - Version History

Version	Date	Release	Effort	Type	Summary
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.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.

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.

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

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

[Decision 1]
[Decision 2]
[Decision 3]

What This Dashboard Is NOT For

[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

┌─────────────────────────────────────────────────┐
│  [KPI Card 1]  [KPI Card 2]  [KPI Card 3]      │
├────────────────────────┬────────────────────────┤
│                        │                        │
│   [Chart 1: Trend]     │   [Chart 2: Funnel]   │
│                        │                        │
├────────────────────────┴────────────────────────┤
│                                                 │
│            [Chart 3: Detailed Table]            │
│                                                 │
└─────────────────────────────────────────────────┘

---

Filters and Segments

Global Filters

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

Chart	Filter	Type
[Chart 1]	[Filter]	[Type]
[Chart 2]	[Filter]	[Type]

Segment Definitions

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

Condition	Threshold	Action	Recipients
[Metric 1] drops below	[Value]	Send email	[Who]
[Metric 2] exceeds	[Value]	Slack alert	[Channel]

---

Acceptance Criteria

[ ] 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.

Related skills

Setup Matt Pocock SkillsScaffold the per-repo configuration that Matt Pocock’s engineering agent skills rely on so they understand the issue tracker, triage labels, and domain documentation la495k196k

Lark AppsConnect Claude, Cursor or custom agents directly to Lark (Feishu) for messaging, document automation, approval workflows and enterprise data access.402k

CavemanSlash token usage by roughly 75% while keeping every technical detail intact when working with Claude Code, Cursor or similar agents.391k94.7k

Lark Skill MakerQuickly turn any Lark/Feishu OpenAPI call or multi-step workflow into a reusable agent skill with its own SKILL.md.386k16k

Running Claude Code Via Litellm CopilotRun Claude Code at a fraction of the cost by routing requests through LiteLLM to the GitHub Copilot Chat API.270k72

Codex PetGenerate a complete Codex Pet spritesheet and metadata from one reference image without needing an OpenAI key or Codex Pro.246k10

How it compares

Pick measure-dashboard-requirements over experiment-design when the deliverable is a standing analytics dashboard, not a one-off A/B test readout.

FAQ

What does measure-dashboard-requirements output?

measure-dashboard-requirements outputs a dashboard requirements document using the pm-skills template: purpose questions, audience, metric definitions with formulas, visualization specs, filters, data sources, permissions, alerts, and acceptance criteria.

When should developers use measure-dashboard-requirements?

measure-dashboard-requirements fits when requesting a new analytics dashboard, defining KPI tracking for a feature, or formalizing ad-hoc reporting. Use measure-instrumentation-spec first if event tracking is not yet defined.

AI & Agent Buildingagents