To the Bedrock
Products Over Projects

Risk Lens

Product and project are often treated as preferences about funding or delivery. Here the choice depends on which risk remains after available evidence and controls have been considered.

Product-mode is appropriate when the dominant residual risk is that the organisation may not yet understand the problem, the user behaviour, the solution, the value mechanism, or the intended business outcome. Project-mode is appropriate when the dominant residual risk is that known work may not be completed correctly, safely, on time, or across dependencies.

Canonical Distinction

A product is a persistent value system managed through learning. It can be customer-facing, an internal platform, a business capability, a service, a data product, or an operational process. What makes it product-like is the continuing need to improve an outcome under uncertainty, regardless of whether it has a user interface or commercial SKU.

A project is a temporary change effort managed through coordinated completion. It is rational when the objective and solution are sufficiently known, and the principal uncertainty concerns sequencing, dependency management, migration, compliance, correctness, cost, schedule, or transition into operation.

Product teams reduce discovery and adaptation risk. Project teams reduce coordination and completion risk. Where an initiative contains both, govern the parts according to their risks.

Risk Management Translation

ISO 31000 starts from the objective and the uncertainty affecting it. COSO ERM links that risk to strategy and performance, while PMI frames risk management as protecting portfolio, program, and project objectives from uncertain events or conditions. Together they make the product/project distinction more precise: the operating model should be selected as a risk treatment, not as an organisational identity.

Product-mode question

Are we solving the right problem in a way that improves the intended outcome?

Primary treatment: discovery, experimentation, instrumentation, iteration, and durable ownership.

Project-mode question

Can the known change be completed correctly, safely, predictably, and across dependencies?

Primary treatment: planning, controls, dependency management, validation, readiness, and closure.

Fixing scope while product uncertainty remains unresolved commits the organisation before it has credible evidence. Project governance can improve delivery discipline while leaving that investment risk untreated.

Residual Risk

The useful classification is residual rather than inherent. An initiative may begin with high value, usability, feasibility, and viability uncertainty. If those uncertainties have been tested with behavioural evidence, prototypes, technical spikes, constraint review, and credible business validation, the residual product risk may be low enough for project or program governance to dominate.

A deadline or approved business case leaves product uncertainty intact if adoption, value, workflow fit, or outcome movement remains untested. The organisation may deliberately accept that risk, but approval alone provides no assurance.

Risk Frameworks Invoked

The module does not replace established risk frameworks. It uses their language to classify work more carefully: objectives, uncertainty, likelihood, impact, control effectiveness, residual risk, risk appetite, treatment, monitoring, and acceptance.

ISO 31000: risk management principles, framework, and process IEC 31010: selection and application of risk assessment techniques COSO ERM: risk integrated with strategy and performance PMI risk management: portfolio, program, and project risk FMEA/FMECA: failure modes, effects, criticality, and detectability Bowtie analysis: preventive and recovery barriers around a top event NIST RMF: categorize, select, implement, assess, authorize, and monitor controls ISO/IEC 27005: information security risk assessment, treatment, acceptance, and monitoring HACCP and critical-control thinking: hazards, limits, monitoring, corrective action, verification ISO 14971: lifecycle risk management and benefit-risk reasoning for medical devices ICH Q9(R1): quality risk management, formality, subjectivity control, and knowledge-based decisions

Use It

Consider how the initiative could fail even with competent work. Untested adoption, value, usability, feasibility, viability, or outcome movement calls for product-mode learning. Risks to deadlines, migration, dependencies, correctness, compliance, or readiness may call for project or program controls.

Taxonomy Classify product uncertainty, execution risk, and hazard/control risk Residual Risk Assessment Score the dominant residual risk after evidence and controls

Selected References

Narayan, S. (2018). Products over projects. Martin Fowler. martinfowler.com/articles/products-over-projects.html

ISO. (2018). ISO 31000:2018 Risk management — Guidelines. iso.org/standard/65694.html

COSO. (2017). Enterprise Risk Management — Integrating with Strategy and Performance. coso.org/enterprise-risk-management

Project Management Institute. (2024). Risk Management in Portfolios, Programs, and Projects: A Practice Guide. pmi.org/standards/risk-management

IEC. (2019). IEC 31010:2019 Risk management — Risk assessment techniques. iso.org/standard/72140.html

NIST. (2024). Risk Management Framework. csrc.nist.gov/projects/risk-management/about-rmf

ISO. (2019). ISO 14971:2019 Medical devices — Application of risk management to medical devices. iso.org/standard/72704.html

European Medicines Agency. (2023). ICH Q9(R1) Quality risk management. ema.europa.eu