Come decidere quale feedback degli utenti realizzare (e quale lasciar perdere)

Le prime settimane dopo che le persone iniziano a usare la tua app sono tranquille. Poi cominciano i messaggi. “Potresti aggiungere una modalità scura?” “Sarebbe fantastico se potessi esportare in PDF.” “Puoi fare il pulsante blu?” “Abbiamo davvero bisogno delle integrazioni con lo strumento che già usiamo.” Nel giro di un mese hai una lista di quaranta cose, e un creatore di app con IA che te ne costruirà volentieri una qualsiasi in un pomeriggio.

Quest’ultima parte è la trappola. Quando costruire ogni funzionalità è economico e veloce, la domanda difficile smette di essere “posso costruirla?” e diventa “dovrei?” Il collo di bottiglia si sposta dalle tue mani al tuo giudizio, e nessuno ti consegna una guida per quello.

Questo articolo è un modo semplice per smistare il feedback in arrivo in tre mucchi — realizzarlo, metterlo in pausa, lasciarlo andare — senza bisogno di un background da product manager. L’obiettivo non è dire di no alle persone. È assicurarsi che le cose che realizzi siano le cose che fanno davvero progredire la tua app.

Perché “basta costruirlo” smette di funzionare

Per le tue prime dieci funzionalità, “costruisci semplicemente qualunque cosa qualcuno chieda” è una strategia perfetta. Non hai abbastanza utenti per avere opinioni in conflitto, e ogni funzionalità rende l’app più utile della cosa vuota che era la settimana prima.

Smette di funzionare più o meno quando hai utenti veri e diversi tra loro. Un freelance vuole una cosa, una piccola agenzia vuole l’opposto, e un visitatore di passaggio vuole qualcosa che nessuno dei due userà mai. Costruiscile tutte e tre e la tua app si trasforma in un cassetto del disordine — pieno di roba, difficile trovare qualcosa, pesante da portare. Ogni funzionalità che aggiungi è una funzionalità che dovrai mantenere funzionante per sempre, spiegare ai nuovi utenti e non rompere quando cambi qualcosa lì vicino.

Un creatore di app con IA peggiora la cosa prima di migliorarla, perché toglie il freno naturale. Quando una funzionalità richiedeva due settimane a uno sviluppatore, riflettevi bene se valesse due settimane. Quando ci vogliono venti minuti al creatore, non rifletti affatto — dici semplicemente di sì. Il costo non è sparito. Si è spostato da “tempo per costruire” a “peso da portare”, e il peso è più difficile da vedere.

Tre domande che smistano quasi tutto

Quando arriva una richiesta, passala attraverso tre domande in ordine. La maggior parte delle cose si smista da sola dopo le prime due.

1. Aiuta le persone per cui ho costruito questa app? Hai costruito la tua app per qualcuno di preciso — fotografi di matrimoni, allenatori di calcio giovanile, conduttori di podcast indipendenti. Una richiesta da una di queste persone vale più di una richiesta da qualcuno che è capitato lì e non tornerà mai. Se una funzionalità aiuta le tue persone di riferimento a fare la cosa principale per cui sono venute, va in cima. Se aiuta un visitatore che non è davvero un tuo utente, va in fondo, per quanto a voce alta l’abbia chiesta.

2. Quante persone la useranno davvero? Non “chi l’ha chiesta” — chi la userà. Una persona che chiede a voce alta non è la stessa cosa di dieci persone che ne trarrebbero beneficio in silenzio. Sii onesto qui, perché le richieste a voce alta sembrano richieste importanti, e di solito non lo sono. Un buon indizio: chiedi alla persona cosa fa oggi al posto di quella cosa. Se ha un rimedio scomodo che usa ogni giorno, è un bisogno reale. Se “probabilmente la userebbe a volte”, è un “bello da avere” travestito.

3. Quanto mi costa portarla per sempre? Alcune funzionalità sono leggere. Una nuova opzione di colore, un’etichetta riformulata, un campo in più su un modulo — costruiscila e dimenticatene. Alcune funzionalità sono pesanti: tutto ciò che tocca i pagamenti, tutto ciò che invia email a persone reali, tutto ciò che aggiunge un’intera nuova sezione con regole proprie. Le funzionalità pesanti non sono cattive, ma devono guadagnarsi il loro peso superando le prime due domande con ampio margine.

I tre mucchi

Fai queste domande e quasi tutto finisce in uno di tre posti.

Realizzala. Aiuta le tue persone di riferimento, parecchie di loro la useranno e il costo per portarla è ragionevole. Queste sono facili. Falle, e dillo a chi l’ha chiesta — le persone che vedono la loro idea realizzata diventano i tuoi utenti più fedeli e la tua miglior fonte della prossima buona idea.

Mettila in pausa. Buona idea, ma è presto, o la vuole una persona sola, oppure è pesante e non sei ancora sicuro. Non dire di no e non costruirla. Scrivila da qualche parte dove la guarderai davvero — una lista semplice, una nota, una bacheca. Se altre tre persone chiedono la stessa cosa nel mese successivo, si è appena promossa da sola al mucchio “realizzala” e te lo ha detto. La pausa non è un cimitero; è una sala d’attesa.

Lasciala andare. Non si adatta a ciò per cui è fatta la tua app, servirebbe sempre e solo a una persona, oppure renderebbe l’app peggiore per tutti gli altri. Queste hanno bisogno di un no gentile e onesto. “È un’idea ben pensata, ma non è qualcosa che ho intenzione di aggiungere — ecco cosa ti suggerirei invece” preserva il rapporto e protegge l’app. Dire di no è una funzionalità. Ogni no è un sì al mantenere l’app abbastanza semplice perché le persone la capiscano.

Un piccolo esempio

Una persona che conosciamo gestisce un’app di prenotazioni per insegnanti di musica, costruita interamente con un creatore di app con IA. In una settimana ha ricevuto tre richieste: un’insegnante voleva messaggi di promemoria automatici agli studenti, un genitore voleva un modo per vedere tutte le lezioni dei propri figli in un’unica vista, e una persona voleva l’app tradotta in latino “per divertimento”.

I promemoria hanno superato tutte e tre le domande — utenti di riferimento, molti di loro hanno a che fare con i mancati appuntamenti, e i messaggi sono pesanti ma ne vale la pena. Realizzati. La vista per i genitori era una buona idea da parte di una persona sola, quindi l’ha messa in pausa; altri due genitori l’hanno chiesta nel giro di tre settimane e si è promossa da sola. La traduzione in latino ha ricevuto un caloroso no. Nessuna di quelle decisioni ha richiesto un foglio di calcolo. Hanno richiesto tre domande e la disponibilità a rispondere onestamente alla terza.

La parte che nessuno ti dice

Il feedback più difficile da gestire non sono le cattive idee. Sono le buone idee da parte di persone che ti stanno simpatiche, per un’app che non può essere tutto. Lasciarle andare sembra deludere la persona. Non è così. La cosa più gentile che puoi fare per le persone che usano la tua app è tenerla abbastanza focalizzata da restare brava nell’unica cosa per cui sono venute.

La prossima volta che le richieste si accumulano, non aprire prima il tuo creatore di app con IA. Apri la tua lista, fai passare ogni voce attraverso le tre domande e smistala in un mucchio. Costruire adesso è la parte facile. Decidere cosa vale la pena costruire è il vero lavoro — ed è un lavoro che puoi fare senza scrivere una sola riga di codice.