---
name: product_pulse_reports
description: "Write time-windowed product health reports from raw usage, quality, and error signals: triage signals by impact and convert them into owned priorities. Use when asked for a product status review, weekly/monthly product health report, postmortem input, or a data-grounded roadmap briefing."
---

# Product Pulse Reports

## Purpose
Turn raw product signals into a clear, decision-ready time-windowed health report: what users experienced and how the product performed over the period (usage, quality, errors), which signals deserve attention, and which become priorities. Use whenever someone asks for a product status review, a weekly/monthly product health report, an incident postmortem input, or a roadmap-prioritization briefing grounded in product data.

## Workflow
1. **Fix the window and the audience.** State the reporting period (last 7 days, last month, since release X) and who decides what from this report. If nobody owns decisions, stop: a report with no owner is a newsletter, not a tool. See `references/report-cadence.md`.
2. **Collect the four signal blocks.** For the window, gather:
   - **Usage:** reach, activation, engagement on key workflows; completion, abandonment, and funnel conversion.
   - **Quality:** reliability, latency (p50/p95), crash-free sessions, defect escapes, support ticket volume and themes.
   - **Errors:** error rate (errors / attempts), top error clusters by count and affected users, incident count and severity.
   - **Value:** one business signal tied to the product's stated value (revenue, retention, expansion, or cost), never vanity metrics alone.
   Every metric gets a defined calculation, the window it covers, and a baseline (prior window or target).
3. **Triage signals.** For each notable signal, score impact: severity of user harm x delta from baseline x users affected. Sort by impact, not by who shouted loudest. Signals with no verifiable number get cut or flagged as anecdotal, never presented as fact.
4. **Convert to priorities.** For each top signal, write: what changed, why it matters (in user terms), the evidence, the candidate action, and who owns it. One signal, one owner, one proposed next step. A report that names ten problems and assigns none is a complaint form.
5. **Write the report.** Use the template in `assets/pulse-template.md`. Lead with the verdict (healthy / watch / at risk), then the signals table, then priorities. Keep it to one page for execs; link drill-downs, don't embed them.

## Output Contract
- Header: product name, window, date, author, audience/decision owner.
- Verdict line: Healthy, Under watch, or At risk, with the single strongest supporting reason.
- Signal table: metric, this window, prior window, target, delta, status. Max 10-12 metrics.
- Top signals (3-5): what changed, user impact, evidence, owner, proposed action.
- Excluded/anecdotal list: signals cut for lack of evidence, noted as unverified.
- Worked example: `references/worked-example.md`.

## Operating Rules
1. No metric without a definition, a window, and a baseline. Unverifiable = cut or label as anecdote.
2. Correlate with caution: say what changed, not why, unless the evidence pins the cause.
3. Never report vanity metrics without an action they could trigger.
4. Cap severity language: "critical" requires user-facing harm at scale, not a red chart.
5. Keep the report reproducible: anyone with the same data should reach the same verdict.
6. Follow the style law: no em dashes, no press-release phrasing, plain direct language.