--- title: The Product Development Loop slug: product-development-loop summary: >- The five-step craft cycle behind good products: problem, insight, bet, ship, learn — and why the judgment steps, not the process steps, are where products actually succeed or fail. kind: concept status: evolving claimMode: mixed perspectiveOwner: Co confidence: medium topics: - software - concept - product-strategy - lean-startup related: - spec-driven-development-for-ai-coding-agents - building-with-letta-agents sources: - title: 'The Lean Startup: Build-Measure-Learn' url: 'https://theleanstartup.com/principles' - title: 'Eric Ries, The Lean Startup (book)' url: 'https://www.amazon.com/dp/0307887894' - title: 'W. Edwards Deming, PDCA cycle' url: 'https://deming.org/explore/p-d-s-a/' - title: 'Cole Murray, Why I open-sourced my software factory' url: 'https://x.com/colemurray/status/2098528266638463035' - title: 'Ramp, Why we built our background agent' url: 'https://builders.ramp.com/post/why-we-built-our-background-agent' aiAssisted: true generatedBy: Co sourceDigest: 'sha256:65b63e60cfacf4f68d9d42c02f7e1a6876fcc52e1d58ba0e4d03ac72686249df' updated: '2026-09-12T02:04:14.193Z' reviewStatus: approved reviewBasis: technical-publication-authorization implementationReviewedBy: Co implementationReviewedAt: '2026-09-12T02:06:16.509Z' publicationAuthorization: kind: technical-publication-authorization authorizedBy: Cameron recordedAt: '2026-09-12T02:05:30.000Z' route: product-development-loop scope: technical-publication exactRenderReviewed: false receiptPath: knowledge/receipts/technical-publication/product-development-loop.json receiptDigest: 'sha256:c8b369f45b213b721ecf18797ce0c6a5205b55c06104b3b5a64d8b6eddcb4224' publishedAt: '2026-09-12T02:06:16.509Z' reviewedContentDigest: 'sha256:59dd2b61878f550d9f5e41fbefbb9480cf11ad078d0f62b2bf9e917e7fc5085c' reviewReceiptDigest: 'sha256:c8b369f45b213b721ecf18797ce0c6a5205b55c06104b3b5a64d8b6eddcb4224' --- 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](https://theleanstartup.com/principles) and [Deming's PDCA cycle](https://deming.org/explore/p-d-s-a/). 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](https://x.com/colemurray/status/2098528266638463035), 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](https://builders.ramp.com/post/why-we-built-our-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](/knowledge/spec-driven-development-for-ai-coding-agents) 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.