Product Management Word Avanzato

Template per Feature Spec e PRD in Word

Smetti di passare a design ed engineering brief vaghi: ottieni un PRD strutturato con problema, soluzione, requisiti numerati, edge case e criteri di accettazione, pronto da incollare in un documento Word.

#product-management #feature-spec #prd #requisiti #documentazione

Usa nel Playbox Personalizza nel wizard

Claude · Anthropic

<role>
Agisci come un Senior Product Manager con esperienza in prodotti SaaS B2B, abituato a scrivere PRD che design ed engineering possono eseguire senza chiarimenti aggiuntivi.
</role>

<task>
Scrivi una specifica funzionale completa (feature spec / PRD) per la feature descritta, strutturata in 10 sezioni: sommario esecutivo, problema e contesto, obiettivi e metriche, requisiti funzionali numerati, requisiti non funzionali, edge case e gestione errori, fuori scope, dipendenze, criteri di accettazione, domande aperte. Numera ogni requisito con un ID univoco e assegna una priorità MoSCoW.
</task>

<context>
Feature da specificare: [nome e descrizione feature]. Problema utente: [problema]. Segmento target: [segmento]. Evidenze disponibili: [ricerca/dati/ticket]. Obiettivo di business: [obiettivo]. Metriche note: [metriche o baseline se disponibili]. Vincoli tecnici/legali: [vincoli]. Sistemi e team coinvolti: [dipendenze].
</context>

<output_format>
Documento Word con heading H1 per il titolo, H2 per le 10 sezioni numerate, tabelle multi-colonna per requisiti, metriche, dipendenze e criteri di accettazione. Usa checkbox per i criteri di accettazione. Ogni requisito funzionale e non funzionale deve avere un ID (RF-NN / RNF-NN).
</output_format>

<constraints>
Non inventare numeri, baseline o target: se un dato non è negli input, scrivi '[da quantificare]' e spostalo in 'Domande aperte'. Marca come 'assunzione da validare' qualsiasi requisito dedotto e non esplicito. Massimo 1.500 parole. Non includere stime di tempo/effort (compito di engineering). Linguaggio professionale, frasi brevi, niente marketing.
</constraints>

<tone>
Professionale, asciutto, orientato all'esecuzione. Preciso e privo di ambiguità.
</tone>

DeepSeek · DeepSeek

Ruolo: Agisci come un Senior Product Manager con esperienza in prodotti SaaS B2B, abituato a scrivere PRD che design ed engineering possono eseguire senza chiarimenti aggiuntivi.

Obiettivo: Scrivi una specifica funzionale completa (feature spec / PRD) per la feature descritta, strutturata in 10 sezioni: sommario esecutivo, problema e contesto, obiettivi e metriche, requisiti funzionali numerati, requisiti non funzionali, edge case e gestione errori, fuori scope, dipendenze, criteri di accettazione, domande aperte. Numera ogni requisito con un ID univoco e assegna una priorità MoSCoW.

Contesto: Feature da specificare: [nome e descrizione feature]. Problema utente: [problema]. Segmento target: [segmento]. Evidenze disponibili: [ricerca/dati/ticket]. Obiettivo di business: [obiettivo]. Metriche note: [metriche o baseline se disponibili]. Vincoli tecnici/legali: [vincoli]. Sistemi e team coinvolti: [dipendenze].

Formato output: Documento Word con heading H1 per il titolo, H2 per le 10 sezioni numerate, tabelle multi-colonna per requisiti, metriche, dipendenze e criteri di accettazione. Usa checkbox per i criteri di accettazione. Ogni requisito funzionale e non funzionale deve avere un ID (RF-NN / RNF-NN).

Vincoli & regole: Non inventare numeri, baseline o target: se un dato non è negli input, scrivi '[da quantificare]' e spostalo in 'Domande aperte'. Marca come 'assunzione da validare' qualsiasi requisito dedotto e non esplicito. Massimo 1.500 parole. Non includere stime di tempo/effort (compito di engineering). Linguaggio professionale, frasi brevi, niente marketing.

Tono & stile: Professionale, asciutto, orientato all'esecuzione. Preciso e privo di ambiguità.

Gemini · Google

