The product development loop is a five-step cycle for building good products: Problem, Insight, Bet, Ship, Learn. A real user struggle rather than a feature idea. A stated account of why current solutions fail. A small, testable change in behavior or outcome. A thin slice in users' hands. An honest verdict on whether the bet landed, followed by amplifying, pivoting, or killing.
The formulation compresses the hypothesis-driven development tradition into steps that name the judgment each stage demands rather than the ceremony around it. Its lineage runs through Lean Startup's Build-Measure-Learn and Deming's PDCA cycle. Its closing claim is the part worth remembering: roadmaps, PRDs, and org charts are not the craft. They are ways to run the loop without chaos — coordination devices for a human process, not the value itself.
Where the loop actually fails
The five steps look equally executable in list form. They are not.
Steps one and two are where products die, and they are judgment rather than process. Problem selection — choosing which real user struggle matters — and the insight step — explaining why everything currently on the market, including the obvious baseline, fails that struggle — cannot be proceduralized the way shipping can. A team can run steps three through five competently and still build the wrong thing, because the scarce resource upstream is taste and judgment about what matters, not execution.
Step five's kill verdict is the step organizations structurally struggle to execute. Sunk cost, escalation of commitment, and incentive design all push toward pivoting without end or amplifying without evidence. Most companies adopt loop language specifically to avoid the honest kill: the vocabulary of validated learning arrives, the verdict never does. A loop that cannot say "this bet did not land, stop" is not running step five; it is running steps one through four on repeat.
The distinctive emphasis of the five-step version is Insight as an explicit step. Before any bet is made, the team must state why current solutions fail — including the laziest current solution. In AI products in the 2020s, that baseline is often "just chat with an LLM." A product whose insight cannot explain why plain model access fails the user's struggle has not earned its bet.
The artifacts are coordination, not value
The claim that roadmaps, PRDs, and org charts are "ways to run the loop without chaos" repeats a structural pattern that appears elsewhere in modern software practice. In the software-factory discussion of the mid-2020s, the same argument runs from the infrastructure direction: control planes, sandboxes, and agent harnesses are commodity coordination devices, while the organization's actual routing decisions, knowledge distribution, and learning from its own session history are the compounding assets. Ramp's account of its background agent makes the same move — the sandbox and tooling are what an engineer would have locally; the value is the surrounding process.
The pattern generalizes: whenever the artifacts of coordination become cheap to copy, the value concentrates in the human process those artifacts coordinate. Documentation, specifications, and org design are real work — but they are the loop's support structure, not its engine.
Relation to specification-driven work
The loop is the strategic cycle; spec-driven development is one way to run its middle steps with delegated labor. A specification records the bet's intended behavior and its verification map so that a thin slice can be shipped and learned from without the intent dissolving on the way to production. The loop supplies the verdict discipline; the specification supplies the durable state that survives the handoff.