Product Management Word Intermedio

Template per Release Notes in Word

Basta release notes copiate dai commit: ottieni un documento a due livelli, una sintesi orientata al beneficio per gli utenti e un changelog tecnico ordinato per categoria, pronto in Word.

#product-management #release-notes #changelog #comunicazione #rilascio

Usa nel Playbox Personalizza nel wizard

Claude · Anthropic

<role>
Agisci come un Product Manager che cura la comunicazione di rilascio, capace di tradurre modifiche tecniche in valore percepito dal cliente senza perdere precisione tecnica.
</role>

<task>
Trasforma l'elenco grezzo di modifiche fornito in un documento di release notes a due livelli: (1) una parte rivolta al cliente con sintesi 'In breve', azioni richieste, Novità, Miglioramenti, Correzioni in linguaggio orientato al beneficio; (2) un changelog tecnico in tabella ordinato per tipo (feat/fix/perf/breaking) con componente, descrizione e riferimento al ticket.
</task>

<context>
Versione: [X.Y.Z]. Data: [data]. Prodotto: [nome]. Pubblico cliente: [tipo utente]. Tono desiderato per il cliente: [sobrio/friendly/enterprise]. Elenco grezzo modifiche (commit/ticket): [incolla qui le voci]. Breaking change o azioni richieste note: [eventuali].
</context>

<output_format>
Documento Word: H1 con versione e data; H2 per ogni sezione; tabella per 'Azioni richieste' e per il 'Changelog tecnico'; elenchi puntati con la parte in grassetto del beneficio nelle sezioni cliente. Separa nettamente la parte cliente dal changelog tecnico con una linea orizzontale.
</output_format>

<constraints>
Riscrivi ogni voce tecnica in beneficio per l'utente nella parte cliente; escludi dalla parte cliente le voci puramente interne (refactor, bump dipendenze, test) ma mantienile nel changelog tecnico. Non inventare percentuali o numeri di miglioramento: se non forniti, usa '[X]%' come segnaposto. Metti sempre breaking change e azioni richieste in cima. Massimo 700 parole nella parte cliente.
</constraints>

<tone>
Parte cliente: chiara e orientata al beneficio, nel tono indicato. Changelog tecnico: fattuale, neutro, conciso.
</tone>

DeepSeek · DeepSeek

Ruolo: Agisci come un Product Manager che cura la comunicazione di rilascio, capace di tradurre modifiche tecniche in valore percepito dal cliente senza perdere precisione tecnica.

Obiettivo: Trasforma l'elenco grezzo di modifiche fornito in un documento di release notes a due livelli: (1) una parte rivolta al cliente con sintesi 'In breve', azioni richieste, Novità, Miglioramenti, Correzioni in linguaggio orientato al beneficio; (2) un changelog tecnico in tabella ordinato per tipo (feat/fix/perf/breaking) con componente, descrizione e riferimento al ticket.

Contesto: Versione: [X.Y.Z]. Data: [data]. Prodotto: [nome]. Pubblico cliente: [tipo utente]. Tono desiderato per il cliente: [sobrio/friendly/enterprise]. Elenco grezzo modifiche (commit/ticket): [incolla qui le voci]. Breaking change o azioni richieste note: [eventuali].

Formato output: Documento Word: H1 con versione e data; H2 per ogni sezione; tabella per 'Azioni richieste' e per il 'Changelog tecnico'; elenchi puntati con la parte in grassetto del beneficio nelle sezioni cliente. Separa nettamente la parte cliente dal changelog tecnico con una linea orizzontale.

Vincoli & regole: Riscrivi ogni voce tecnica in beneficio per l'utente nella parte cliente; escludi dalla parte cliente le voci puramente interne (refactor, bump dipendenze, test) ma mantienile nel changelog tecnico. Non inventare percentuali o numeri di miglioramento: se non forniti, usa '[X]%' come segnaposto. Metti sempre breaking change e azioni richieste in cima. Massimo 700 parole nella parte cliente.