## Ruolo
Agisci come un Senior Product Manager con esperienza in prodotti SaaS B2B, abituato a scrivere PRD che design ed engineering possono eseguire senza chiarimenti aggiuntivi.

## Contesto
Feature da specificare: [nome e descrizione feature]. Problema utente: [problema]. Segmento target: [segmento]. Evidenze disponibili: [ricerca/dati/ticket]. Obiettivo di business: [obiettivo]. Metriche note: [metriche o baseline se disponibili]. Vincoli tecnici/legali: [vincoli]. Sistemi e team coinvolti: [dipendenze].

## Obiettivo
Scrivi una specifica funzionale completa (feature spec / PRD) per la feature descritta, strutturata in 10 sezioni: sommario esecutivo, problema e contesto, obiettivi e metriche, requisiti funzionali numerati, requisiti non funzionali, edge case e gestione errori, fuori scope, dipendenze, criteri di accettazione, domande aperte. Numera ogni requisito con un ID univoco e assegna una priorità MoSCoW.

## Tono & stile
Professionale, asciutto, orientato all'esecuzione. Preciso e privo di ambiguità.

## Formato output
Documento Word con heading H1 per il titolo, H2 per le 10 sezioni numerate, tabelle multi-colonna per requisiti, metriche, dipendenze e criteri di accettazione. Usa checkbox per i criteri di accettazione. Ogni requisito funzionale e non funzionale deve avere un ID (RF-NN / RNF-NN).

## Vincoli & regole
Non inventare numeri, baseline o target: se un dato non è negli input, scrivi '[da quantificare]' e spostalo in 'Domande aperte'. Marca come 'assunzione da validare' qualsiasi requisito dedotto e non esplicito. Massimo 1.500 parole. Non includere stime di tempo/effort (compito di engineering). Linguaggio professionale, frasi brevi, niente marketing.

Grok · xAI

## Ruolo
Agisci come un Senior Product Manager con esperienza in prodotti SaaS B2B, abituato a scrivere PRD che design ed engineering possono eseguire senza chiarimenti aggiuntivi.

## Obiettivo
Scrivi una specifica funzionale completa (feature spec / PRD) per la feature descritta, strutturata in 10 sezioni: sommario esecutivo, problema e contesto, obiettivi e metriche, requisiti funzionali numerati, requisiti non funzionali, edge case e gestione errori, fuori scope, dipendenze, criteri di accettazione, domande aperte. Numera ogni requisito con un ID univoco e assegna una priorità MoSCoW.

## Contesto
Feature da specificare: [nome e descrizione feature]. Problema utente: [problema]. Segmento target: [segmento]. Evidenze disponibili: [ricerca/dati/ticket]. Obiettivo di business: [obiettivo]. Metriche note: [metriche o baseline se disponibili]. Vincoli tecnici/legali: [vincoli]. Sistemi e team coinvolti: [dipendenze].

## Formato output
Documento Word con heading H1 per il titolo, H2 per le 10 sezioni numerate, tabelle multi-colonna per requisiti, metriche, dipendenze e criteri di accettazione. Usa checkbox per i criteri di accettazione. Ogni requisito funzionale e non funzionale deve avere un ID (RF-NN / RNF-NN).

## Vincoli & regole
Non inventare numeri, baseline o target: se un dato non è negli input, scrivi '[da quantificare]' e spostalo in 'Domande aperte'. Marca come 'assunzione da validare' qualsiasi requisito dedotto e non esplicito. Massimo 1.500 parole. Non includere stime di tempo/effort (compito di engineering). Linguaggio professionale, frasi brevi, niente marketing.

## Tono & stile
Professionale, asciutto, orientato all'esecuzione. Preciso e privo di ambiguità.

## Verbosità
Fornisci una risposta completa e dettagliata, coerente con il formato richiesto.

Mistral · Mistral AI

## Ruolo
Agisci come un Senior Product Manager con esperienza in prodotti SaaS B2B, abituato a scrivere PRD che design ed engineering possono eseguire senza chiarimenti aggiuntivi.

## Obiettivo
Scrivi una specifica funzionale completa (feature spec / PRD) per la feature descritta, strutturata in 10 sezioni: sommario esecutivo, problema e contesto, obiettivi e metriche, requisiti funzionali numerati, requisiti non funzionali, edge case e gestione errori, fuori scope, dipendenze, criteri di accettazione, domande aperte. Numera ogni requisito con un ID univoco e assegna una priorità MoSCoW.

