Come leggiamo la prima ondata di feedback

Quando il sito di uno studio viene pubblicato online, iniziano ad arrivare email di un certo tipo. Non si tratta di segnalazioni di bug relative a un’app specifica — per quelle c’è un canale dedicato —, ma di feedback più generici e vaghi. Vorrei un'app che faccia X. Avete considerato Y? I vostri prezzi sono troppo bassi / troppo alti / poco chiari. Tutto è un dono. La maggior parte non può diventare prodotto.

Quest’ultima frase suona più severa di quanto vorremmo. Il problema non è la qualità dei suggerimenti; molti di essi sono validi. Il fatto è che uno studio di piccole dimensioni può realizzare solo poche cose alla volta, e ogni “sì” equivale a un “no” per qualcos’altro. Quindi il vero lavoro consiste nel decidere quali idee meritino di trovare spazio.

Cosa ne facciamo

Leggilo. Contrassegnalo. Ordinalo. I suggerimenti vengono inseriti in un documento condiviso che rileggiamo alla fine di ogni trimestre, non ogni settimana: gli schemi significativi diventano visibili solo quando ce ne sono abbastanza da individuare una tendenza.

Le etichette sono semplici: di quale app si tratta (o “studio” se non ce n’è una), che tipo di richiesta è e una parafrasi di una riga con parole nostre. La parafrasi è importante. Scrivere ciò che pensiamo sia realmente necessario per la persona, piuttosto che la soluzione da lei proposta, è spesso il punto in cui emerge l’intuizione utile. Chi chiede l’esportazione del calendario in un’app per l’organizzazione di matrimoni potrebbe in realtà dirci che condivide la pianificazione con qualcuno che non utilizza l’app.

Rispondiamo a tutti, anche se la risposta è breve. Un breve ringraziamento accompagnato da una nota sincera — “lo abbiamo messo in lista” oppure “probabilmente non è qualcosa che realizzeremo, ed ecco perché” — è meglio del silenzio e meglio di una promessa che non possiamo mantenere.

Cosa non facciamo

Realizzate subito la funzionalità più richiesta. La funzionalità più richiesta è quasi sempre un segno di ciò di cui gli utenti sono più consapevoli di aver bisogno, non di ciò che migliorerebbe maggiormente il prodotto. I miglioramenti più profondi di solito provengono dalla seconda o terza e-mail, quella che dice funziona ma è sbagliato perché...

È più difficile dare seguito a quelle e-mail, perché raramente contengono una soluzione concreta. Qualcuno ci dice che una schermata sembra troppo affollata, oppure che ha smesso di usare una funzione senza sapere bene perché. Presa singolarmente, ogni segnalazione è vaga. Ma se ne raccogliamo diverse che puntano tutte allo stesso aspetto di un’app, spesso rappresentano l’elemento più prezioso dell’intera cartella.

Inoltre, non consideriamo le richieste di nuove app come una semplice lista di cose da fare. Un’idea per un prodotto completamente nuovo viene valutata con la stessa attenzione che riserviamo a tutto il resto nel corso del trimestre, e la maggior parte di esse rimane solo un’idea. Quelle che vanno avanti si adattano al nostro modo di lavorare: uno strumento mirato, utile di per sé, che vorremmo usare noi stessi.

Cosa abbiamo sbagliato

Nelle prime settimane, il nostro istinto era quello di rispondere ai feedback man mano che arrivavano: una soluzione rapida qui, una piccola modifica là. Ci sembrava un approccio attento. Ma significava anche che l’e-mail più insistente della settimana determinava le nostre priorità, e che un paio di modifiche apportate in fretta dovevano poi essere silenziosamente annullate. Aspettare l’analisi trimestrale richiede più tempo e a volte è frustrante, ma porta a decisioni migliori.

A un mese dall'inizio del progetto, ne abbiamo una cartella. Ci lavoreremo per tutta l'estate.