Managing the Development of Large Software Systems
Source: https://www.praxisframework.org/files/royce1970.pdf ↗
The paper usually cited as the birth of waterfall, and almost always misread.
Royce diagrams the linear sequence — requirements, design, code, test, deploy — and immediately writes that this approach is "risky and invites failure." The rest of the paper argues for iteration, feedback, and doing each step twice.
It is one of the most consequential misreadings in the history of software: the industry built careers on a straw man of a paper that was warning against the straw man.
Worth reading in the original to understand how ideas travel, and how often they arrive at their destination inverted.
Central argument
Royce argues that developing large software systems through a simple linear sequence — requirements through deployment — is inherently risky and likely to fail. His actual prescription is iterative: each major phase should be done twice, with structured feedback loops that allow upstream design decisions to be revised when downstream phases expose their flaws. The paper's central finding is that the gap between how software development is planned and how it actually behaves in practice must be closed through deliberate process design, not optimism.
Critique
Royce's proposed solution — a more disciplined, documented, plan-driven iteration — still assumes that requirements can be substantially known and stabilized before large-scale construction begins, which later empirical work (including the studies underpinning agile methods) would challenge. His framework remains a response to the problems of large defense-contract software, where contractual and organizational pressures impose a structure that most product environments don't share; the iteration he advocates is corrective rather than exploratory, and has little room for learning from users once development is underway.
Why it matters for product
The paper's real lesson for a CPO is about how process abstractions get detached from their original intent and then institutionalized — the waterfall that became dogma was a diagram Royce explicitly warned against, which should make any product leader suspicious of inherited delivery frameworks their organization treats as settled truth. More concretely, the tension Royce identifies between the need for early architectural commitment and the reality that critical information only surfaces late in development is precisely the tension that shapes decisions about when to harden a roadmap, how much discovery to front-load, and how to structure handoffs between product, design, and engineering without locking in decisions prematurely.