La richiesta di funzionalità che dovresti davvero realizzare (e come riconoscerla)

Sai dire di no alle richieste di funzionalità sbagliate. Hai imparato a distinguere il proliferare del progetto dalle funzionalità centrali. Stai proteggendo i confini del tuo prodotto.

Ma ora sei in un pasticcio diverso: hai una dozzina di richieste che superano tutte il test. Sono tutte per la tua app. Sono tutte ragionevoli. Sono tutte cose che i tuoi utenti vogliono davvero. Ma puoi realizzarne solo tre.

Quali tre?

È qui che la maggior parte delle decisioni di prodotto va storta. I founder scelgono quelle che suonano più impressionanti, o più redditizie, o quelle arrivate dal loro cliente più importante. A volte hanno ragione. Di solito hanno torto.

I segnali che contano

Segnale 1: la ripetizione spontanea

Se tre utenti separati chiedono la stessa cosa senza parlarsi tra loro, quello è un segnale. Non si sono coordinati. Ci hanno pensato tutti per conto loro. Se cinque utenti la chiedono, non è una coincidenza — è un bisogno reale.

L’inverso è importante: se un utente la chiede e nessun altro lo fa, e tu la realizzi, ora hai mantenuto una funzionalità che nessun altro usa e di cui quell’utente potrebbe comunque non essere contento (perché l’hai realizzata leggermente storta).

Conta le richieste prima di realizzare qualcosa. Non quelle dal cliente più rumoroso o dal tuo cliente più grosso — conta la ripetizione spontanea. Due o tre utenti indipendenti che chiedono la stessa cosa sono un segnale molto più forte di un cliente importante che chiede cinque cose.

Segnale 2: l’aggiramento conta

Se hai degli utenti e restano anche se la funzionalità manca, hanno trovato un modo per aggirarla. Forse lo fanno fuori dalla tua app. Forse lo fanno a mano. Forse usano un altro strumento in parallelo.

Ma restano, il che significa che non hanno bisogno della funzionalità per usare la tua app. Ne hanno bisogno per usare la tua app meglio. È diverso da un blocco.

Le funzionalità che contano di più sono quelle che impediscono del tutto alle persone di usare la tua app. Le funzionalità che è bello avere sono quelle che le persone aggirano.

Fai attenzione a quali richieste sono dei blocchi. Qualcuno che dice “non posso usarlo finché non fai X” è diverso da qualcuno che dice “sarebbe fantastico se aveste X”. Quella distinzione è oro.

Segnale 3: la funzionalità si lega al modello di business

Alcune funzionalità sbloccano modi completamente nuovi di fare soldi. “Fattura i miei clienti” sblocca un modello di business in cui fai pagare per la fatturazione. “Esporta su Salesforce” sblocca ricavi da integrazione. “White-label per i rivenditori” sblocca un canale partner.

Ma ecco il trucco: non sai se quei modelli funzioneranno finché non stai già pubblicando. Non puoi pianificarci attorno. Puoi solo notarli dopo aver pubblicato e visto se le persone li usano davvero.

Le aggiunte di funzionalità di maggior successo sono quelle in cui pubblicare la funzionalità rivela un mercato che non sapevi esistesse. Hai realizzato l’esportazione. Si scopre che le aziende vogliono integrare la tua esportazione nel loro flusso di lavoro. Ora hai una storia di integrazione che non avevi pianificato.

Realizza le funzionalità perché i tuoi utenti ne hanno bisogno. Poi osserva se i tuoi utenti ne hanno bisogno in un modo che crea nuovo business. Non prevedere il modello di business per primo.

Segnale 4: la richiesta di aiuto

Se un utente ti chiede di realizzare qualcosa, quella è una richiesta. Se un utente chiede se potresti realizzare qualcosa e si offre di aiutarti a testarla, è un’altra cosa.

Le persone che si offrono di aiutare a testare sono persone investite nel risultato. Useranno la funzionalità con attenzione. Segnaleranno i bug. Ti diranno se risolve davvero il loro problema.

Le persone che si limitano a fare richieste sono persone che sperano tu realizzi magicamente quello che hanno in mente. A volte ci riuscirai. Spesso no.

Costruisci prima con chi testa. Tutto il resto è secondario.

La tentazione di realizzare la funzionalità di prestigio

Ogni prodotto ha una funzionalità che, se la pubblichi, ti fa suonare più impressionante. Per le app di scheduling, è l’integrazione con Calendly. Per le app di task, è l’integrazione con Slack. Tutti sanno cosa sono. Tutti le vogliono.

Ecco il punto: tutti le stanno anche ottenendo da qualcun altro. Se la tua funzionalità non è la migliore, la più semplice integrazione con Slack, aggiunge solo complessità alla tua app senza renderti famoso.

Le funzionalità che ti rendono famoso sono quelle che sei nella posizione unica di poter realizzare perché capisci i problemi dei tuoi utenti specifici meglio di chiunque altro. Non sono le funzionalità di prestigio. Sono le funzionalità noiose che risolvono problemi reali per persone reali.

L’integrazione con Slack è impressionante. Uno strumento che permette ai tuoi utenti di fare una cosa specifica molto più velocemente di quanto Slack abbia mai pensato di fare è prezioso.

Come decidere davvero

Quando hai un gruppo di richieste di funzionalità che superano tutte il test “rientra nel progetto?”, ordinale per:

1. Quanti utenti l’hanno chiesta (in modo indipendente)? Di più è meglio.
2. È un blocco o un bello-da-avere? I blocchi sono più urgenti.
3. I tuoi utenti possono aggirarla oggi? Se no, è più importante.
4. Qualcuno ti aiuterà a testarla? Se sì, realizzala per prima.
5. Rivelerà un nuovo mercato? Se forse, è un bonus, non un motivo.

Poi realizza in quell’ordine. Non nell’ordine di ciò che suona impressionante. Non nell’ordine del tuo cliente più grosso. Nell’ordine del segnale reale che arriva dalle persone che usano la tua app.

La funzionalità che non realizzerai (per ora)

Avrai richieste che non passano la selezione. Non far finta che le realizzerai un giorno. Di’ all’utente: “Non realizzeremo quella cosa adesso. Ecco perché. Ecco cosa stiamo realizzando. Ecco un’alternativa che potrebbe funzionare per te.”

Quell’onestà conta più di quanto pensi. Gli utenti preferiscono sapere che non lo farai piuttosto che aspettare sei mesi sperando.

E a volte, una volta che hai detto di no, l’utente trova un modo per aggirarla, o uno strumento diverso, o risolve il problema in un altro modo. Va bene così. Non puoi essere tutto per tutti.

I prodotti che vincono sono quelli che fanno bene il loro lavoro e ascoltano con attenzione ciò di cui gli utenti hanno davvero bisogno, non quelli che cercano di essere tutto e finiscono per non essere niente.