Risk Assessment Matrix

Purpose

Systematically identify, rate, and prioritise risks that could prevent a prototype from succeeding in A4–A7 production, using a probability × impact matrix that forces explicit assessment of both how likely a risk is and how damaging it would be—replacing vague “it's risky” statements with structured, actionable risk profiles.

In A3.4, the risk assessment matrix serves as the bridge between evidence (what A3 data shows) and decision (what A3.5 should do about uncertainty). Every prototype carries risks; the question is not “Is there risk?” but “Which risks are acceptable, which need mitigation, and which are deal-breakers?”

When to Use

Use risk assessment matrix when:

• Conducting A3.4 evaluation (mandatory—risk profile feeds all three lenses and A3.5 decision)
• Preparing A4 charter (risk register becomes project risk management baseline)
• A3.5 governance forum needs structured risk discussion (not anecdotal “what-ifs”)
• Comparing multiple prototypes (risk profile is a differentiator)

Do NOT use when:

• Risk identification becomes risk avoidance—the goal is not zero risk but acceptable risk with mitigation
• Analysis paralysis—50 identified risks with no prioritisation is worse than 10 prioritised risks with mitigation plans

Sample Size and Duration

Effort: 8–14 hours per prototype

Team: 4–6 people (cross-functional)

Workshop: 2–3 hours for identification and rating; 2–4 hours for mitigation planning

Duration: 1–2 days within A3.4 timebox

Prerequisites

• A3 evidence: Complete data from A3.1 (build risks realised), A3.2 (validation risks), A3.3 (operational risks observed during pilot)
• Cross-functional input: Engineering (technical risks), Finance (financial risks), Product (market risks), Operations (operational risks), Legal (regulatory risks)
• Risk taxonomy: Agreed categories to ensure comprehensive coverage
• Scoring criteria: Probability and impact scales agreed before assessment begins

Complete Procedure

Step~1: Identify Risks by Category (2–4 hours)

Use a structured taxonomy to ensure comprehensive coverage. For each category, ask: “What could prevent this prototype from succeeding at production scale?”

Step~2: Rate Each Risk (1–2 hours)

For each identified risk, assess:

1. Probability: Low / Medium / High (use A3 evidence where available—e.g. if A3.3 showed scaling problems, probability of technical risk is High, not Low)
2. Impact: Low / Medium / High / Critical
3. Rating: From the matrix (Table~)

Step~3: Build Risk Register (2–3 hours)

Example (C001 Smart Checkout):

Step~4: Define Risk Responses (1–2 hours per critical/high risk)

Four response strategies:

• Avoid: Eliminate the risk entirely (change approach, drop feature). Use for critical risks with high probability.
• Mitigate: Reduce probability or impact (add redundancy, build fallback, invest in prevention). Most common response.
• Transfer: Shift risk to third party (insurance, outsourcing, SLA guarantees). Use for financial and operational risks.
• Accept: Acknowledge and monitor. Use for low-rated risks where mitigation cost exceeds expected loss.

Step~5: Assign Owners and Triggers (1 hour)

Each risk above “Low” rating gets:

• Owner: Named person responsible for monitoring (not “the team”)
• Trigger: Observable signal that the risk is materialising (e.g. “Week~4 retention <50%” triggers R2 response)
• Response plan: Pre-committed action if trigger fires

Step~6: Aggregate for A3.4 Report (1–2 hours)

Summarise risk profile:

• Total risks identified: [count]
• Critical: [count]; High: [count]; Medium: [count]; Low: [count]
• Top 3 risks with mitigation plans
• Residual risk assessment: “After mitigation, overall risk profile is [acceptable / elevated / concerning]”
• Unmitigatable risks (if any)—these become A3.5 decision factors

Quality Criteria

1. Comprehensive: All six taxonomy categories assessed
2. Evidence-based ratings: Probability and impact informed by A3 data (not gut feeling)
3. Cross-functional: Engineering, product, finance, operations, legal input represented
4. Actionable: Every High/Critical risk has a mitigation plan, owner, and trigger
5. Prioritised: Risks ranked; top 3–5 highlighted for A3.5 attention
6. Honest: Includes risks the team hopes won't happen (pre-mortem applied)