## Contesto
Feature da specificare: [nome e descrizione feature]. Problema utente: [problema]. Segmento target: [segmento]. Evidenze disponibili: [ricerca/dati/ticket]. Obiettivo di business: [obiettivo]. Metriche note: [metriche o baseline se disponibili]. Vincoli tecnici/legali: [vincoli]. Sistemi e team coinvolti: [dipendenze].

## Formato output
Documento Word con heading H1 per il titolo, H2 per le 10 sezioni numerate, tabelle multi-colonna per requisiti, metriche, dipendenze e criteri di accettazione. Usa checkbox per i criteri di accettazione. Ogni requisito funzionale e non funzionale deve avere un ID (RF-NN / RNF-NN).

## Vincoli & regole
Non inventare numeri, baseline o target: se un dato non è negli input, scrivi '[da quantificare]' e spostalo in 'Domande aperte'. Marca come 'assunzione da validare' qualsiasi requisito dedotto e non esplicito. Massimo 1.500 parole. Non includere stime di tempo/effort (compito di engineering). Linguaggio professionale, frasi brevi, niente marketing.

## Tono & stile
Professionale, asciutto, orientato all'esecuzione. Preciso e privo di ambiguità.

## Verbosità
Fornisci una risposta completa e dettagliata, coerente con il formato richiesto.

ChatGPT · OpenAI

## Ruolo
Agisci come un Senior Product Manager con esperienza in prodotti SaaS B2B, abituato a scrivere PRD che design ed engineering possono eseguire senza chiarimenti aggiuntivi.

## Obiettivo
Scrivi una specifica funzionale completa (feature spec / PRD) per la feature descritta, strutturata in 10 sezioni: sommario esecutivo, problema e contesto, obiettivi e metriche, requisiti funzionali numerati, requisiti non funzionali, edge case e gestione errori, fuori scope, dipendenze, criteri di accettazione, domande aperte. Numera ogni requisito con un ID univoco e assegna una priorità MoSCoW.

## Contesto
Feature da specificare: [nome e descrizione feature]. Problema utente: [problema]. Segmento target: [segmento]. Evidenze disponibili: [ricerca/dati/ticket]. Obiettivo di business: [obiettivo]. Metriche note: [metriche o baseline se disponibili]. Vincoli tecnici/legali: [vincoli]. Sistemi e team coinvolti: [dipendenze].

## Formato output
Documento Word con heading H1 per il titolo, H2 per le 10 sezioni numerate, tabelle multi-colonna per requisiti, metriche, dipendenze e criteri di accettazione. Usa checkbox per i criteri di accettazione. Ogni requisito funzionale e non funzionale deve avere un ID (RF-NN / RNF-NN).

## Vincoli & regole
Non inventare numeri, baseline o target: se un dato non è negli input, scrivi '[da quantificare]' e spostalo in 'Domande aperte'. Marca come 'assunzione da validare' qualsiasi requisito dedotto e non esplicito. Massimo 1.500 parole. Non includere stime di tempo/effort (compito di engineering). Linguaggio professionale, frasi brevi, niente marketing.

## Tono & stile
Professionale, asciutto, orientato all'esecuzione. Preciso e privo di ambiguità.

## Verbosità
Fornisci una risposta completa e dettagliata, coerente con il formato richiesto.

Perplexity · Perplexity

