scope, customer value, and business outcomes
Key facts
- Purpose
- A complete worked example showing a rough idea becoming a practical PRD with users, goals, non-goals, success metrics, requirements, and risks.
- Example rule
- In a real PRD, mark each important customer claim as observed, measured, requested, inferred, or unknown. That one habit prevents polished fiction.
- Best next step
- Use the same structure for your own PRD.
Raw idea
The starting idea
Raw idea: "Customers keep missing renewals. We should build an AI risk dashboard." That is not a PRD. It is a bundle of assumptions: who is missing renewals, what risk means, why AI is needed, what data exists, and what action the user should take.
Before writing requirements, the PM interviews customer success managers, reviews support tags, reads churn notes, and checks product usage data. The research suggests a narrower problem: managers do not need another dashboard; they need a weekly digest that flags accounts whose risk changed and explains why.
The PRD should now change shape. The solution is not "AI dashboard." The product bet is "weekly account-risk digest with evidence and owner workflow."
- Observed
- CS managers manually scan accounts before renewal meetings.
- Measured
- Usage, support, and renewal dates exist, but risk reasons are scattered.
- Inferred
- A digest may beat a dashboard because the workflow is weekly.
- Unknown
- Whether managers trust generated risk explanations enough to act.
PRD spine
The one-page PRD spine
Problem: Customer success managers miss meaningful account-risk changes because risk signals live across usage analytics, support cases, renewal dates, and notes. By the time the issue appears in a QBR or renewal call, the next action is reactive.
Primary user: CS managers who own 25 to 80 active accounts. Secondary users: account executives, support leads, revenue operations, and executives who inspect retention health.
Product goal: Give CS managers a weekly, explainable list of accounts whose risk increased or decreased, with the reason, owner, suggested next action, and link to source evidence.
- Non-goal: This release does not change the official health score.
- Non-goal: This release does not auto-contact customers.
- Non-goal: This release does not create a general BI dashboard.
- Constraint: Every generated explanation must link to source data.
- Constraint: Managers must be able to dismiss an item with a reason.
Metrics
Success metrics
Primary metric: percent of weekly risk changes reviewed by the account owner within three business days. That is closer to the job than a vanity metric like digest opens.
Diagnostic metrics: digest open rate, number of accounts dismissed as not useful, number of items converted into customer actions, median time from risk change to owner review, and percent of generated explanations with clicked source evidence.
Guardrails: false-positive dismissal rate, support escalation volume, model cost per digest, and user trust survey response. If AI explanations increase noise or cost without action, the release fails even if people open the email.
- Baseline
- UNKNOWN until current manual review behavior is instrumented.
- Target
- Set after two weeks of baseline data, not invented in the PRD.
- Measurement window
- Four weekly digest cycles after launch to pilot cohort.
- Decision
- Expand only if review rate rises without a high false-positive dismissal rate.
Requirements
Requirements that design and engineering can use
Requirement 1: Each Monday, CS managers receive a digest of accounts they own whose risk state changed during the prior week. The digest includes account name, renewal date, risk direction, top reason, suggested next action, and links to source evidence.
Requirement 2: Managers can dismiss a digest item as not useful, already handled, not my account, or other. The dismissal reason is stored for product analysis and excluded from customer-facing records.
Requirement 3: Generated explanations must be traceable to source data. If the system cannot cite supporting data, the item appears as "needs review" rather than as an AI-generated recommendation.
Requirement 4: Revenue operations can configure the pilot cohort and can pause digest delivery without engineering intervention.
- Empty state: no changed-risk accounts produces a short "no material changes" digest.
- Permission state: managers only see accounts they are allowed to view.
- Slow state: digest delivery may be delayed but must not send partial account data.
- Error state: failed generation logs an internal alert and skips the item.
Review
The review catches the original overreach
The first idea asked for an AI dashboard. The PRD ends with a weekly digest pilot. That is not a smaller ambition; it is a clearer test. The team can learn whether account owners trust explainable risk changes before investing in a larger risk workspace.
The PRD also names a kill criterion: if fewer than half of changed-risk items are reviewed by owners after four weekly cycles, or if dismissals show low trust in the reasons, the team pauses expansion and investigates the signal quality.
This is what a worked PRD should do. It turns product enthusiasm into a testable decision, gives engineering a bounded surface, and gives leadership a way to say "continue," "change," or "stop" based on evidence.