Theoretical Foundation

Seminal references:

• : The standard practitioner guide to risk management. Established the probability × impact framework and the distinction between risk identification (what could happen), risk analysis (how likely and how bad), and risk response (what to do about it). Key principle: risks must be owned—every risk has a named person responsible for monitoring and response.
• : Demonstrated systematic biases in risk perception: people overweight vivid, recent risks and underweight abstract, statistical ones. Structured risk assessment counteracts these biases by forcing consistent evaluation across all risk types.

Contemporary references:

• : Applied risk thinking to innovation: the riskiest assumptions should be tested first. By A3.4, many risks have been tested (desirability validated in A3.2, retention validated in A3.3)—the risk matrix now focuses on remaining risks that A4–A7 must manage.

The Probability $$ Impact Matrix

Probability scale:

• Low (<20%): Unlikely but possible
• Medium (20–60%): Plausible; has occurred in similar contexts
• High (>60%): More likely than not; evidence suggests it will happen

Impact scale:

• Low: Minor delay or cost increase (<10% budget); no user impact
• Medium: Significant delay (1–2 months) or cost increase (10–25%); degraded user experience
• High: Major delay (>2 months) or cost overrun (>25%); loss of users or revenue
• Critical: Project failure, market exit, or reputational damage

Challenges and Solutions

Challenge 1: Risk Theater

Symptoms: 50 risks identified, all rated “Medium,” no mitigation plans. Risk register exists for compliance, not decision-making.

Solutions: Limit to 10–15 risks maximum (force prioritisation). Require mitigation plans for every High and Critical risk. If no one will own a risk, it isn't real—remove it. Review register in governance forum (the referenced method) —the register must survive scrutiny.

Challenge 2: Anchoring on A3 Evidence

Symptoms: Team rates all risks “Low” because “the pilot went well.” Pilot success production success. Scale, competition, and time introduce new risks.

Solutions: Separate “tested risks” (validated in A3, lower probability) from “untested risks” (not yet encountered, assess independently). Use pre-mortem technique: “Imagine it is 18 months from now and C001 has failed. What went wrong?”

Challenge 3: Missing Risk Categories

Symptoms: Technical team identifies only technical risks. Market, regulatory, and strategic risks unaddressed.

Solutions: Use the taxonomy (Table~) as a checklist. Cross-functional workshop: each function identifies risks in their domain. If a category has zero risks, explicitly state “No material [category] risks identified”—absence should be deliberate, not accidental.

Relationship to Other Methods

Risk Assessment Matrix receives input from:

• Three-Lens Evaluation (the referenced method): Each lens identifies risks in its domain
• ROI Modelling (the referenced method): Financial risks (worst-case NPV, CAC overrun) flow into risk register
• Customer Success Management (the referenced method): Support scalability risk informed by pilot data
• A3.1–A3.3 evidence: Realised risks (bugs, scaling issues, churn) inform probability ratings

Risk Assessment Matrix provides input to:

• Sensitivity Analysis (the referenced method): High-rated risks identify variables to stress-test
• Governance Forum (the referenced method): Risk profile is key deliberation input; unmitigatable risks may drive kill decisions
• A4 Charter: Risk register with mitigations becomes A4 risk management baseline
• SWOT Analysis (the referenced method): Risks map to Weaknesses (internal) and Threats (external)

Tools and Templates

• Risk register: Excel/Google Sheets (standard risk register template), Jira (risk tracking as issues), Notion (risk database)
• Facilitation: Miro, FigJam (collaborative risk identification workshop)
• Risk matrix visualisation: Excel conditional formatting, dedicated risk tools (Risk Register Pro, Resolver)
• Pre-mortem facilitation: Structured workshop guide (Gary Klein's pre-mortem protocol)

• D. Hillson (2009). Managing Risk in Projects. Gower.
• D. J. Bland & A. Osterwalder (2020). Testing Business Ideas. Wiley.
• D. Kahneman (2011). Thinking, Fast and Slow. Farrar, Straus and Giroux.
• R. G. Cooper (2017). Winning at New Products: Creating Value Through Innovation. 4 ed. Basic Books.