Loop Engineering for Product Managers: Beyond Prompting

Key takeaways

1. Central thesis. the next PM skill is not prompt engineering but Loop Engineering — "designing a system that improves every time it runs," not writing the perfect prompt every time.
2. Definition of a loop. a repeated cycle — change what shapes the agent → run it → evaluate → keep if quality rises / revert otherwise → commit the learning so the next version starts ahead.
3. The PM's entry point = artifacts. (not code): PRD-review skill, customer-call summarizer, evaluation rubric, launch checklist, research workflow, CLAUDE.md, prompt template, prioritization framework. They are durable, reused, and encode judgment; they shape the agent across dozens of runs.
4. Bidirectional compounding. a good artifact sharpens the work every week; a bad one slows it down, silently. "A one-off prompt you can afford to get wrong. A rubric ten people depend on, you cannot."
5. The problem prompting doesn't solve — DRIFT. the CLAUDE.md keeps growing, the review skill hardens, the checklist swells until it's half-ignored, eval criteria change without anyone knowing when/why. A month later the agent "seems worse": "the model probably did not get worse. Your artifacts drifted, and nothing was watching them."
6. Anatomy of a loop — 5 parts. (1) trigger (when it starts), (2) action (what the agent does), (3) proof (how you know it's better), (4) memory (where the learning is saved), (5) stop condition (when it stops).
7. The stop condition is the most critical. (especially for recursive loops): many systems fail not because the model is bad, but because the loop has no clean exit (scope creep, invented work, a confident summary with no proof). A good PM loop must be able to say: nothing changed / the input is too thin / it's blocked / the quality bar isn't met / it requires a human decision. "A loop that can say stop is a loop you can leave running."
8. Evals become PM work. not a giant benchmark — start from known examples. E.g. 3 strong / 3 weak PRDs → does the artifact catch the real gaps without nitpicking, while preserving intent?; 5 already-understood calls → does it capture the real pain, quote accurately, distinguish strong signal from noise?; 2 past launches (1 clean, 1 failed) → would it have caught what broke? Question: "did this artifact improve against known product judgment?" (not "does the agent look smart?").
9. Memory layer = GitHub. not to turn PMs into engineers, but for the version history of artifacts. It holds the artifact, the changes, eval results, the decision log, the rollback path. "The repo becomes product memory."
10. Recommended first loop — weekly product signal loop. don't start with strategy (too broad/subjective) but with product ops. Every Friday: read customer calls, support tickets, sales notes, experiment updates, analytics summaries, shipped changes, open escalations → produce a product signal memo that separates repeated signal from isolated noise, quotes the customer verbatim, shows what changed, flags thin evidence, and states which roadmap assumptions strengthened/weakened.
11. Taste remains central but needs PROOF. when judgment is put into reusable artifacts, one must prove that a change actually improves things (otherwise it just adds noise or "ceremony").
12. Human boundary. a loop can summarize evidence, revise a PRD, flag a risky launch — it must not decide strategy alone, become the product leader, or arbitrate without context. "Build the loop, but stay the PM." Increase autonomy slowly, after trust is earned.
13. Quotes & citations. Boris (creator of Claude Code) "doesn't prompt anymore, he writes loops that prompt for him"; "Generation is solved… Verification and judgment are all that's left"; Loop Library by Matthew Berman (real eng/research/ops loops).
14. Strong links. converges directly with Compound Engineering ("each unit of work makes the next one easier," compounding artifacts) and the Compound phase of the SDLC; echoes Stack Overflow for Agents (capitalize/verify instead of regenerate) and Monperrus / the verification > generation doctrine. CLAUDE.md as a living, versioned artifact ties back to the Context Engineering doctrine.