Note sulla costruzione di un prodotto silenzioso

Mole for Mac ha superato un piccolo traguardo di vendite circa tre settimane dopo il lancio. Invece di scrivere dei numeri, voglio fissare alcune scelte fatte lungo il percorso, perché la maggior parte va contro gli istinti di un ingegnere al lavoro, e sono le scelte che difenderei per prime. Se stai costruendo il tuo prodotto, forse qualcosa di questo ti risparmia una deviazione.

Rispondo a ogni email di persona

Ogni richiesta di supporto dal lancio è stata gestita a mano: rimborsi, reset di attivazione, rimborso della differenza di prezzo dopo uno sconto, domande ordinarie. Il volume è basso, ben sotto l’uno per cento degli utenti scrive, e avrei potuto collegare un agente per gestirlo in mezz’ora. Ho scelto di non farlo, per due motivi.

Primo, il supporto è dove il prodotto ti dice la verità. Una richiesta di rimborso ti dice perché il prodotto ha deluso qualcuno. Una domanda scomoda ti dice quale parte dell’app non sa spiegarsi da sola. Qualche email avanti e indietro fa emergere cosa l’utente voleva davvero, che spesso non è la cosa che ha chiesto per prima. Filtrare tutto questo con l’automazione dal giorno uno significa perdere il segnale proprio quando ne hai più bisogno.

Secondo, gestire ogni caso ti rende fluente. Dopo abbastanza giri conosci la risposta migliore per ogni classe di problema, e sai quali problemi il prodotto dovrebbe assorbire così che la domanda non venga più posta. Quando il volume crescerà e introdurrò l’automazione, codificherà quella fluidità invece di congetture.

La mia soglia per l’automazione non è un conteggio di ticket. Voglio che la domanda si ripeta, che la risposta resti stabile e che le eccezioni siano comprese. Fino ad allora, la conversazione disordinata è la ricerca. Dopo quel punto, l’automazione può gestire il percorso noto lasciando facile a un caso insolito raggiungere una persona.

Finora l’approccio regge: non ho speso nulla in marketing, la crescita è passaparola, e il tasso di rimborso è sotto lo 0,8 per cento.

L’impalcatura può aspettare

La stessa logica vale per l’infrastruttura. Non ho impostato un sistema di ticket, un help desk o una knowledge base prima del lancio. Gli ingegneri amano costruire prima il macchinario di supporto perché è la parte che sanno costruire, e l’IA lo ha reso un lavoro di mezza giornata, il che lo rende più allettante e altrettanto facile da ottimizzare prematuramente. La mezza giornata è reale; lo è anche il costo continuo di curare un sistema di cui non avevi ancora bisogno. Aggiungerei il sistema quando l’assenza inizia a perdere richieste, a nascondere i tempi di risposta o a rendere incoerente la stessa risposta. Prima di allora, la casella di posta è più semplice e più informativa.

Decidere cosa non costruire

La differenza tra un buon prodotto e uno mediocre sta soprattutto nelle cose che rifiuta di fare. Quali funzioni appartengono a quale release, quali richieste sono bisogni reali e quali lo sembrano soltanto, quali idee davvero buone non appartengono comunque a questo prodotto. Mi sono scusato con utenti che hanno proposto funzioni buone di per sé, perché un Mac ha tanti trucchi piacevoli che Mole non dovrebbe eseguire. Dire sì a tutto produce uno stufato, e uno stufato è difficile da mantenere e ancora più difficile da fidarsi quando si tratta di eliminare file.

Tengo in testa circa mezzo anno del percorso del prodotto: cosa aggiunge ogni versione, cosa resta fuori, e dove le cose finiscono così che un utente alla prima volta le trovi senza istruzioni. Se il primo compito comune richiede un manuale, l’interfaccia ha fallito le persone che voglio raggiungere di più. La documentazione conta ancora per la profondità, i casi limite e la fiducia, ma non dovrebbe salvare la forma di base del prodotto. Il vecchio rasoio lo dice meglio: non aggiungere un’entità se non è necessaria.

Ora uso tre veti prima che una funzione arrivi alla roadmap. Non deve aggiungere un timer, un listener o un costo di campionamento sempre attivi a meno che l’utente non sia entrato nella funzione. Non deve allargare l’helper privilegiato o chiedere un nuovo permesso solo per rendere possibile una piccola comodità. E non deve aggiungere un’impostazione quando un default calmo può prendere la decisione per tutti. Non sono regole universali del software. Sono un budget per questo prodotto: lavoro residente, privilegi e configurazione sono tutti forme di superficie che gli utenti devono fidarsi per sempre.

La posizione

La posizione di Mole è una frase: un custode silenzioso per il tuo Mac. Pulisce, disinstalla, ottimizza, analizza e osserva, e per il resto resta fuori dai piedi. L’ambizione è semplice da enunciare: se uno su cento utenti Mac tiene Mole con sé, sarà diventato davvero utile. Di recente alcuni utenti con disabilità visive hanno iniziato a usarlo e hanno incontrato asperità, così le correzioni di accessibilità sono passate davanti alle nuove funzioni. Non vedo l’ora di capire come l’app si senta per loro; un custode silenzioso dovrebbe essere silenzioso per tutti.

Tenere i prodotti umani nell’era dell’IA

L’IA ha reso possibile gran parte di questo prodotto. Non ha sostituito il parlare con le persone che lo usano, e non penso che dovrebbe. L’efficienza è facile da comprare ora; il sentimento e la fiducia tra uno sviluppatore e i suoi utenti vanno ancora guadagnati una conversazione alla volta. Forse è così che i prodotti costruiti con l’IA conservano il loro calore umano: il codice può essere generato, la relazione no.

Questo è il mio primo prodotto a pagamento, e alcune di queste scelte potrebbero rivelarsi sbagliate. Se hai percorso questa strada più a lungo di me e mi vedi fare qualcosa di sciocco, mi piacerebbe saperlo. Come Mole sia arrivato fin qui è una storia più lunga, raccontata in Da uno script shell di 500 righe a un’app per Mac.