product_pulse_reports v1.0.0

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).

1. 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.
2. 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.
3. 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.