Per dare priorità alle richieste di funzionalità, raggruppale in base al problema che c’è dietro, dai a ogni problema un punteggio su portata, gravità, coerenza e sforzo, e parla con alcune delle persone che le hanno fatte prima di impegnarti. Quest’ultimo passaggio è quello che la maggior parte dei team salta, ed è il punto più economico per accorgersi di una scommessa sbagliata. Sviluppare la cosa sbagliata succede spesso: il report 2019 di Pendo sull’adozione delle funzionalità, basato su tre mesi di dati di utilizzo di 615 abbonamenti di clienti Pendo, ha rilevato che l’80 per cento delle funzionalità di un software medio è usato raramente o mai.
In sintesi
- Una richiesta di funzionalità è l’ipotesi di un cliente su una soluzione. Dai priorità al problema che c’è dietro.
- Il numero di voti mostra chi ha alzato la voce, non quanto fa male il problema.
- Scegli un framework semplice qualsiasi, ma alimentalo con quello che impari parlando con chi ha fatto la richiesta.
- Decidi, poi comunica alle persone cosa hai deciso, anche quando è un no.
Perché il numero di voti inganna
La maggior parte dei team tiene traccia delle richieste da qualche parte: una bacheca, un foglio di calcolo, un canale Slack. Poi sviluppa quella con più voti. Sembra equo, ma è rischioso.
- I clienti rumorosi vengono contati. Quelli silenziosi no. Chi pubblica richieste non è sempre il cliente che più ti preme tenere.
- Le richieste sono soluzioni, non problemi. “Aggiungete l’esportazione CSV” potrebbe voler dire “il mio responsabile vuole un report settimanale”. Un’email di riepilogo programmata potrebbe risolverlo meglio.
- I duplicati dividono i voti. Cinque richieste formulate in cinque modi diversi sembrano cinque piccoli problemi invece di uno grande.
- I voti non hanno peso. Una richiesta che terrebbe un grande cliente conta quanto un semplice “sarebbe carino”.
- I voti non scadono. Le vecchie richieste restano in cima molto dopo che il bisogno è sparito.
Un voto è un segnale per andare a chiedere. Non è la risposta.
I framework di prioritizzazione, in breve
In ogni guida trovi la stessa manciata di framework. Ecco a cosa serve ciascuno.
| Framework | Come funziona | Ideale per | Attenzione a |
|---|---|---|---|
| Numero di voti | Classifica per numero di richieste | Un primo segnale | Clienti rumorosi, duplicati divisi |
| RICE | Reach × Impact × Confidence ÷ Effort (portata, impatto, fiducia, sforzo) | Confrontare molte idee | La fiducia spesso è una supposizione |
| ICE | Impact × Confidence × Ease (impatto, fiducia, facilità) | Uno smistamento veloce | Molto soggettivo |
| MoSCoW | Must, Should, Could, Won’t (indispensabile, importante, facoltativo, escluso) | Una scadenza o un rilascio fisso | Nessun ordine dentro ogni gruppo |
| Impatto vs sforzo | Una semplice griglia 2×2 | Individuare i risultati rapidi | Ignora quante persone sono coinvolte |
| Kano | Funzionalità di base, di prestazione e che entusiasmano | Capire le aspettative | Serve un sondaggio per farlo bene |
| Ponderazione per fatturato | Pesa ogni voto in base al valore del cliente | B2B con pochi grandi clienti | Rischia di favorire troppo pochi grandi clienti |
RICE, descritto per la prima volta da Sean McBride di Intercom, è una scelta predefinita sensata per la maggior parte dei team di prodotto. Ma ogni framework ha lo stesso punto debole: portata, impatto e fiducia dipendono tutti da quanto bene capisci il problema. I passaggi qui sotto servono a fare bene proprio questa parte.
Passo 1: raccogli ogni richiesta in un unico posto
Le richieste arrivano da ticket di assistenza, chiamate commerciali, messaggi in app, email e recensioni. Mettile in un’unica lista per vederle una accanto all’altra.
Per ogni richiesta, annota:
| Campo | Esempio |
|---|---|
| Richiesta | Esportare i report in CSV |
| Chi l’ha chiesta | Responsabile operativo di un cliente di medie dimensioni |
| Le sue parole esatte | “Ogni lunedì copio i numeri in un foglio di calcolo per il mio capo.” |
| Piano o segmento | Piano Business, 40 licenze |
| Fonte e data | Ticket di assistenza, 3 marzo |
Le parole esatte sono la cosa più importante. Spesso mostrano il problema più chiaramente della richiesta stessa.
Non dimenticare le fonti silenziose. Le note sulle trattative perse e le risposte dei clienti che hanno disdetto contengono spesso richieste che non arrivano mai alla tua bacheca.
Passo 2: trova il problema dietro ogni richiesta
Riscrivi ogni richiesta come un problema, con una frase semplice:
Chi sta cercando di obiettivo, ma ostacolo.
Per l’esempio del CSV: “I team lead stanno cercando di condividere i numeri settimanali con il loro responsabile, ma devono copiarli a mano.”
Ora raggruppa le richieste che condividono un problema. Cinque richieste diverse (esportazione CSV, email programmate, un link pubblico alla dashboard, un pulsante PDF e un endpoint API) potrebbero essere tutte lo stesso problema. Insieme, è molto più grande di quanto sembrasse ogni singola richiesta.
È l’idea alla base dei jobs to be done: le persone non vogliono la funzionalità in sé. Vogliono il passo avanti che gli permette di fare.
Passo 3: parla con chi ha fatto la richiesta
Prima di dare qualsiasi punteggio, parla con alcune delle persone dietro i gruppi più grandi. Una breve conversazione ti dice più di una montagna di voti.
Chiedi della loro situazione reale, non della tua idea:
- “Cosa stavi cercando di fare quando l’hai chiesto?”
- “Come lo gestisci oggi?”
- “Ogni quanto ti capita?”
- “Cosa succede quando non viene fatto?”
- “Chi altro ne risente?”
Evita “Lo useresti se lo sviluppassimo?” Quasi tutti rispondono di sì, quindi non ti dice nulla. La nostra guida alle domande tendenziose ha altri esempi da evitare.
Com’è una buona conversazione
Tu: Cosa stavi cercando di fare quando hai chiesto l’esportazione CSV?
Cliente: Mettere i nostri numeri nel report del lunedì.
Tu: Chi legge quel report?
Cliente: La mia responsabile. Vuole solo tre numeri e l’andamento. Ogni settimana li copio nelle slide.
Tu: Quanto tempo ti porta via?
Cliente: Quasi un’ora, ogni lunedì.
La richiesta era “esportazione CSV”. Il bisogno è “mostrare alla mia responsabile tre numeri ogni settimana senza perdere tempo”. Un’email di riepilogo programmata potrebbe risolverlo in una frazione del tempo di sviluppo, e aiuterebbe ogni cliente con lo stesso rituale del lunedì.
Prove forti e prove deboli
| Segnale debole | Segnale forte |
|---|---|
| “Sarebbe carino averlo.” | “Ci passo un’ora ogni lunedì.” |
| “Certo, lo userei.” | “Paghiamo un altro strumento solo per fare questo.” |
| Un singolo voto | Una soluzione di ripiego che si sono costruiti da soli |
| “Lo vogliono tutti.” | Nomi, date e quanto gli è costato |
Quante conversazioni bastano
Continua a parlare finché non riesci a prevedere cosa dirà la persona successiva. Quando le storie iniziano a ripetersi, capisci il problema abbastanza bene da dargli un punteggio.
Se le storie continuano a cambiare, anche questo è un risultato. Una richiesta potrebbe nascondere diversi problemi, e dovresti dividere il gruppo. Per altre domande da fare, guarda le nostre domande per le interviste ai clienti.
Passo 4: dai un punteggio a ogni problema
Ora dai un punteggio ai problemi, non alle richieste. Tienilo semplice. Un punteggio che il team aggiorna davvero vale più di uno perfetto che nessuno tocca.
Valuta ogni problema da 1 a 3 su quattro aspetti:
- Portata: quanti dei clienti che ti interessano hanno questo problema.
- Gravità: quanto li fa soffrire, in base a quello che hai sentito.
- Coerenza: quanto risolverlo è in linea con la direzione del tuo prodotto.
- Sforzo: quanto lavoro richiede. Più alto significa più lavoro.
Poi calcola: Portata × Gravità × Coerenza ÷ Sforzo.
| Problema | Portata | Gravità | Coerenza | Sforzo | Punteggio |
|---|---|---|---|---|---|
| Condividere i numeri settimanali con i responsabili | 3 | 2 | 3 | 2 | 9 |
| Single sign-on per i team più grandi | 1 | 3 | 3 | 3 | 3 |
| Modalità scura | 2 | 1 | 1 | 2 | 1 |
Vince il problema della condivisione, anche se da sola la modalità scura aveva più voti. Le richieste sulla condivisione erano sparse su cinque idee di funzionalità diverse, quindi nessuna sembrava grande.
Pesa per fatturato, con cautela
Nel B2B è giusto dare più peso ai problemi che riguardano i clienti più grandi o in più rapida crescita. Solo non lasciare che la ponderazione per fatturato guidi la roadmap. Pochi grandi clienti possono spingerti verso funzionalità che non servono a nessun altro, e i nuovi segmenti che vuoi conquistare non generano ancora fatturato.
Quando chiede un grande cliente
A volte un cliente importante vuole qualcosa che nessun altro ha chiesto. La tentazione di dire subito di sì è forte.
Prima trova il problema dietro la richiesta, come per qualsiasi altra. Poi chiediti se i clienti più piccoli simili a lui incontreranno lo stesso problema crescendo. Se sì, potrebbe meritare un posto nella roadmap. Se riguarda solo quel cliente, trattalo come un accordo su misura con un prezzo e una tempistica chiari.
Lascia spazio alle tue scommesse
Le richieste dei clienti ti mostrano i problemi di oggi. Raramente ti mostrano dove sta andando il mercato. Decidi in anticipo quanta parte del tempo del team va ai problemi dei clienti, alle tue scommesse strategiche e a correzioni e manutenzione. Poi dai priorità alle richieste dentro la loro quota, così una bacheca affollata non si prende in silenzio tutta la roadmap.
Passo 5: decidi, poi chiudi il ciclo
Scegli il problema principale, scegli una soluzione e avvisa chi l’aveva chiesta. I clienti che ricevono una risposta continuano a dirti di cosa hanno bisogno. La nostra guida al ciclo del feedback dei clienti mostra come farne un’abitudine.
Dire di no fa parte del lavoro. Due modelli che puoi adattare:
Non ora
Ciao nome,
grazie per averci chiesto funzionalità. Non la svilupperemo in questo trimestre.
Prima ci concentriamo su altro problema, perché riguarda più clienti.
Hai detto che stai cercando di loro obiettivo. Nel frattempo, ecco come
lo gestiscono alcuni clienti: soluzione alternativa o articolo di aiuto.
Ho conservato la tua segnalazione con le tue parole esatte, e ti farò sapere se cambia qualcosa.
Non previsto
Ciao nome,
grazie per l’idea su funzionalità. Voglio essere sincero con te:
non è in linea con la direzione che stiamo dando a prodotto, quindi non prevediamo di svilupparla.
Per loro obiettivo, altro strumento o soluzione alternativa potrebbe essere più adatto.
Se le tue esigenze cambiano, mi farebbe comunque piacere saperlo.
Un ritmo semplice che tiene onesta la lista
Dare priorità una volta sola serve a poco. Una routine leggera sì.
| Ogni quanto | Cosa fare |
|---|---|
| Ogni settimana | Aggiungi le nuove richieste con le parole esatte, unisci i duplicati, collega ognuna a un problema |
| Ogni mese | Parla con tre-cinque persone dietro i gruppi di problemi più grandi |
| Ogni trimestre | Ricalcola i punteggi, scegli cosa viene dopo e comunica a chi ha fatto le richieste cosa hai deciso |
Venti minuti a settimana bastano per la maggior parte dei team. Sono le conversazioni mensili a tenere i punteggi legati ai clienti reali e non a chi ha scritto per ultimo.
Errori da evitare quando dai priorità alle richieste di funzionalità
- Sviluppare per il cliente più rumoroso. Prima verifica se altri condividono il problema.
- Dare il punteggio alle funzionalità invece che ai problemi. Spezzerai un grande problema in piccole richieste che sembrano tutte secondarie.
- Chiedere se le persone lo userebbero. Chiedi come affrontano il problema oggi.
- Non guardarsi mai indietro. Ricalcola i punteggi ogni trimestre. Le esigenze cambiano, e anche il tuo prodotto.
Come ti aiuta Diaform
Parlare con tutte le persone dietro una richiesta richiede tempo, e la maggior parte non prenoterà una chiamata. Con Diaform invece mandi un unico link. Un agente IA fa le tue domande a voce o per iscritto, approfondisce quando qualcuno dice “sarebbe carino averlo” e riassume ogni conversazione quando finisce.
Invia il link per email o mostralo dentro la tua app. Dal piano Pro in su, i link su invito possono portare con sé l’email o l’ID utente di ogni persona, così sai quale cliente ha detto cosa. Esporta le risposte in CSV e aggiungile al tuo foglio dei punteggi. Guarda come Diaform gestisce il feedback sul prodotto, oppure inizia una prova gratuita di 14 giorni.
