Guida operativa standard per PM
Per ogni PM del nostro team di prodotto, che tu sappia programmare o no. L'obiettivo di questa guida: portarti da «non oso usarlo, non so come» a «non posso farne a meno».
Prima di tutto: non aver paura, usalo senza freni
Se la tua sensazione attuale verso Claude Code è «ne ho sentito parlare bene, ma non so da dove iniziare», è del tutto normale. Prima di tutto sfatiamo tre equivoci.
Equivoco 1: non so programmare, non posso usarlo
Sbagliato, anzi è esattamente il contrario — non saper programmare è un vantaggio. Non sei vincolato da «quanto è difficile implementarlo», ti concentri solo su cosa vuoi dire e lo descrivi chiaramente. E «descrivere l'idea con chiarezza» è esattamente il mestiere del product manager. Il futuro è «dillo, l'IA lo costruisce»: una frase e l'IA te lo fa.
Equivoco 2: lo rompo, combino guai
Sbagliato. Nella tua cartella di progetto puoi fare quello che vuoi senza problemi. Nel peggiore dei casi fa qualcosa di sbagliato e tu dici «no, ricomincia».
Equivoco 3: è uno strumento, devo imparare a «operarlo»
Cambia prospettiva: non è uno strumento, è il tuo collaboratore. Un tirocinante tuttofare che non si stanca mai, sempre disponibile, con competenze di ogni tipo. Devi solo dargli istruzioni chiare, come faresti con una persona.
Primo passo: impara a dialogare in 5 minuti
Non devi imparare nessun comando. Entra nella cartella del progetto e parla normalmente. Il nucleo è tre frasi.
Inizia dalla cosa più semplice
Crea una pagina web con il titolo "Ciao", sfondo azzurro chiaro, poi avvia un server locale così posso vederla nel browser.
Se nel browser appare la pagina = congratulazioni, sai già usarlo.
Le tre frasi fondamentali
- «Aiutami a fare…» — assegna il compito
- «Qui non va bene, dovrebbe essere…» — dai feedback
- «Prima di fare, dimmi alcune domande» — fallo ragionare con te
Principi fondamentali: quattro premesse
| Premessa | Significato |
|---|---|
| Non serve programmare, serve descrivere | È il traduttore da «idea» a «prodotto finito»: più sei preciso, più il risultato è accurato. |
| Accessibile a tutti, livelli diversi | Non c'è nessuna barriera d'ingresso, solo gradi di padronanza. |
| Prototipo = qualcosa che funziona davvero | Si può cliccare, è interattivo, si può dare all'utente da provare — non è un'immagine statica. |
| Tutto il team cambia insieme | Il nuovo modo di lavorare predefinito del team, non un esperimento individuale. |
Flusso di lavoro in cinque fasi (nel dettaglio)
Il lavoro del PM suddiviso in cinque fasi. Per ciascuna: obiettivo, come dirlo, criteri di completamento, ostacoli per i principianti.
Scoprire
Obiettivo: capire cosa vogliono gli utenti, cosa fanno i competitor, dove va il mercato.
/competitor-watch analizza [URL competitor], focus su [prezzi/funzioni IA], crea report comparativo
Sai spiegare in tre frasi qual è il dolore principale degli utenti; conosci come i competitor lo risolvono e qual è la nostra differenza.
Domanda troppo generica. Soluzione: dai un soggetto specifico + un punto di attenzione specifico + un formato di output specifico.
Definire
Obiettivo: trasformare un'idea vaga in requisiti chiari che chiunque può seguire (PRD).
/office-hours voglio fare [idea], non darmi ancora soluzioni, prima fammi 5 domande chiave → /prd-generator scrivi un PRD completo
Ci sono indicatori di successo chiari; i casi limite sono elencati; anche chi non ha partecipato capisce.
Si chiede di scrivere subito e lui inventa i dettagli. Soluzione: farlo sempre «fare domande prima» poi scrivere.
Progettare
Obiettivo: prima di costruire, vedere «come potrebbe essere» e scegliere la direzione.
/design-shotgun crea 3 varianti di stile per la pagina di login: A minimalista B professionale C vivace, in una pagina affiancata per il confronto
È stata scelta una direzione; si ha un'idea di come saranno le pagine chiave.
Voler subito la perfezione e stare a indecidersi. Soluzione: chiedere prima 3 soluzioni grezze, scegliere dopo averle viste.
Prototipare
Obiettivo: trasformare il design in un prototipo cliccabile, interattivo, utilizzabile dagli utenti. Principio core: piccoli passi veloci.
/design-html crea il prototipo → poi aggiungi una funzione alla volta: «cambia il grafico in blu brand» «aggiungi pulsante esporta CSV»… iterazione in dialogo
Funziona davvero nel browser; il flusso principale si percorre senza errori; i dati finti reggono la demo.
Chiedere 20 cose in una volta. Soluzione: una alla volta! Non preoccuparti della qualità del codice del prototipo.
Validare
Obiettivo: far provare agli utenti reali, prendere decisioni basate su dati e non su sensazioni.
/qa testa questo prototipo, clicca tutto quello che si può cliccare, trova errori, blocchi e comportamenti inaspettati, elencali
Il flusso principale funziona senza bug evidenti; l'hanno provato utenti reali; si può rispondere con prove se vale la pena continuare.
Cliccare due volte e trarre conclusioni. Soluzione: farlo sempre provare a qualcun altro e stare in silenzio a osservare dove si blocca.
Percorso di crescita delle competenze
Non serve arrivare a tutto subito, cresci con questo ritmo.
Linea di fondo: questa è una rete di sicurezza, non una gabbia
Proprio perché queste 5 regole fanno da pavimento, puoi sperimentare e usarlo liberamente sopra di esse.
- Non dargli dati sensibili reali — usa dati finti o anonimizzati per i prototipi.
- Non mettere chiavi di accesso nel codice — chiedi al team le credenziali di test dedicate.
- Per le azioni irreversibili clicca tu l'ultimo tasto — pubblicazione, eliminazione, pagamenti: la conferma finale la dai tu.
- Non toccare i sistemi in produzione — i prototipi girano solo in locale o in ambienti di test.
- Se sei in dubbio, chiedi — compliance, pagamenti, privacy, scelte tecnologiche: prima chiedi al team lead.
Piano di crescita in tre settimane
| Settimana | Obiettivo | Azioni concrete |
|---|---|---|
| Settimana 1 | Superare la paura | Configura l'ambiente, fai girare la prima pagina web, esercitati 3 conversazioni al giorno. |
| Settimana 2 | Un vero utilizzo | Usa un requisito reale e piccolo, percorri una volta «scrivi PRD → fai prototipo». |
| Settimana 3 | Ciclo autonomo | Percorri per intero «idea → prototipo → prova con colleghi → miglioramento». |
Appendice
A · Le quattro regole per i prompt
| Regola | ❌ Così no | ✅ Così sì |
|---|---|---|
| Sii specifico | Fai una bella pagina | Pagina di login, card centrata, email + password, pulsante blu #3B82F6 |
| Dai contesto | Aggiungi una funzione di esportazione | In alto a destra nella bacheca aggiungi pulsante esporta, scarica CSV con i risultati filtrati |
| Vai a step | 15 richieste in una volta | Una alla volta, vedi il risultato poi passa alla successiva |
| Dai un riferimento | Aggiusta un po' i colori | Colore principale #3B82F6, prendi come riferimento la palette di Stripe |
B · Guida rapida alle competenze più usate
Nella conversazione digita / e vedi tutto l'elenco. Le più usate dai PM: /office-hours affina l'idea · /prd-generator scrivi PRD · /competitor-watch competitor · /design-shotgun più varianti · /design-html prototipo · /qa test · /make-pdf converti in PDF.
C · FAQ per principianti
D: Ha sbagliato qualcosa, ma non so programmare — come lo correggo?
Di' direttamente «qui non va bene, quello che voglio è…». Lo corregge da solo.
D: Il prototipo può diventare il prodotto finale per gli utenti?
Può essere usato per test su piccola scala, ma non può andare in produzione ufficialmente. Per il rilascio lo sviluppo deve fare una riscrittura di livello produttivo.
D: Quanto tempo ci vuole per un prototipo?
Per i semplici poche ore, per i complessi 1 giorno. Se dopo 1 giorno non è uscito niente, il requisito è troppo grande: spezzalo.
D: Ho paura di sprecare tempo a tentare e sbagliare.
Il tentativo e l'errore è il valore core di questo modo di lavorare. Più velocemente sbagli, prima trovi la direzione giusta.