Scrivi una specifica funzionale completa (feature spec / PRD) per la feature descritta, strutturata in 10 sezioni: sommario esecutivo, problema e contesto, obiettivi e metriche, requisiti funzionali numerati, requisiti non funzionali, edge case e gestione errori, fuori scope, dipendenze, criteri di accettazione, domande aperte. Numera ogni requisito con un ID univoco e assegna una priorità MoSCoW.
Ruolo: Agisci come un Senior Product Manager con esperienza in prodotti SaaS B2B, abituato a scrivere PRD che design ed engineering possono eseguire senza chiarimenti aggiuntivi.
Contesto: Feature da specificare: [nome e descrizione feature]. Problema utente: [problema]. Segmento target: [segmento]. Evidenze disponibili: [ricerca/dati/ticket]. Obiettivo di business: [obiettivo]. Metriche note: [metriche o baseline se disponibili]. Vincoli tecnici/legali: [vincoli]. Sistemi e team coinvolti: [dipendenze].
Formato output: Documento Word con heading H1 per il titolo, H2 per le 10 sezioni numerate, tabelle multi-colonna per requisiti, metriche, dipendenze e criteri di accettazione. Usa checkbox per i criteri di accettazione. Ogni requisito funzionale e non funzionale deve avere un ID (RF-NN / RNF-NN).
Vincoli & regole: Non inventare numeri, baseline o target: se un dato non è negli input, scrivi '[da quantificare]' e spostalo in 'Domande aperte'. Marca come 'assunzione da validare' qualsiasi requisito dedotto e non esplicito. Massimo 1.500 parole. Non includere stime di tempo/effort (compito di engineering). Linguaggio professionale, frasi brevi, niente marketing.
Tono & stile: Professionale, asciutto, orientato all'esecuzione. Preciso e privo di ambiguità.

Esempio di output

# Feature Spec — Notifiche smart per scadenze fatture

## 1. Sommario esecutivo
Introdurre notifiche configurabili che avvisano l'utente X giorni prima della scadenza di una fattura, riducendo i pagamenti in ritardo. Stato: Draft. Owner: [nome PM].

## 2. Problema e contesto
| Elemento | Dettaglio |
|---|---|
| Problema utente | I clienti dimenticano scadenze e accumulano mora |
| Evidenza | [link a ricerca / ticket / dato] |
| Segmento | PMI con >50 fatture/mese |
| Costo del non fare nulla | [da quantificare — domanda aperta] |

## 3. Obiettivi e metriche di successo
| Obiettivo | Metrica | Baseline | Target |
|---|---|---|---|
| Ridurre ritardi | % fatture pagate entro scadenza | [baseline] | [target] |

## 4. Requisiti funzionali
| ID | Requisito | Priorità (MoSCoW) | Note |
|---|---|---|---|
| RF-01 | L'utente può impostare l'anticipo (1/3/7 gg) | Must | |
| RF-02 | Notifica via email e in-app | Must | |
| RF-03 | Snooze della notifica | Could | |

## 5. Requisiti non funzionali
| ID | Categoria | Requisito |
|---|---|---|
| RNF-01 | Performance | Invio entro 60s dalla soglia |
| RNF-02 | Privacy | Nessun dato fattura in chiaro nel push |

## 6. Edge case e gestione errori
- Fattura modificata dopo programmazione notifica → riprogramma
- Utente senza email verificata → fallback solo in-app

## 7. Fuori scope
- Notifiche SMS (valutare in v2)

## 8. Dipendenze
| Dipendenza | Team | Stato |
|---|---|---|
| Servizio email transazionale | Platform | Da confermare |

## 9. Criteri di accettazione
- [ ] Dato un anticipo di 3 gg, la notifica arriva il giorno corretto
- [ ] Disattivando le notifiche, non viene inviato nulla

## 10. Domande aperte
- Quale baseline reale per i ritardi attuali?
- Costo del non fare nulla da quantificare con Finance

Domande frequenti

Posso usarlo anche senza avere ancora le metriche di successo definite?

Sì, ma la qualità del documento dipende dalla precisione degli input. Se non hai metriche di successo, il prompt ti segnalerà esplicitamente la lacuna come 'open question' invece di inventare numeri, così sai cosa devi ancora decidere prima del handoff.

Che differenza c'è tra questo e una semplice user story?

Una user story descrive un bisogno in una frase. Questo prompt produce il documento completo che sta a monte: contesto, requisiti funzionali e non funzionali numerati, edge case, dipendenze, criteri di accettazione e metriche. Le user story diventano una sezione del PRD, non il PRD intero.

Come evito che il modello inventi requisiti che non ho chiesto?

Il prompt impone di derivare i requisiti solo dagli input forniti e di marcare come 'assunzione da validare' qualsiasi elemento dedotto. Tutto ciò che non è ricavabile dagli input finisce nella sezione 'Domande aperte', non tra i requisiti.

Vuoi un prompt su misura?

Costruiscine uno in poche domande — e adattalo a ogni modello.

Crea il tuo prompt