Create a Risks and Tradeoffs Section for a Spec
Produces a structured risks and tradeoffs section covering user, technical, business, and timing risks with mitigations. Built for PMs preparing specs for executive review.
When to use this prompt
Use this when a spec is heading to an executive review where leadership will ask 'what could go wrong?' and you want to answer before they ask. You will need the spec overview, the known constraints, and any prior postmortems or risk context from similar work. The prompt produces a structured taxonomy rather than a free-form list, which forces you to consider categories you might otherwise miss (timing risks are especially often skipped). It is not a substitute for formal risk management on regulated features; treat it as a structured brainstorm, not a compliance artifact.
The Prompt
You are a product manager drafting the risks and tradeoffs section of a spec that is heading to executive review. The section must use a 4-axis risk taxonomy and produce concrete mitigations. Spec overview: {{spec_overview}} Known constraints: {{constraints}} Timeline: {{timeline}} Prior context: {{prior_context}} Produce risks across these 4 axes. For each axis, identify 2-4 risks, each with: - RISK NAME (short) - DESCRIPTION (2 sentences) - PROBABILITY: LOW / MEDIUM / HIGH - IMPACT: LOW / MEDIUM / HIGH - MITIGATION: 1-2 sentences, concrete (not "monitor carefully") - OWNER: role that would handle the risk if it materialized Risk axes: 1. USER RISK â Risks related to adoption, confusion, negative reactions, trust impact. 2. TECHNICAL RISK â Scalability, reliability, security, dependency fragility, performance regressions. 3. BUSINESS RISK â Revenue impact, legal/compliance, brand damage, partner relationships, cost overruns. 4. TIMING RISK â Delays, market timing, dependency slippage, resource conflicts, competitive moves. After the risk list, produce two more sections: TRADEOFFS â 3-5 explicit tradeoffs the spec makes. Each as "We chose X over Y because Z." Make the Y option real, not a strawman. ASSUMPTIONS â Things the spec takes for granted that could be wrong. Each with 1 line of "how we would know if this is wrong." Be honest. The value of this section is surfacing risks that a polished spec hides. Do not pad with generic risks like "scope creep" unless they are specifically likely here.
Example Output
USER RISK - Existing admins dislike new default sort. Prob: MEDIUM, Impact: MEDIUM. Mitigation: in-app tour plus opt-out toggle. Owner: Design. - Color-blind users miss overdue badge. Prob: HIGH if relying on color only, Impact: MEDIUM. Mitigation: use icon and label in addition to color. Owner: Accessibility review. TECHNICAL RISK - Overdue computation at query time regresses page load. Prob: MEDIUM, Impact: HIGH at p99. Mitigation: benchmark on staging with production-scale data. Owner: EM. - Timezone handling incorrect for non-UTC accounts. Prob: MEDIUM, Impact: HIGH (trust). Mitigation: explicit test cases per timezone, SRE review. Owner: EM. BUSINESS RISK - Finance teams treat computed overdue as legal status. Prob: LOW, Impact: HIGH. Mitigation: disclaimer in UI, legal review. Owner: Legal. TIMING RISK - Launch overlaps with customer end-of-quarter close. Prob: HIGH, Impact: HIGH trust. Mitigation: delay GA by 2 weeks or launch behind flag only. Owner: PM. - Dependency on shared auth refactor. Prob: MEDIUM. Mitigation: start parallel work that does not depend on refactor. Owner: EM. TRADEOFFS - We chose server-side computation over client-side because client-side would drift with user clocks. - We chose sort-and-badge over a separate overdue page because it kept navigation flat. - We chose no email automation in v1 to ship faster even though several customers asked for it. ASSUMPTIONS - Customers use default sort (validated with current sort usage telemetry). - Overdue thresholds are consistent at 30 days (wrong for 2 large accounts; confirmed).
Recommended Tools
Notion and Coda render the risk taxonomy as an editable table that execs can comment on during review. Airtable is the right choice when your team maintains a longitudinal risk register across multiple specs and wants to track how past risks materialized. Use Notion or Coda for single-spec reviews; use Airtable when risk management is a recurring discipline across quarters.
Frequently Asked Questions
When should I use this prompt?
Use it before any executive review, launch readiness meeting, or cross-functional spec walkthrough. It is especially valuable for specs where past similar work had postmortems; the prompt lets you pattern-match on known failure modes. Do not use it on trivial changes where the risk list would be shorter than the prompt template. Run it as a brainstorm and then have a peer PM or tech lead review for missing risks; a single perspective always has blind spots, and risks you do not see are the ones that bite you.
How do I avoid generic risks like 'scope creep'?
The rule in the prompt is explicit: do not include generic risks unless they are specifically likely here. If the model outputs a generic risk, ask it to either replace it with a specific version or delete it. For example, 'scope creep' becomes useful only when you can name which part of the scope is likely to creep and why. Generic risks add noise without insight. The value of this section is the 2-3 specific risks that surprise the exec reviewer, not the comprehensive enumeration of every conceivable thing that could go wrong.