Risk Management

Every product idea carries risk. Customers may not want it, users may struggle with it, engineers may fail to build it, or the business may fail to profit from it. Product managers name these risks early, test the biggest ones first, and keep surprises small.

Think of a sailor who checks weather, equipment, and route before leaving harbor. The sailor cannot remove every danger. Careful preparation turns unknown dangers into planned responses. Risk management gives product teams the same advantage.

The Four Product Risks

┌─────────────────┬──────────────────────────────────────┐
│ VALUE RISK      │ Will customers want this?            │
├─────────────────┼──────────────────────────────────────┤
│ USABILITY RISK  │ Can customers figure it out?         │
├─────────────────┼──────────────────────────────────────┤
│ FEASIBILITY RISK│ Can we build it with our skills,     │
│                 │ time, and technology?                │
├─────────────────┼──────────────────────────────────────┤
│ VIABILITY RISK  │ Will it work for the business:       │
│                 │ costs, laws, partners, brand?        │
└─────────────────┴──────────────────────────────────────┘

Who Helps Check Each Risk

• Value: product manager, through customer interviews and tests
• Usability: designer, through prototypes and usability sessions
• Feasibility: engineers, through technical exploration
• Viability: legal, finance, marketing, and security colleagues

Involve all four voices at the start. Late discoveries cost the most.

Build a Risk Register

A risk register lists each risk with its chance, its damage, and a plan.

RISK                      CHANCE   IMPACT   PLAN
──────────────────────────────────────────────────────────────────
Users skip the setup      High     High     Test shorter setup flow
Payment partner delays    Medium   High     Prepare backup partner
New privacy rule applies  Low      High     Ask legal to review early
Key engineer leaves       Low      Medium   Document and share work

The Risk Matrix

A matrix helps you decide where to spend attention. Place each risk by chance and impact.

IMPACT
 High   │  Watch       │  ACT NOW
        │              │  (Setup skipped,
        │              │   payment delays)
 ───────┼──────────────┼───────────────────
 Low    │  Ignore      │  Monitor
        │              │
        └──────────────┴───────────────────
              Low           High      CHANCE

Five Ways to Respond

Avoid

Drop the risky part of the plan. A team skips a complicated feature that few customers need.

Reduce

Shrink the chance or the damage. Staged rollouts expose a bug to five percent of users first.

Transfer

Shift the risk to someone better prepared, such as a trusted payment provider.

Accept

Live with a small risk and keep a note. Not every risk deserves action.

Prepare

Write a response plan in advance, so the team acts calmly if the risk appears.

Run a Pre-Mortem

A pre-mortem imagines failure before it happens. Gather the team and say: "Six months from now, the launch failed. What went wrong?" People write reasons on sticky notes, group them, and rank them. Imagining failure frees teammates to voice worries that politeness might hide.

Imagine the failure
      ↓
Everyone writes reasons silently
      ↓
Group similar reasons
      ↓
Rank by chance and impact
      ↓
Add the top items to the risk register with plans

Test Risks Cheaply

Choose the riskiest assumption and design a small test. Customer interviews test value risk. Prototypes check usability risk. Engineers run a two-day technical spike to explore feasibility risk. Cheap tests replace guesses with evidence.

Keep Watching

Risks change as the product grows. Review the register at the start of each sprint or monthly. Close resolved risks, add new ones, and update plans.

Common Mistakes

• Listing risks and never acting on them
• Focusing only on technical risks
• Hiding bad news from stakeholders
• Testing the easy risks and ignoring the biggest one

A Worked Example

A food delivery team plans scheduled deliveries, where customers pick a weekly time slot. The team lists four risks. Will customers want fixed slots? Slot selection must feel easy. Drivers need to keep to a strict schedule, and late deliveries could raise costs beyond the planned margin.

Value risk ranks highest, so the team interviews fifteen customers and tests a simple sign-up page. Eleven customers show strong interest. A prototype test reveals that the slot picker confuses people, and the designer simplifies it. Engineers review driver routes and find that evening slots overload the schedule. The team limits evening slots in the first release. Each early test removed a costly surprise before launch.

Key Takeaways

Product risk covers value, usability, feasibility, and viability. Record risks, rank them by chance and impact, and test the biggest first. Use pre-mortems to surface worries, and review the register regularly.