Risk

Origin & evolution

Formalised risk management grew out of large engineering and defence programmes in the mid-twentieth century, where the cost of surprise was measured in years and budgets. The Project Management Institute codified the modern toolkit in its PMBOK Guide, which defines risk as an uncertain event with a cause and an effect, scored by probability and impact, and tracked in a risk register: a living log of each risk, its likelihood, its impact, its owner, and the planned response. The probability-and-impact matrix that ranks risks high, medium, or low comes straight from this tradition.

Product practice reframed the idea for software, where the dominant risks are not schedule slips but building the wrong thing. Marty Cagan's four big product risks name the categories that actually kill products. Value risk asks whether anyone will choose to use or buy it. Usability risk asks whether they can work out how. Feasibility risk asks whether engineering can build it with the time, skills, and technology on hand. Viability risk asks whether it works for the wider business: legal, finance, sales, brand. Cagan's argument, refined since the first edition of Inspired, is that discovery exists to retire all four before a team commits to delivery, and that viability is the one product managers most often underestimate.

The two traditions sit at different altitudes. The risk register🧯Risk RegisterProgram ManagementA register of project risksView reference → manages execution risk across a project; the four big risks structure discovery risk for a product. The field has converged on a shared move: name the risk explicitly, attach an owner, and decide the response (avoid, mitigate, transfer, or accept). A named and owned risk stops being ambient anxiety and becomes a managed item.

How it works in practice

A health-tech team is shipping a feature⭐FeatureProduct SpecificationA product capability or featureView reference → that infers a patient's medication schedule from free-text notes. They log three risks. A model misread that produces a wrong schedule scores low likelihood but severe impact, so it tops the register; the response is a mandatory human confirmation step before anything is saved. A regulatory risk around storing inferred clinical data scores medium and medium; the owner is the compliance lead, with a deadline two sprints out. A third risk, slow inference latency, scores high likelihood but low impact, so they accept it and add a loading state. The point of the register is what it lets them ignore: latency feels urgent in standups, but it is the cheapest of the three to live with.

Risk vs. its neighbours

• Assumption🤔AssumptionStrategyA belief taken as true that underpins a strategyView reference → is a belief held without proof; it sits quietly until challenged. A risk is an articulated threat with a probability attached. An unexamined assumption that turns out false is one of the most common ways a risk materialises, which is why discovery converts key assumptions into testable risks.
• Constraint🔒ConstraintStrategyA constraint entityView reference → is a boundary already in force today, such as a fixed budget. A risk is a future possibility that may never arrive. Treating a constraint as a risk wastes mitigation effort on something that is certain, not probable.
• Dependency⛓️DependencyTeam & OrganisationA cross-team or system dependencyView reference → is a concrete reliance on another team or system delivering on time. A risk is the broader uncertainty around whether that, or anything else, goes wrong. A slipping dependency is a frequent source of risk, but the dependency is the relationship and the risk is the exposure it creates.

In the graph

In the Unified Product Graph, a risk sits in the compliance region as a node that exposure and governance both connect to. A product carries its live threats through product_exposed_to_riskProductexposed toRiskhierarchy, and risk_register_contains_riskRisk RegistercontainsRiskhierarchy gives the PMBOK register a structural home where every entry is queryable, with none of it buried in a spreadsheet tab. Governance links inward through compliance_framework_identifies_riskCompliance FrameworkidentifiesRiskhierarchy, so the controls a framework demands trace to the specific risks they answer. The consequence side is modelled too: risk_manifests_as_technical_debt_itemRiskmanifests asTechnical Debt Itemcross-domain captures the moment an accepted risk becomes real debt, turning the register from a list of fears into a record of what the product has actually taken on.