# Note sulla costruzione di un prodotto silenzioso

> Quando il supporto diretto è ricerca, quando l’automazione merita il suo posto e come la sobrietà tiene un prodotto piccolo comprensibile e affidabile.

Published: 2026-06-02 | Updated: 2026-08-08

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.

<figure class="blog-diagram">
  <img src="https://mole.fit/img/blog/quiet-product-loop.webp" width="1360" height="454" loading="lazy" alt="Un loop decisionale di prodotto in cui la conversazione diretta preserva il contesto utente finché un bisogno ricorrente supera i gate di aderenza al prodotto, fiducia e sicurezza e auto-spiegazione prima di essere fissato, programmato o rifiutato; l'automazione precoce perde il segnale">
  <figcaption>Le conversazioni dirette preservano il contesto finché un bisogno ricorrente non diventa chiaro. Adeguatezza al prodotto, fiducia e auto-spiegazione decidono se diventa una correzione, una voce in roadmap o un no deliberato. Una buona correzione lascia meno domande future.</figcaption>
</figure>

## 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](https://mole.fit/it/blog/the-story-of-mole).

---

Canonical HTML page: https://mole.fit/it/blog/notes-on-building-a-quiet-product
Blog index for agents: https://mole.fit/it/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt
