Loop Engineering for Product Managers

Punti chiave

1. Tesi centrale. la prossima competenza del PM non è il prompt engineering ma il Loop Engineering — "progettare un sistema che migliora ogni volta che viene eseguito", non scrivere il prompt perfetto ogni volta.
2. Definizione di loop. un ciclo ripetuto — modificare ciò che modella l'agente → eseguirlo → valutare → mantenere se la qualità aumenta / annullare altrimenti → capitalizzare l'apprendimento in modo che la versione successiva parta avvantaggiata.
3. Il punto d'ingresso del PM = gli artefatti. (non il codice): skill di PRD-review, summarizer di chiamate con i clienti, griglia di valutazione, checklist di lancio, workflow di ricerca, CLAUDE.md, template di prompt, framework di prioritizzazione. Sono durevoli, riutilizzati e codificano il giudizio; modellano l'agente attraverso decine di esecuzioni.
4. Accumulo bidirezionale. un buon artefatto affina il lavoro ogni settimana; uno cattivo lo rallenta, silenziosamente. "Un prompt usa e getta puoi permetterti di sbagliarlo. Una griglia da cui dipendono dieci persone, no."
5. Il problema che il prompting non risolve — IL DEGRADO (DRIFT). il CLAUDE.md continua a crescere, la skill di review si irrigidisce, la checklist si gonfia fino a essere per metà ignorata, i criteri di valutazione cambiano senza che nessuno sappia quando/perché. Un mese dopo l'agente "sembra peggiore": "probabilmente il modello non è peggiorato. I tuoi artefatti sono degradati, e nessuno li sorvegliava."
6. Anatomia di un loop — 5 componenti. (1) trigger (quando inizia), (2) azione (cosa fa l'agente), (3) prova (come sai che è migliore), (4) memoria (dove viene salvato l'apprendimento), (5) condizione di arresto (quando si ferma).
7. La condizione di arresto è la più critica. (soprattutto per i loop ricorsivi): molti sistemi falliscono non perché il modello è scadente, ma perché il loop non ha un'uscita pulita (scope creep, lavoro inventato, un riassunto sicuro di sé ma senza prova). Un buon loop di PM deve poter dire: niente è cambiato / l'input è troppo esiguo / è bloccato / la soglia di qualità non è raggiunta / serve una decisione umana. "Un loop che sa dire stop è un loop che puoi lasciare in esecuzione."
8. Gli eval diventano lavoro del PM. non un benchmark gigantesco — si parte da esempi noti. Es. 3 PRD forti / 3 deboli → l'artefatto coglie le lacune reali senza essere pignolo, preservando l'intento?; 5 chiamate già comprese → coglie il dolore reale, cita accuratamente, distingue il segnale forte dal rumore?; 2 lanci passati (1 riuscito, 1 fallito) → avrebbe individuato cosa si è rotto? Domanda: "questo artefatto è migliorato rispetto a un giudizio di prodotto noto?" (non "l'agente sembra intelligente?").
9. Livello di memoria = GitHub. non per trasformare i PM in ingegneri, ma per la cronologia delle versioni degli artefatti. Contiene l'artefatto, le modifiche, i risultati degli eval, il registro delle decisioni, il percorso di rollback. "Il repository diventa memoria di prodotto."
10. Primo loop consigliato — loop settimanale di segnale di prodotto. non partire dalla strategia (troppo ampia/soggettiva) ma dalle operazioni di prodotto. Ogni venerdì: leggere chiamate con i clienti, ticket di supporto, note vendite, aggiornamenti sperimenti, riepiloghi analytics, modifiche rilasciate, escalation aperte → produrre un memo di segnale di prodotto che separa il segnale ricorrente dal rumore isolato, cita testualmente il cliente, mostra cosa è cambiato, segnala le evidenze deboli e indica quali ipotesi di roadmap si sono rafforzate/indebolite.
11. Il gusto/istinto resta centrale ma richiede PROVA. quando il giudizio viene messo in artefatti riutilizzabili, bisogna dimostrare che una modifica migliora davvero le cose (altrimenti aggiunge solo rumore o "cerimonia").
12. Confine umano. un loop può riassumere le evidenze, rivedere un PRD, segnalare un lancio rischioso — non deve decidere la strategia da solo, diventare il leader di prodotto, o arbitrare senza contesto. "Costruisci il loop, ma resta il PM." Aumentare l'autonomia lentamente, dopo aver guadagnato fiducia.
13. Citazioni e riferimenti. Boris (creatore di Claude Code) "non fa più prompting, scrive loop che fanno prompting al posto suo"; "La generazione è risolta… restano solo la verifica e il giudizio"; Loop Library di Matthew Berman (loop reali di ingegneria/ricerca/operazioni).
14. Collegamenti forti. converge direttamente con il Compound Engineering ("ogni unità di lavoro rende più facile la successiva", accumulo di artefatti) e la fase Compound dell'SDLC; fa eco a Stack Overflow for Agents (capitalizzare/verificare invece di rigenerare) e a Monperrus / alla dottrina verifica > generazione. CLAUDE.md come artefatto vivo e versionato si ricollega alla dottrina del Context Engineering.