Il brief dell'MVP è la tua prima decisione di prodotto

I fondatori arrivano spesso con un brief che in realtà è una descrizione dell'idea: qualche paragrafo sul mercato, un elenco di funzionalità e una frase su dove il prodotto potrebbe arrivare un giorno. Basta per avviare una conversazione, ma non per pubblicare. Un team di sviluppo ha bisogno di un documento più piccolo e più nitido, che trasformi l'ambizione in una sequenza di scelte verificabili.

Un brief utile svolge tre compiti

1. Identifica la persona che ha il problema

“Piccole imprese” è un mercato, non un primo utente. Un buon brief identifica la persona, il momento in cui si trova e l'espediente che usa oggi. Un responsabile di clinica che cerca di riempire le cancellazioni di domani ha un problema diverso da un paziente che cerca un nuovo appuntamento, anche se entrambi appartengono alla sanità. Più è specifico il primo utente, più è facile decidere cosa debba fare il prodotto dopo.

2. Traccia una linea attorno alla versione uno

Un elenco di funzionalità dice ciò che è stato immaginato. Un confine di ambito dice ciò che verrà costruito. Scrivi il ciclo fondamentale in una frase, poi elenca il lavoro che lo rende affidabile: la schermata principale, l'unica azione significativa, i dati che la sostengono e il feedback che dice all'utente che ha funzionato. Tutto il resto è un candidato per dopo, non un requisito silenzioso per il lancio.

3. Definisce la prova successiva

“Lanciare e vedere cosa succede” non è un piano di apprendimento. Decidi cosa ti aspetti di osservare nelle prime settimane: un flusso completato, un'azione ripetuta, una conversione a pagamento o un'intervista condotta dal fondatore con uno specifico tipo di utente. La misura non deve essere sofisticata; deve essere abbastanza vicina al comportamento dell'utente da poter cambiare la prossima decisione di prodotto.

Cosa annotare prima di una schermata

• Il primo utente: un ruolo, una situazione e un espediente doloroso
• Il ciclo fondamentale: la più piccola azione che crea valore e può ripetersi
• Il confine di lancio: ciò che è esplicitamente fuori ambito per la versione uno
• Il requisito di fiducia: ciò che l'utente deve vedere, controllare o capire prima di agire
• Il prossimo punto di prova: il comportamento o la conversazione che merita un altro ciclo di sviluppo

Il test dell'ambito che uso

Prendi ogni funzionalità proposta e fai una domanda: rende più probabile il successo del ciclo fondamentale per il primo utente? Se la risposta è no, spostala fuori dalla prima release. Se è forse, annota l'ipotesi che sta proteggendo e trova un modo più economico per testarla. Questo impedisce a una funzionalità utile di diventare una scusa permanente per ritardare il prodotto.

Lo scopo di un brief non è raccogliere tutto ciò che potresti costruire. È rendere evidente la prossima decisione di sviluppo.

una regola che uso negli avvii di prodotto

Come lo uso in Sirajov

Prima di quotare una realizzazione, trasformo l'idea del fondatore in un ambito di una pagina: un utente, un ciclo fondamentale, le schermate e l'infrastruttura che lo supportano e l'evidenza che dovrebbe cambiare la decisione successiva. Il documento diventa il passaggio di consegne tra strategia, design, ingegneria e lancio, e il punto di riferimento quando una nuova funzionalità cerca di intrufolarsi nella versione uno.

Domande frequenti

Quanto deve essere lungo un brief MVP?

Abbastanza breve da leggerlo in una sola seduta e abbastanza specifico da prendere decisioni tra alternative. Una o due pagine sono di solito sufficienti quando identifica primo utente, ciclo fondamentale, confine di lancio, requisiti di fiducia e prossimo punto di prova.

Il brief deve includere un elenco completo delle funzionalità?

Includi le funzionalità che fanno funzionare il ciclo fondamentale, poi tieni il resto in una sezione di idee successive. Un parcheggio separato protegge le buone idee senza lasciare che diventino silenziosamente requisiti di lancio.

E se l'utente target è ancora incerto?

Annota i due candidati più forti e l'evidenza che li distinguerebbe. L'incertezza è utile quando è esplicita; diventa costosa quando è nascosta dentro un ampio ambito di prodotto.

Il brief deve essere finito prima che inizi il design?

Dovrebbe essere abbastanza chiaro da guidare il primo passaggio di design, non congelato per sempre. Il design può far emergere una domanda migliore, ma ogni cambiamento dovrebbe aggiornare l'ambito e la prova che stai cercando di raccogliere.