20 prompt per product manager che mostrano i compromessi

01. Scrivi un PRD da un brief confuso ed elenca le domande aperte

Hai un thread Slack, gli appunti di una call e una scadenza, ma nessuna specifica.

Trasforma questo brief confuso in un documento dei requisiti di prodotto.

[incolla il brief, il thread, gli appunti della call o quello che hai]

Sezioni, in quest'ordine: il problema e chi ce l'ha, le prove che abbiamo a riguardo, l'obiettivo con un risultato misurabile, cosa rientra nel perimetro, cosa ne resta fuori, il flusso utente in passaggi numerati, i requisiti segnati come MUST o SHOULD, e le dipendenze da altri team.

Usa solo ciò che dice il brief. Dove tace, scrivi [OPEN: la domanda] al posto di riempire il vuoto.

Poi elenca in fondo tutte le domande aperte, raggruppate per chi può rispondere (io, il design, l'ingegneria, il legale, un cliente), mettendo per prime le tre che bloccano lo sviluppo.

02. Dividi una funzionalità in user story con criteri di accettazione

Il refinement è domani e la funzionalità è ancora un unico ticket enorme.

Dividi questa funzionalità in user story che un team possa sviluppare e rilasciare una alla volta.

Funzionalità: [cosa fa]
Utenti: [chi la usa e cosa sta cercando di ottenere]
Vincoli: [piattaforme, scadenze, cose già sviluppate]

Per ogni story:
1. Come [utente], voglio [azione], così che [risultato].
2. Criteri di accettazione nella forma Given / When / Then, da tre a sei per story, ognuno verificabile da chi non l'ha scritto.
3. Una stima di dimensione S, M o L e la cosa che la rende incerta.

Ordina le story in modo che la prima rilasci qualcosa che un utente reale possa usare, anche se piccolo. Segnala ogni story che in realtà sono due, e ogni story che ha senso solo dopo il rilascio di un'altra.

03. Trova i casi limite che il tuo PRD ha trascurato

La specifica sembra finita e l'ingegneria parte la settimana prossima.

Leggi questo PRD come l'ingegnere che riceverà le segnalazioni di bug dopo il lancio.

[incolla il PRD o la specifica]

Elenca i casi limite che non copre, raggruppati così: stati vuoti e di primo utilizzo, errori e timeout, permessi e ruoli, limiti (molto lungo, molto numeroso, zero, duplicato), concorrenza (due persone che modificano, doppi clic, nuovi tentativi), dati precedenti all'esistenza di questa funzionalità e accessibilità.

Per ognuno: lo scenario in una riga, cosa fa intendere oggi la specifica che accadrebbe e la domanda a cui devo rispondere. Classifica i primi cinque in base a quanto è probabile che un utente reale li incontri nel primo mese. Non inventare requisiti: fai domande.

Sblocca gratis gli altri 17 prompt

Iscriviti alla newsletter di Whizi per leggere il resto di questo pack.

4. Dai un punteggio al backlog con RICE e mostra i calcoli
5. Trasforma gli appunti delle interviste in job, problemi e citazioni
6. Scrivi una guida per interviste di discovery su ciò che le persone hanno fatto, non su ciò che vogliono
7. Raggruppa i ticket di supporto in problemi di prodotto che vale la pena risolvere
8. Scrivi una specifica di una pagina da cui gli ingegneri possano sviluppare
9. Scegli una metrica di successo e la contro-metrica che la tiene onesta
10. Progetta un esperimento e rispondi prima alle domande sulla dimensione del campione
11. Crea una checklist di lancio con un responsabile per ogni team
12. Scrivi note di rilascio che gli utenti leggono davvero
13. Scrivi un aggiornamento per gli stakeholder che parte da ciò che è cambiato
14. Scrivi una narrazione della roadmap che dice cosa non farai
15. Rifiuta una richiesta di funzionalità con il motivo e un passo successivo
16. Fai un pre-mortem prima che il lancio parta
17. Smonta la pagina prodotto di un concorrente affermazione per affermazione
18. Scrivi un unico obiettivo di sprint da un lungo elenco di ticket
19. Trasforma una soluzione richiesta nel problema che c'è dietro
20. Fai rivedere il PRD del primo modello a un secondo modello