Risk Discovery Interview
Position in workflow: v0.4 Screen Flow Definition → v0.5 Risk Discovery Interview → v0.5 Technical Stack Selection
This is an interactive interview skill. The AI asks questions, the user reflects and decides. The goal is to surface risks so the user can mitigate or accept them—not to kill ideas.
Design Principles
- Interview, not inquisition — Facilitate discovery, don't interrogate
- Inform, not kill — Surface risks so user can mitigate, not abandon
- User owns decisions — AI facilitates, user assigns severity and response
- Actionable outputs — Every risk has a mitigation path or explicit "accept"
Risk Categories
| Category |
Focus Area |
Example Questions |
| Market |
Competitors, timing, demand |
"What if [competitor] launches this feature next month?" |
| Technical |
Complexity, unknowns, dependencies |
"Which feature has the most technical uncertainty?" |
| Adoption |
User behavior, activation, retention |
"What's the biggest friction point in onboarding?" |
| Resource |
Team, budget, time |
"If you had to cut scope by 50%, what stays?" |
| Dependency |
External factors, integrations, partners |
"What external factor could block launch?" |
| Timing |
Deadlines, market windows, seasonality |
"Is there a deadline we must hit? Why?" |
Interview Flow
Phase 1: Context Review
Before asking questions, AI reviews:
- CFD- evidence from v0.1-v0.2
- FEA- features and their priorities
- UJ- journeys and their complexity
- BR- business rules and constraints
Phase 2: Guided Questions
Ask questions from each category, adapting based on product context:
Market Risks:
- "What happens if [competitor] launches something similar in 60 days?"
- "What market assumption are you least confident about?"
- "What would cause users to choose a competitor instead?"
Technical Risks:
- "Which feature has the most technical uncertainty?"
- "What technology choice are you least confident about?"
- "Is there anything you've never built before?"
Adoption Risks:
- "What's the biggest friction point in [UJ-001 onboarding journey]?"
- "What behavior change are you asking users to make?"
- "What would cause a user to churn in the first week?"
Resource Risks:
- "If you had only 2 developers, what would you cut?"
- "What skill does the team lack?"
- "What's your runway for validation?"
Dependency Risks:
- "What external API or service could break your product?"
- "What partner relationship is critical?"
- "What regulatory requirement could block launch?"
Timing Risks:
- "Is there a hard deadline? What happens if you miss it?"
- "Is there a market window closing?"
- "What seasonal factor affects launch timing?"
Phase 3: Risk Documentation
For each identified risk, create RISK- entry with user input on severity and response.
Phase 4: Priority & Review
- Force-rank risks by Impact × Likelihood
- Identify top 3-5 that require active mitigation
- Document "accept" decisions explicitly
Interview Techniques
| Technique |
How to Use |
When to Use |
| Pre-mortem |
"It's 6 months from now and the product failed. Why?" |
Opening question |
| Constraint forcing |
"If you only had [X], what would you cut?" |
Resource discovery |
| Dependency mapping |
"What external factor could block launch?" |
Dependency discovery |
| Assumption surfacing |
"What must be true for this to work?" |
Any category |
| Devil's advocate |
"Let me argue the opposite—what if [X]?" |
Challenge weak evidence |
RISK- Output Template
RISK-XXX: [Risk Title]
Category: [Market | Technical | Adoption | Resource | Dependency | Timing]
Description: [What could go wrong]
Trigger: [What would cause this to happen]
Impact: [High | Medium | Low] — User assessed
Likelihood: [High | Medium | Low] — User assessed
Priority: [Impact × Likelihood ranking]
Early Signal: [How we'd know this is happening]
Response: [Mitigate | Accept | Avoid | Transfer]
Mitigation: [Specific action if Response = Mitigate]
Owner: [Who is responsible for monitoring]
Linked IDs: [FEA-XXX, UJ-XXX, BR-XXX affected]
Review Date: [When to reassess this risk]
Example RISK- entry:
RISK-001: Primary API Dependency (Stripe) Outage
Category: Dependency
Description: Stripe API outage would block all payment processing
Trigger: Stripe infrastructure failure or rate limiting
Impact: High — All revenue blocked during outage
Likelihood: Low — Stripe has 99.99% uptime SLA
Priority: 3 (High × Low)
Early Signal: Stripe status page, payment failure rate spike
Response: Mitigate
Mitigation:
- Implement graceful degradation (queue payments for retry)
- Add status page monitoring alert
- Document manual billing fallback process
Owner: Tech Lead
Linked IDs: FEA-020 (payments), UJ-005 (checkout), BR-030 (pricing)
Review Date: Before launch, quarterly thereafter
Risk Response Types
| Response |
When to Use |
Example |
| Mitigate |
Can reduce impact or likelihood |
Add fallback provider, implement retry logic |
| Accept |
Low impact or unavoidable |
"Competitor might copy us—we accept" |
| Avoid |
Change plan to eliminate risk |
Remove feature with high technical uncertainty |
| Transfer |
Someone else owns the risk |
Use managed service instead of self-hosting |
Severity Matrix
|
Low Impact |
Medium Impact |
High Impact |
| High Likelihood |
Monitor |
Mitigate |
Mitigate urgently |
| Medium Likelihood |
Accept |
Monitor/Mitigate |
Mitigate |
| Low Likelihood |
Accept |
Accept/Monitor |
Monitor |
Anti-Patterns to Avoid
| Anti-Pattern |
Signal |
Fix |
| Risk theater |
50+ risks documented |
Focus on top 10 that matter |
| All high severity |
Everything is critical |
Force rank; max 3-5 "High" |
| No owner |
Risks without accountability |
Every RISK- needs an owner |
| Mitigation = "be careful" |
Vague responses |
Require specific, testable actions |
| Interview becomes lecture |
AI talks more than user |
Ask, listen, summarize |
| Killing ideas |
Every risk leads to "don't do it" |
Frame as "how to succeed despite" |
Quality Gates
Before proceeding to Technical Stack Selection:
Downstream Connections
RISK- entries feed into:
| Consumer |
What It Uses |
Example |
| v0.5 Technical Stack Selection |
RISK- constraints affect tech choices |
RISK-003 (latency) → choose edge hosting |
| v0.6 Architecture Design |
Risk mitigations become architecture requirements |
RISK-005 → add circuit breaker |
| v0.7 Build Execution |
Risk monitoring in EPIC |
Track RISK-001 early signals |
| KPI- Thresholds |
Kill criteria from risks |
"If RISK-002 triggers, evaluate pivot" |
Detailed References
- Interview question bank: See
references/question-bank.md
- RISK- entry template: See
assets/risk.md
- Example risk register: See
references/examples.md
1---2name: prd-v05-risk-discovery-interview3description: Surface risks through guided questioning, helping users consider pivots, constraints, and prioritization during PRD v0.5 Red Team Review. Triggers on requests to identify risks, stress-test the idea, perform red team review, or when user asks "what could go wrong?", "identify risks", "red team", "risk assessment", "challenge assumptions", "stress test the idea". Consumes all prior IDs (CFD-, BR-, FEA-, PER-, UJ-, SCR-) as interview context. Outputs RISK- entries with owner decisions and mitigations. Feeds v0.5 Technical Stack Selection.4---5
6# Risk Discovery Interview
7
8Position in workflow: v0.4 Screen Flow Definition → **v0.5 Risk Discovery Interview** → v0.5 Technical Stack Selection
9
10This is an **interactive interview skill**. The AI asks questions, the user reflects and decides. The goal is to surface risks so the user can mitigate or accept them—not to kill ideas.
11
12## Design Principles
13
141. **Interview, not inquisition** — Facilitate discovery, don't interrogate
152. **Inform, not kill** — Surface risks so user can mitigate, not abandon
163. **User owns decisions** — AI facilitates, user assigns severity and response
174. **Actionable outputs** — Every risk has a mitigation path or explicit "accept"
18
19## Risk Categories
20
21| Category | Focus Area | Example Questions |
22|----------|------------|-------------------|
23| **Market** | Competitors, timing, demand | "What if [competitor] launches this feature next month?" |
24| **Technical** | Complexity, unknowns, dependencies | "Which feature has the most technical uncertainty?" |
25| **Adoption** | User behavior, activation, retention | "What's the biggest friction point in onboarding?" |
26| **Resource** | Team, budget, time | "If you had to cut scope by 50%, what stays?" |
27| **Dependency** | External factors, integrations, partners | "What external factor could block launch?" |
28| **Timing** | Deadlines, market windows, seasonality | "Is there a deadline we must hit? Why?" |
29
30## Interview Flow
31
32### Phase 1: Context Review
33Before asking questions, AI reviews:
34- CFD- evidence from v0.1-v0.2
35- FEA- features and their priorities
36- UJ- journeys and their complexity
37- BR- business rules and constraints
38
39### Phase 2: Guided Questions
40Ask questions from each category, adapting based on product context:
41
42**Market Risks:**
43- "What happens if [competitor] launches something similar in 60 days?"
44- "What market assumption are you least confident about?"
45- "What would cause users to choose a competitor instead?"
46
47**Technical Risks:**
48- "Which feature has the most technical uncertainty?"
49- "What technology choice are you least confident about?"
50- "Is there anything you've never built before?"
51
52**Adoption Risks:**
53- "What's the biggest friction point in [UJ-001 onboarding journey]?"
54- "What behavior change are you asking users to make?"
55- "What would cause a user to churn in the first week?"
56
57**Resource Risks:**
58- "If you had only 2 developers, what would you cut?"
59- "What skill does the team lack?"
60- "What's your runway for validation?"
61
62**Dependency Risks:**
63- "What external API or service could break your product?"
64- "What partner relationship is critical?"
65- "What regulatory requirement could block launch?"
66
67**Timing Risks:**
68- "Is there a hard deadline? What happens if you miss it?"
69- "Is there a market window closing?"
70- "What seasonal factor affects launch timing?"
71
72### Phase 3: Risk Documentation
73For each identified risk, create RISK- entry with user input on severity and response.
74
75### Phase 4: Priority & Review
76- Force-rank risks by Impact × Likelihood
77- Identify top 3-5 that require active mitigation
78- Document "accept" decisions explicitly
79
80## Interview Techniques
81
82| Technique | How to Use | When to Use |
83|-----------|------------|-------------|
84| **Pre-mortem** | "It's 6 months from now and the product failed. Why?" | Opening question |
85| **Constraint forcing** | "If you only had [X], what would you cut?" | Resource discovery |
86| **Dependency mapping** | "What external factor could block launch?" | Dependency discovery |
87| **Assumption surfacing** | "What must be true for this to work?" | Any category |
88| **Devil's advocate** | "Let me argue the opposite—what if [X]?" | Challenge weak evidence |
89
90## RISK- Output Template
91
92```
93RISK-XXX: [Risk Title]
94Category: [Market | Technical | Adoption | Resource | Dependency | Timing]
95Description: [What could go wrong]
96Trigger: [What would cause this to happen]
97Impact: [High | Medium | Low] — User assessed
98Likelihood: [High | Medium | Low] — User assessed
99Priority: [Impact × Likelihood ranking]
100
101Early Signal: [How we'd know this is happening]
102Response: [Mitigate | Accept | Avoid | Transfer]
103Mitigation: [Specific action if Response = Mitigate]
104Owner: [Who is responsible for monitoring]
105
106Linked IDs: [FEA-XXX, UJ-XXX, BR-XXX affected]
107Review Date: [When to reassess this risk]
108```
109
110**Example RISK- entry:**
111```
112RISK-001: Primary API Dependency (Stripe) Outage
113Category: Dependency
114Description: Stripe API outage would block all payment processing
115Trigger: Stripe infrastructure failure or rate limiting
116Impact: High — All revenue blocked during outage
117Likelihood: Low — Stripe has 99.99% uptime SLA
118Priority: 3 (High × Low)
119
120Early Signal: Stripe status page, payment failure rate spike
121Response: Mitigate
122Mitigation:
123 - Implement graceful degradation (queue payments for retry)
124 - Add status page monitoring alert
125 - Document manual billing fallback process
126Owner: Tech Lead
127
128Linked IDs: FEA-020 (payments), UJ-005 (checkout), BR-030 (pricing)
129Review Date: Before launch, quarterly thereafter
130```
131
132## Risk Response Types
133
134| Response | When to Use | Example |
135|----------|-------------|---------|
136| **Mitigate** | Can reduce impact or likelihood | Add fallback provider, implement retry logic |
137| **Accept** | Low impact or unavoidable | "Competitor might copy us—we accept" |
138| **Avoid** | Change plan to eliminate risk | Remove feature with high technical uncertainty |
139| **Transfer** | Someone else owns the risk | Use managed service instead of self-hosting |
140
141## Severity Matrix
142
143| | Low Impact | Medium Impact | High Impact |
144|---|---|---|---|
145| **High Likelihood** | Monitor | Mitigate | Mitigate urgently |
146| **Medium Likelihood** | Accept | Monitor/Mitigate | Mitigate |
147| **Low Likelihood** | Accept | Accept/Monitor | Monitor |
148
149## Anti-Patterns to Avoid
150
151| Anti-Pattern | Signal | Fix |
152|--------------|--------|-----|
153| **Risk theater** | 50+ risks documented | Focus on top 10 that matter |
154| **All high severity** | Everything is critical | Force rank; max 3-5 "High" |
155| **No owner** | Risks without accountability | Every RISK- needs an owner |
156| **Mitigation = "be careful"** | Vague responses | Require specific, testable actions |
157| **Interview becomes lecture** | AI talks more than user | Ask, listen, summarize |
158| **Killing ideas** | Every risk leads to "don't do it" | Frame as "how to succeed despite" |
159
160## Quality Gates
161
162Before proceeding to Technical Stack Selection:
163
164- [ ] All 6 risk categories explored
165- [ ] Maximum 10-15 RISK- entries (focused, not exhaustive)
166- [ ] Force-ranked by priority (Impact × Likelihood)
167- [ ] Top 5 risks have specific mitigation plans
168- [ ] "Accept" decisions are explicit, not accidental
169- [ ] Every RISK- has an owner
170
171## Downstream Connections
172
173RISK- entries feed into:
174
175| Consumer | What It Uses | Example |
176|----------|--------------|---------|
177| **v0.5 Technical Stack Selection** | RISK- constraints affect tech choices | RISK-003 (latency) → choose edge hosting |
178| **v0.6 Architecture Design** | Risk mitigations become architecture requirements | RISK-005 → add circuit breaker |
179| **v0.7 Build Execution** | Risk monitoring in EPIC | Track RISK-001 early signals |
180| **KPI- Thresholds** | Kill criteria from risks | "If RISK-002 triggers, evaluate pivot" |
181
182## Detailed References
183
184- **Interview question bank**: See `references/question-bank.md`
185- **RISK- entry template**: See `assets/risk.md`
186- **Example risk register**: See `references/examples.md`