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.

Taleb's work on extreme events adds a standing caveat to that matrix: it is calibrated for risks whose probability can be estimated from prior data, and it systematically underweights events that are genuinely novel — low probability not because they are inherently rare but because no comparable event exists in the historical record to anchor the estimate. By that reading, a risk register🧯Risk RegisterProgram ManagementA register of project risksView reference → that ranks only known threats☠️ThreatSecurityA specific security threatView reference → is complete for execution risk and incomplete for the tail of possibilities that would actually end the product.

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 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.

Duke's argument in Thinking in Bets is relevant to what that probability number means in practice: assigning a likelihood is not a prediction but a bet, and a team that confuses a good risk decision⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference → with a good outcome🏆OutcomeStrategyA desired business or user outcomeView reference → will systematically learn the wrong lessons. A risk that was accepted at low probability and then materialised was not necessarily misjudged; the register should record the reasoning at the time, not be rewritten in hindsight.

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 limit, requirement, or ceiling the product must respect, whether a self-imposed principle or an externally imposed boundaryView 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📸CaptureWorkspaceA dated, hashed rendition of something already in the graph: a screenshot of a surface, a PDF of a report, an export of a canvas. The subject stays a graph node; the capture records what it looked like at one moment, and the content hash says whether it still does.View reference → 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. Two edges added at 0.35.0 close the exposure loop. risk_threatens_nodeRiskthreatensany entitycross-domain names what the risk puts at stake, and risk_mitigated_by_nodeRiskmitigated byany entitycross-domain names the decisions, features and experiments🧫ExperimentValidationA test designed to validate a hypothesisView reference → that answer it. Both keep a typed risk on the source side and leave the target open, registered together as the polymorphic "risk exposure" family, because what a risk threatens and what retires it are genuinely unbounded sets; enumerating either would be writing down today's corpus and calling it the vocabulary. Ownership rides the existing node_owned_by_stakeholderany entityowned byStakeholdercross-domain, so a risk with a named owner is a query rather than a convention. The properties moved in the same release🚢ReleaseProduct SpecificationA shipped version of the productView reference →: the likelihood field is now likelihood, reading the new likelihood_5 ladder rather than the epistemic confidence_5, which says how sure the assessor is and not how likely the event is; and impact resolves to severity_5 on a risk through the per-entity scale layer, because impact means magnitude of benefit elsewhere in the graph and severity of harm here.