# saboo-loop-engineering-product-managers-2026-06-21

## Veille

Long-form essay by **Shubham Saboo** (X/Twitter) advancing a thesis on the Product Manager role in the age of agents: the next key skill is **not prompt engineering** but **Loop Engineering** — designing a *system that improves with every run* rather than writing the perfect prompt every time. A **loop** is a repeated cycle: change what shapes the agent's behavior → run it → evaluate the output → keep the change if quality rises, revert otherwise → **compound the learning** so the next version starts ahead. For a PM, the entry point is not code but the **durable artifacts** that encode their judgment: PRD-review skill, customer-call *summarizer*, evaluation rubric, launch checklist, research workflow, `CLAUDE.md`, prompt template, prioritization framework. Because they are reused, these artifacts **compound in both directions** — and **drift** silently (a CLAUDE.md that keeps growing, a checklist that gets ignored…): the model has not regressed, the artifacts have drifted unwatched. A loop has **5 parts**: trigger, action, **proof**, memory, **stop condition** (the most critical). **Evals** become PM work (testing the artifact against known examples: 3 good / 3 bad PRDs, 5 understood calls, 2 past launches). **Memory** lives on **GitHub** (the repo becomes "product memory": commits, diffs, eval results, decision log, rollback). Recommended first loop: a **weekly product signal loop** (every Friday). Taste remains central — but it now needs **proof**. Cites Boris (creator of Claude Code): "he no longer writes prompts, he writes loops."

## Titre Article

Loop Engineering for Product Managers

## Date

2026-06-21

## URL

https://x.com/Saboo_Shubham_/status/2068730090457006588

## Keywords

Loop Engineering, product management, augmented PM, prompt engineering, reusable artifacts, artifact drift, drift, compounding, stop condition, agentic loop, evals, evaluation rubric, PRD review, customer-call summarizer, launch checklist, CLAUDE.md, product memory, GitHub, versioning, weekly product signal loop, verification, judgment, taste, Boris Cherny, Claude Code

## Authors

Shubham Saboo (@Saboo_Shubham_)

## Ton

Profile: long-form opinion essay published as an X/Twitter thread, the perspective of an AI-product practitioner-evangelist addressing fellow PMs directly ("you"), didactic and prescriptive register in English, medium technical level (engineering vocabulary made accessible to non-developers), target audience of product managers, product leads, and product-ops practitioners already working with agents. The tone is that of a **pedagogical manifesto**: a thesis-slogan ("the next PM skill is not prompt engineering, it is Loop Engineering"), a controlled climb in abstraction (from a concrete problem — drift — toward the 5-part framework), and an emphasis on the **actionable** ("your first loop," "the skeleton for any loop"). Authority rests on field experience (PRD examples, customer calls, launches) and on external endorsements (Boris, creator of Claude Code; Matthew Berman's *Loop Library*). The rhetoric proceeds through **binary oppositions** (prompting once vs. a loop that improves every run; generation solved vs. verification/judgment remaining; a compounding artifact vs. a decaying one) and memorable formulas ("a loop that can say stop is a loop you can leave running"). Implicit metaphor: the artifact as a living organism that, left unwatched, **rots** — and the loop as an immune system that keeps it healthy. Final balanced stance: "build the loop, but stay the PM."

## Pense-betes

- **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.
- **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.
- **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.
- **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."*
- **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."*
- **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).
- **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."*
- **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?").
- **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."*
- **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.
- **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").
- **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.
- **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).
- **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.

## RésuméDe400mots

In this long-form essay published on X, **Shubham Saboo** argues that the next decisive skill for the Product Manager in the age of agents is not **prompt engineering** but **Loop Engineering**. The end state is not a PM writing the perfect prompt every time they need something, but a PM **designing a system that improves with every run**. A loop is a repeated cycle: change what shapes the agent's behavior, run it, evaluate the output, keep the change if quality improves and revert it otherwise, then **compound the learning** so the next version starts ahead.

For an engineer, this cycle starts from code. For a PM, it starts from the **artifacts** that structure product work: PRD-review skill, customer-call *summarizer*, evaluation rubric, launch checklist, research workflow, `CLAUDE.md`, prompt template, prioritization framework. Durable and reused, they encode judgment and shape the agent across dozens of runs — so they **compound in both directions**. This is where the real problem shows up: **drift**. The CLAUDE.md keeps growing, the checklist swells, eval criteria change without a trace; a month later the agent "seems worse." The model has not regressed: the artifacts have drifted unwatched, and this is precisely what Loop Engineering corrects.

A useful loop has **five parts**: trigger, action, **proof**, memory, **stop condition**. The last is the most critical: many systems fail for lack of a clean exit (scope creep, a confident summary with no proof). A good loop must be able to say "stop" — nothing changed, input too thin, blocked, bar not met, human decision required.

Putting one's judgment into reusable artifacts requires that **taste** now come with **proof**: **evals** become PM work, built from known examples (3 good / 3 bad PRDs, 5 understood calls, 2 past launches). The question is no longer "does the agent look smart?" but "did this artifact improve against known product judgment?" Learning needs a **memory**: **GitHub**, where the artifact, diffs, eval results, decision log, and rollback path live — *"the repo becomes product memory."*

Saboo advises starting small, with **product ops**: a **weekly product signal loop** (every Friday) producing a memo that separates repeated signal from isolated noise. The loop informs a decision the PM **keeps**: *"build the loop, but stay the PM."* Generation is solved; verification and judgment remain.

## GrapheDeConnaissance

- Shubham Saboo —publie→ Loop Engineering for Product Managers (DOCUMENT, 0.97)
- Shubham Saboo —recommande→ le Loop Engineering comme prochaine compétence clé des PM (AFFIRMATION, 0.95)
- Loop Engineering —remplace→ prompt engineering (METHODOLOGIE, 0.85)
- Loop Engineering —utilise→ artefacts réutilisables (revue de PRD, summarizer, rubrique d'éval, checklist) (CONCEPT, 0.92)
- Loop Engineering —résout→ dérive des artefacts (artifact drift) (CONCEPT, 0.9)
- Loop Engineering —utilise→ condition d'arrêt (stop condition) (CONCEPT, 0.9)
- Loop Engineering —s_applique_à→ product management (ops produit) (CONCEPT, 0.9)
- évaluations (evals) —permet→ preuve qu'un artefact s'améliore face à un jugement produit connu (CONCEPT, 0.88)
- GitHub —permet→ mémoire produit (version history des artefacts) (CONCEPT, 0.88)
- weekly product signal loop —est_instance_de→ Loop Engineering (METHODOLOGIE, 0.85)
- Loop Engineering —converge_avec→ Compound Engineering (METHODOLOGIE, 0.82)
- Boris Cherny —a_créé→ Claude Code (TECHNOLOGIE, 0.95)
- Boris Cherny —affirme_que→ il n'écrit plus de prompts mais des boucles qui prompt pour lui (CITATION, 0.88)
- Shubham Saboo —affirme_que→ la génération est résolue ; vérification et jugement sont tout ce qui reste (CITATION, 0.9)
- Matthew Berman —a_créé→ Loop Library (DOCUMENT, 0.85)

---
Canonical: https://www.thekb.eu/en/fiches/saboo-loop-engineering-product-managers-2026-06-21/