Tono & stile: Parte cliente: chiara e orientata al beneficio, nel tono indicato. Changelog tecnico: fattuale, neutro, conciso.

Gemini · Google

## Ruolo
Agisci come un Product Manager che cura la comunicazione di rilascio, capace di tradurre modifiche tecniche in valore percepito dal cliente senza perdere precisione tecnica.

## Contesto
Versione: [X.Y.Z]. Data: [data]. Prodotto: [nome]. Pubblico cliente: [tipo utente]. Tono desiderato per il cliente: [sobrio/friendly/enterprise]. Elenco grezzo modifiche (commit/ticket): [incolla qui le voci]. Breaking change o azioni richieste note: [eventuali].

## Obiettivo
Trasforma l'elenco grezzo di modifiche fornito in un documento di release notes a due livelli: (1) una parte rivolta al cliente con sintesi 'In breve', azioni richieste, Novità, Miglioramenti, Correzioni in linguaggio orientato al beneficio; (2) un changelog tecnico in tabella ordinato per tipo (feat/fix/perf/breaking) con componente, descrizione e riferimento al ticket.

## Tono & stile
Parte cliente: chiara e orientata al beneficio, nel tono indicato. Changelog tecnico: fattuale, neutro, conciso.

## Formato output
Documento Word: H1 con versione e data; H2 per ogni sezione; tabella per 'Azioni richieste' e per il 'Changelog tecnico'; elenchi puntati con la parte in grassetto del beneficio nelle sezioni cliente. Separa nettamente la parte cliente dal changelog tecnico con una linea orizzontale.

## Vincoli & regole
Riscrivi ogni voce tecnica in beneficio per l'utente nella parte cliente; escludi dalla parte cliente le voci puramente interne (refactor, bump dipendenze, test) ma mantienile nel changelog tecnico. Non inventare percentuali o numeri di miglioramento: se non forniti, usa '[X]%' come segnaposto. Metti sempre breaking change e azioni richieste in cima. Massimo 700 parole nella parte cliente.

Grok · xAI

## Ruolo
Agisci come un Product Manager che cura la comunicazione di rilascio, capace di tradurre modifiche tecniche in valore percepito dal cliente senza perdere precisione tecnica.

## Obiettivo
Trasforma l'elenco grezzo di modifiche fornito in un documento di release notes a due livelli: (1) una parte rivolta al cliente con sintesi 'In breve', azioni richieste, Novità, Miglioramenti, Correzioni in linguaggio orientato al beneficio; (2) un changelog tecnico in tabella ordinato per tipo (feat/fix/perf/breaking) con componente, descrizione e riferimento al ticket.

## Contesto
Versione: [X.Y.Z]. Data: [data]. Prodotto: [nome]. Pubblico cliente: [tipo utente]. Tono desiderato per il cliente: [sobrio/friendly/enterprise]. Elenco grezzo modifiche (commit/ticket): [incolla qui le voci]. Breaking change o azioni richieste note: [eventuali].

## Formato output
Documento Word: H1 con versione e data; H2 per ogni sezione; tabella per 'Azioni richieste' e per il 'Changelog tecnico'; elenchi puntati con la parte in grassetto del beneficio nelle sezioni cliente. Separa nettamente la parte cliente dal changelog tecnico con una linea orizzontale.

## Vincoli & regole
Riscrivi ogni voce tecnica in beneficio per l'utente nella parte cliente; escludi dalla parte cliente le voci puramente interne (refactor, bump dipendenze, test) ma mantienile nel changelog tecnico. Non inventare percentuali o numeri di miglioramento: se non forniti, usa '[X]%' come segnaposto. Metti sempre breaking change e azioni richieste in cima. Massimo 700 parole nella parte cliente.

## Tono & stile
Parte cliente: chiara e orientata al beneficio, nel tono indicato. Changelog tecnico: fattuale, neutro, conciso.

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

Mistral · Mistral AI

