Prodotto ed engineering non valgono quasi niente

Prodotto ed engineering, da soli, valgono quasi zero, e ogni anno valgono un po' meno. Lo dico non malgrado più di dieci anni passati a scrivere codice e a lanciare prodotti, ma proprio perché li ho alle spalle.

Il collo di bottiglia non è più costruire

Dieci anni fa un prodotto che funzionava era già un fossato difensivo. Quasi nessuno era in grado di costruirlo, oppure servivano un team e un anno di lavoro, e chi ce l'aveva partiva con un vantaggio difficile da recuperare. Quel divario non esiste più. Assistenti di programmazione basati sull'AI, framework maturi, infrastruttura che si accende con un clic: tutto questo, insieme, ha quasi azzerato la distanza tra un'idea e la sua prima versione funzionante. Cose per cui un tempo stimavo settimane oggi mi prendono un pomeriggio (tra queste c'è un gioco nascosto in un angolo di questo sito), e non perché sia diventato più veloce io. Sono diventati più veloci gli strumenti.

Quando tutti sanno costruire una cosa, quella cosa smette di essere un vantaggio. È un'arma a doppio taglio, e nella sicurezza fa parecchio male: il costo di un attacco fatto come si deve è crollato seguendo esattamente la stessa curva.

Che cosa scarseggia oggi

Se costruire non è più raro, a esserlo è l'attenzione. Ci sono più prodotti validi che occhi per scoprirli, e più costruire costa poco, più la sproporzione cresce. La domanda non è più "riusciamo a farlo?" ma "qualcuno se ne accorgerà mai?". Oggi la risorsa scarsa è la distribuzione: un pubblico che hai già, un canale che si autoalimenta, una porta d'ingresso verso gli utenti di qualcun altro, un founder con un seguito, una rete commerciale che ti apre stanze precluse ai concorrenti. L'AI non l'ha nemmeno sfiorata, perché non è mai stato un problema tecnico. È una questione di fiducia, e la fiducia si costruisce lentamente, con le persone, nel corso degli anni. Un modello capace di farlo ancora non c'è, e magari non ci sarà mai.

Ho visto prodotti peggiori vincere perché la distribuzione ce l'avevano, e prodotti migliori morire nell'indifferenza perché non ce l'avevano. Va così quando le cose "abbastanza buone" sono infinite e l'attenzione no.

L'indizio Bending Spoons

Prendi Bending Spoons, l'azienda italiana quotata da poco al Nasdaq. Il suo metodo per le acquisizioni è pubblico e non lascia spazio a dubbi: si compra un'azienda per gli utenti, non per il prodotto, e spesso nemmeno per le persone. Ha rilevato app con milioni di installazioni, ha tenuto la base di utenti e ha rifatto da capo il prodotto con i propri sviluppatori. Spesso il team che l'aveva costruito è il primo a essere tagliato.

Paga soldi veri soltanto per la distribuzione e tratta il prodotto, e le persone che l'hanno creato, come la parte sacrificabile.

È una lettura lucida di dove sta il valore. In un mondo in cui chiunque può rifare il prodotto, l'unica cosa che non rimetti in piedi entro martedì è un pubblico che l'app l'ha già aperta stamattina. Oggi l'attenzione è il business stesso, e sembra sempre di più l'unico bene economico rimasto che valga la pena di comprare, vendere o difendere.

L'altra trappola: rilasciare solo perché si può

C'è poi un effetto di secondo ordine. Quando costruire non costa quasi nulla, viene la tentazione di continuare a costruire all'infinito, visto che ogni nuova feature si rilascia quasi gratis. È una trappola, ed è peggio che fare troppo poco.

La vecchia regola del less is more oggi vale più che mai. Ogni feature che aggiungi dopo quella centrale ha un'utilità marginale più bassa della precedente, e oltre un certo punto diventa negativa. Una feature che non serviva a nessuno aggiunge una scelta, una voce di menu, un punto in cui l'utente si ferma a pensare, un modo in più perché ciò che era ovvio diventi un po' meno ovvio. La confusione ha un costo, e si accumula proprio come la distribuzione, solo nel verso sbagliato.

Costruire a basso costo avrebbe dovuto lasciarti libero di concentrarti. Alla maggior parte dei team è successo l'opposto: è venuto meno l'unico vincolo (il costo) che imponeva disciplina.

Le eccezioni sono poche

Qualche eccezione c'è: vantaggi tecnici nell'addestramento dei modelli di frontiera, nell'hardware innovativo o nelle infrastrutture che per essere replicate richiedono anni e capitali enormi. Se fai qualcosa che mille ingegneri armati di strumenti di AI non riuscirebbero comunque a riprodurre in sei mesi, l'eccellenza di prodotto e di engineering ti garantisce ancora un vantaggio difendibile.

Ma parliamo di una fetta sottilissima del mercato. Quasi nessuno di noi addestra foundation model. Quasi tutti costruiamo un'app, uno strumento, un flusso di lavoro, qualcosa che un team competente con un discreto aiuto dall'AI potrebbe rifare in pochi mesi, una volta capito che funziona. Per questa categoria, che poi è la maggior parte del software, la distribuzione è tutta la partita.

Che cosa sto cambiando

Tutto questo cambia il modo in cui uso il mio tempo e, in egual misura, le cose a cui dico di no. Meno ore a rifinire feature che nessuno ha chiesto, più ore a capire per chi è il prodotto e come la gente ne verrà a sapere, prima ancora di scrivere una riga di codice. Meno feature, perché ogni feature in meno protegge quelle che il loro posto se lo sono già guadagnato.

Costruisci in fretta, perché puoi farlo tu e possono farlo tutti, e rilascia di proposito meno di quanto saresti in grado di fare. Poi investi ciò che hai risparmiato nel conquistare l'attenzione delle persone e nel tenertela: è l'unica parte che richiede ancora fatica vera.