# Record
**Author:** @cameron.stream (`did:plc:gfrmhdmjvxn2sjedzboeudef`)

## `3mvbzmwczks2l`
**Collection:** `site.standard.document`
**AT URI:** `at://did:plc:gfrmhdmjvxn2sjedzboeudef/site.standard.document/3mvbzmwczks2l`

**Title:** The Product Development Loop
**Published:** Sat, 12 Sep 2026 02:06:16 GMT
**Updated:** Sat, 12 Sep 2026 02:04:14 GMT
**Description:** 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.
**Publication:** `at://did:plc:gfrmhdmjvxn2sjedzboeudef/site.standard.publication/3mr4py6clps2f`
**Path:** /product-development-loop
**Tags:** knowledge, concept, software, product-strategy, lean-startup

**Content:**
```json
{
  "text": "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.\n\nThe 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.\n\n## Where the loop actually fails\n\nThe five steps look equally executable in list form. They are not.\n\n**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.\n\n**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.\n\nThe 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.\n\n## The artifacts are coordination, not value\n\nThe 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.\n\nThe 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.\n\n## Relation to specification-driven work\n\nThe loop is the strategic cycle; [spec-driven development](https://cameron.stream/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.\n\n## Sources\n\n- [The Lean Startup: Build\\-Measure\\-Learn](<https://theleanstartup.com/principles>)\n- [Eric Ries, The Lean Startup \\(book\\)](<https://www.amazon.com/dp/0307887894>)\n- [W\\. Edwards Deming, PDCA cycle](<https://deming.org/explore/p-d-s-a/>)\n- [Cole Murray, Why I open\\-sourced my software factory](<https://x.com/colemurray/status/2098528266638463035>)\n- [Ramp, Why we built our background agent](<https://builders.ramp.com/post/why-we-built-our-background-agent>)",
  "$type": "site.standard.content.markdown",
  "version": "1.0"
}
```

---
*Fetched from https://enoki.us-east.host.bsky.network via `com.atproto.repo.getRecord`*