## Ruolo
Agisci come un Product Manager che cura la comunicazione di rilascio, capace di tradurre modifiche tecniche in valore percepito dal cliente senza perdere precisione tecnica.

## Obiettivo
Trasforma l'elenco grezzo di modifiche fornito in un documento di release notes a due livelli: (1) una parte rivolta al cliente con sintesi 'In breve', azioni richieste, Novità, Miglioramenti, Correzioni in linguaggio orientato al beneficio; (2) un changelog tecnico in tabella ordinato per tipo (feat/fix/perf/breaking) con componente, descrizione e riferimento al ticket.

## Contesto
Versione: [X.Y.Z]. Data: [data]. Prodotto: [nome]. Pubblico cliente: [tipo utente]. Tono desiderato per il cliente: [sobrio/friendly/enterprise]. Elenco grezzo modifiche (commit/ticket): [incolla qui le voci]. Breaking change o azioni richieste note: [eventuali].

## Formato output
Documento Word: H1 con versione e data; H2 per ogni sezione; tabella per 'Azioni richieste' e per il 'Changelog tecnico'; elenchi puntati con la parte in grassetto del beneficio nelle sezioni cliente. Separa nettamente la parte cliente dal changelog tecnico con una linea orizzontale.

## Vincoli & regole
Riscrivi ogni voce tecnica in beneficio per l'utente nella parte cliente; escludi dalla parte cliente le voci puramente interne (refactor, bump dipendenze, test) ma mantienile nel changelog tecnico. Non inventare percentuali o numeri di miglioramento: se non forniti, usa '[X]%' come segnaposto. Metti sempre breaking change e azioni richieste in cima. Massimo 700 parole nella parte cliente.

## Tono & stile
Parte cliente: chiara e orientata al beneficio, nel tono indicato. Changelog tecnico: fattuale, neutro, conciso.

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

ChatGPT · OpenAI

## Ruolo
Agisci come un Product Manager che cura la comunicazione di rilascio, capace di tradurre modifiche tecniche in valore percepito dal cliente senza perdere precisione tecnica.

## Obiettivo
Trasforma l'elenco grezzo di modifiche fornito in un documento di release notes a due livelli: (1) una parte rivolta al cliente con sintesi 'In breve', azioni richieste, Novità, Miglioramenti, Correzioni in linguaggio orientato al beneficio; (2) un changelog tecnico in tabella ordinato per tipo (feat/fix/perf/breaking) con componente, descrizione e riferimento al ticket.

## Contesto
Versione: [X.Y.Z]. Data: [data]. Prodotto: [nome]. Pubblico cliente: [tipo utente]. Tono desiderato per il cliente: [sobrio/friendly/enterprise]. Elenco grezzo modifiche (commit/ticket): [incolla qui le voci]. Breaking change o azioni richieste note: [eventuali].

## Formato output
Documento Word: H1 con versione e data; H2 per ogni sezione; tabella per 'Azioni richieste' e per il 'Changelog tecnico'; elenchi puntati con la parte in grassetto del beneficio nelle sezioni cliente. Separa nettamente la parte cliente dal changelog tecnico con una linea orizzontale.

## Vincoli & regole
Riscrivi ogni voce tecnica in beneficio per l'utente nella parte cliente; escludi dalla parte cliente le voci puramente interne (refactor, bump dipendenze, test) ma mantienile nel changelog tecnico. Non inventare percentuali o numeri di miglioramento: se non forniti, usa '[X]%' come segnaposto. Metti sempre breaking change e azioni richieste in cima. Massimo 700 parole nella parte cliente.

## Tono & stile
Parte cliente: chiara e orientata al beneficio, nel tono indicato. Changelog tecnico: fattuale, neutro, conciso.

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

Perplexity · Perplexity

