Three Risk Families
Product uncertainty
Product uncertainty is present when the organisation may still be wrong about the problem, the solution, the behaviour it expects to change, or the value mechanism it expects to activate. It is reduced through evidence that tests assumptions before irreversible commitment.
Execution risk
Execution risk is present when the change is substantially known but completion may fail because of time, dependencies, sequencing, quality, migration, resource conflict, or transition into operation.
Hazard and control risk
Hazard and control risk is present when failure may cause harm, breach a formal obligation, create unacceptable exposure, or require explicit residual-risk acceptance. It does not replace product or project logic; it constrains both.
Framework Mapping
The frameworks below are not interchangeable. They are included because each makes a different part of the product/project distinction visible to a traditional governance audience.
| Framework | Familiar Risk Logic | Contribution to the Product/Project Boundary |
|---|---|---|
| ISO 31000 | Objectives, uncertainty, risk treatment, communication, monitoring, and review. | Start from the objective and classify the uncertainty that threatens it. |
| IEC 31010 | Selection and application of risk assessment techniques under uncertainty. | Choose assessment methods that fit the uncertainty: assumption tests, FMEA, scenario analysis, bowtie, or quantitative models. |
| COSO ERM | Risk integrated with strategy-setting and performance. | Product-mode is a treatment for uncertainty in strategic and performance outcomes. |
| PMI risk management | Risk to portfolio, program, and project objectives; threats and opportunities. | Project controls are appropriate when project objectives are the right objectives. |
| FMEA/FMECA | Failure modes, effects, severity, occurrence, detection, and criticality. | Classify the work by the most consequential failure modes rather than by label. |
| Bowtie analysis | Threats, preventive barriers, top event, consequences, and recovery barriers. | Treat discovery as a preventive barrier against building the wrong thing. |
| NIST RMF | Categorize, select, implement, assess, authorize, and monitor controls. | Empowered teams still operate inside explicit control baselines and monitoring duties. |
| ISO/IEC 27005 | Information security risk identification, assessment, treatment, acceptance, communication, and monitoring. | Digital product work may require explicit security and privacy risk treatment even when discovery risk dominates. |
| HACCP / critical controls | Hazard analysis, critical control points, limits, monitoring, corrective action, verification. | Some risks require critical controls before learning in live operation is acceptable. |
| ISO 14971 | Lifecycle hazard identification, risk estimation, risk control, benefit-risk reasoning, monitoring. | Durable ownership and formal evidence can coexist in high-consequence product work. |
| ICH Q9(R1) | Quality risk management, formality, subjectivity control, knowledge-based decisions, review. | Risk work should be as formal as the context warrants, and should use knowledge to reduce subjectivity. |
Governance Patterns
| Residual Risk Profile | Recommended Governance | Typical Evidence |
|---|---|---|
| High product uncertainty, low execution complexity | Durable product team with discovery cadence and outcome metrics. | Behavioural evidence, prototypes, customer or user research, instrumented releases. |
| High product uncertainty, high execution complexity | Product team plus program management; separate assumption learning from delivery coordination. | Assumption map, staged investment, dependency map, release readiness, go/no-go criteria. |
| Low product uncertainty, high execution complexity | Project or program governance with strong controls, risk register, and dependency management. | Scope baseline, integrated plan, test evidence, audit traceability, transition plan. |
| High hazard/control exposure | Formal risk/control framework plus durable ownership and lifecycle monitoring. | Hazard analysis, control design, verification records, residual-risk acceptance, post-release monitoring. |
| Low product uncertainty, low execution complexity | Lightweight task or project execution; avoid governance overhead disproportionate to risk. | Clear acceptance condition, owner, due date, and basic quality checks. |
Language for Cross-Functional Review
Instead of saying that an initiative should be a product rather than a project, say that value or adoption risk remains dominant and that fixed-scope governance would create false assurance. Instead of saying that discovery is needed, say that discovery is the proposed treatment for assumptions that would make the investment fail if they are wrong.
This language preserves respect for project management while placing it in the correct domain. Project governance is highly rational when the work is known and the dominant risk is coordination, migration, compliance, correctness, or operational readiness. It becomes weak assurance when it is asked to resolve uncertainty about value, usability, feasibility, viability, or outcome.