Una delle lezioni più sorprendenti che ho imparato costruendo un SaaS è che la parte più difficile spesso inizia quando il prodotto funziona davvero. Scrivere codice, rilasciare funzionalità, correggere bug e fare deploy sono attività concrete. C’è un problema chiaro, un sistema chiaro e di solito anche un passo successivo chiaro.
Trovare clienti è tutta un’altra storia. La distribuzione è più caotica. Il posizionamento è più sfumato. Il messaggio richiede sensibilità. Click, CTR, retention e conversion ti costringono a pensare non solo da ingegnere, ma anche da marketer, autore, analista e persona capace di capire il comportamento umano.
Pubblicare il prodotto è solo l’inizio
Molti sviluppatori sottovalutano questa parte perché il software restituisce feedback immediati. Un pulsante funziona oppure no. Un deploy va bene oppure fallisce. Il marketing raramente funziona così. Puoi pubblicare qualcosa di intelligente e venire comunque ignorato. Puoi costruire un prodotto utile e avere comunque difficoltà a spiegare perché dovrebbe interessare a qualcuno.
Questo divario è particolarmente frustrante quando costruisci da solo. Sembra di dover imparare una seconda professione da zero mentre cerchi di mantenere viva la prima. Ed è una difficoltà di cui si parla ancora troppo poco nelle conversazioni sincere sul SaaS.
La distribuzione ha un feedback loop diverso
Questa differenza conta perché le metriche di marketing sono segnali, non spiegazioni già pronte. Un clic o una variazione del CTR può dirmi che qualcosa è cambiato, ma non indica da solo se la causa sia il pubblico, il canale, il messaggio, il timing o il prodotto. Retention e conversion sono utili per lo stesso motivo: restringono la domanda, ma non rispondono al posto mio. Il lavoro sta nell'interpretare il segnale e decidere cosa provare dopo.
Perché il lato creativo sembra più difficile
- Il codice premia logica e struttura.
- La distribuzione dipende da attenzione, timing, fiducia e ripetizione.
- Un buon messaggio spesso sembra semplice, ma arrivare a quella semplicità richiede moltissime iterazioni.
- Anche strumenti AI molto forti aiutano più velocemente con il codice che con un posizionamento originale o con un lavoro creativo che suoni davvero umano.
Quest’ultimo punto oggi è quasi ironico. AI può essere utilissima quando il compito è tecnico e ben definito. Ma appena il lavoro diventa creativo, sfumato o legato alla voce, il risultato può diventare goffo. Questo contrasto mostra bene quanto il giudizio umano resti fondamentale.
Non considero tutto questo una prova che l'AI non sappia fare lavoro creativo. La mia conclusione è più limitata: nel mio utilizzo, è più facile fidarsi dell'AI quando il compito è vincolato e il risultato è verificabile. Posizionamento e voce non hanno un equivalente del typechecker. Devo comunque decidere se il risultato è specifico, credibile e adatto al pubblico.
Per me è cambiato il significato di «lanciare»
Questo ha cambiato il modo in cui penso al lancio di un SaaS. Il prodotto può essere online e tecnicamente sano mentre il problema della distribuzione resta quasi intatto. Dopo il lancio parte un secondo ciclo: spiegare per chi è il prodotto, aiutare le persone giuste a scoprirlo, osservare cosa fanno e correggere sia il messaggio sia il prodotto. Per uno sviluppatore solo, questo lavoro compete per la stessa attenzione limitata dell'ingegneria.
Cosa terrei a mente prima del prossimo lancio
- So spiegare chiaramente per chi è il prodotto e perché dovrebbe interessargli?
- Dove lo scopriranno davvero i primi utenti?
- Quali segnali guarderò — clic, CTR, conversion, retention — e cosa non può dirmi ciascuno di essi da solo?
- Sto trattando l'output dell'AI come una bozza da giudicare, invece che come un sostituto del mio giudizio?
Non è una regola universale
Non sto dicendo che acquisire clienti sia sempre più difficile dell'ingegneria per ogni SaaS. Alcuni prodotti hanno vincoli tecnici durissimi; altri dispongono già di distribuzione. Il mio punto è più ristretto: per uno sviluppatore che si sente a proprio agio a costruire software, il lavoro dopo il lancio può richiedere competenze diverse e un feedback loop molto meno deterministico. Nel mio caso, è stata proprio questa la parte più sorprendente.
La mia conclusione pratica è semplice: il lancio non è il traguardo. Acquisizione clienti, posizionamento, messaging e retention sono vere competenze di costruzione del prodotto. Si imparano più lentamente e sono più difficili da fare debug rispetto al codice perché il feedback è più rumoroso, ma ignorarle non le fa sparire.