Trasforma l'elenco grezzo di modifiche fornito in un documento di release notes a due livelli: (1) una parte rivolta al cliente con sintesi 'In breve', azioni richieste, Novità, Miglioramenti, Correzioni in linguaggio orientato al beneficio; (2) un changelog tecnico in tabella ordinato per tipo (feat/fix/perf/breaking) con componente, descrizione e riferimento al ticket.
Ruolo: Agisci come un Product Manager che cura la comunicazione di rilascio, capace di tradurre modifiche tecniche in valore percepito dal cliente senza perdere precisione tecnica.
Contesto: Versione: [X.Y.Z]. Data: [data]. Prodotto: [nome]. Pubblico cliente: [tipo utente]. Tono desiderato per il cliente: [sobrio/friendly/enterprise]. Elenco grezzo modifiche (commit/ticket): [incolla qui le voci]. Breaking change o azioni richieste note: [eventuali].
Formato output: Documento Word: H1 con versione e data; H2 per ogni sezione; tabella per 'Azioni richieste' e per il 'Changelog tecnico'; elenchi puntati con la parte in grassetto del beneficio nelle sezioni cliente. Separa nettamente la parte cliente dal changelog tecnico con una linea orizzontale.
Vincoli & regole: Riscrivi ogni voce tecnica in beneficio per l'utente nella parte cliente; escludi dalla parte cliente le voci puramente interne (refactor, bump dipendenze, test) ma mantienile nel changelog tecnico. Non inventare percentuali o numeri di miglioramento: se non forniti, usa '[X]%' come segnaposto. Metti sempre breaking change e azioni richieste in cima. Massimo 700 parole nella parte cliente.
Tono & stile: Parte cliente: chiara e orientata al beneficio, nel tono indicato. Changelog tecnico: fattuale, neutro, conciso.

Esempio di output

# Note di rilascio — v[X.Y.Z] · [data]

## In breve
Questa versione introduce l'esportazione dei report in PDF, velocizza il caricamento della dashboard e corregge alcuni problemi segnalati.

## ⚠️ Azioni richieste
| Cambiamento | Impatto | Cosa fare |
|---|---|---|
| Le API v1 vengono dismesse | Integrazioni esistenti | Migrare a v2 entro [data] |

## Novità per te
- **Esporta i report in PDF**: ora puoi scaricare qualsiasi report con un clic.
- **Dashboard più veloce**: i grafici si caricano fino al [X]% più rapidamente.

## Miglioramenti
- Filtri della tabella ora memorizzati tra le sessioni.
- Migliorata la leggibilità su schermi piccoli.

## Correzioni
- Risolto un errore nell'invio delle notifiche email.
- Corretto un disallineamento dei totali in alcuni report.

---

## Changelog tecnico
| Tipo | Componente | Descrizione | Rif. |
|---|---|---|---|
| feat | export-service | Generazione PDF report | TICKET-101 |
| perf | dashboard | Lazy-load dei widget | TICKET-104 |
| fix | mailer | Retry su invio fallito | TICKET-110 |
| breaking | api | Deprecazione endpoint v1 | TICKET-098 |

Domande frequenti

Posso dargli in pasto direttamente la lista dei commit git?

Sì. Incolli i commit o i titoli dei ticket grezzi e il prompt li riscrive in linguaggio orientato al valore per il cliente, raggruppandoli per categoria (Novità, Miglioramenti, Correzioni). Filtra automaticamente le voci puramente interne (refactor, bump di dipendenze) dal livello cliente.

Come gestisce i breaking change?

I breaking change e le azioni richieste all'utente finiscono in una sezione dedicata e in evidenza all'inizio del documento, con indicazione di cosa fare. Non vengono mai nascosti tra i miglioramenti minori, perché sono l'informazione a più alto rischio per il lettore.

Posso scegliere il tono della comunicazione al cliente?

Sì, indichi il tono nel contesto (es. sobrio enterprise, friendly consumer) e il prompt adatta solo la sezione rivolta al cliente. Il changelog tecnico resta sempre fattuale e neutro, perché è destinato a un pubblico tecnico.

Vuoi un prompt su misura?

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

Crea il tuo prompt