Product ed engineering non valgono quasi niente
Product ed engineering, da soli, valgono quasi zero. Non zero. Quasi zero. E ogni anno ci si avvicinano di più. E lo dico proprio perché ho alle spalle più di dieci anni passati a scrivere codice e a lanciare prodotti, non malgrado questo.
Una volta sembrava una follia. Oggi non più.
Costruire non è più il collo di bottiglia
Dieci anni fa un prodotto funzionante era già di per sé un vantaggio competitivo. La maggior parte delle persone non era in grado di costruirlo, oppure servivano un team e un anno, quindi se avevi qualcosa che funzionava avevi un vantaggio difficile da recuperare. Quel divario non c'è più. Gli assistenti di programmazione basati sull'AI, i framework maturi, l'infrastruttura che si mette in piedi con un clic: tutto questo ha azzerato la distanza tra un'idea e una sua versione funzionante. Cose che prima stimavo in settimane ora richiedono un pomeriggio, e un gioco nascosto in un angolo di questo sito è una di queste. Non perché io sia diventato più veloce. Sono diventati più veloci gli strumenti.
Quando chiunque può costruire la cosa, la cosa smette di essere il vantaggio. Questo vale in entrambe le direzioni, e nella sicurezza fa male sul serio: il costo di un attacco fatto bene è crollato seguendo esattamente la stessa curva.
Cosa è davvero scarso
Se costruire non è più scarso, lo è l'attenzione. Ci sono più prodotti validi che occhi per scoprirli, e il rapporto non può che peggiorare man mano che costruire costa meno. Il limite si è spostato da "riusciamo a farlo?" a "qualcuno lo vedrà mai?". La distribuzione è la risorsa scarsa oggi: un pubblico che hai già, un canale che si rafforza nel tempo, un modo per entrare tra gli utenti di qualcun altro, un fondatore che ha già un seguito, una macchina commerciale che ti fa entrare in stanze dove i concorrenti non arrivano. L'AI non l'ha toccata, perché non è mai stato un problema tecnico. È un problema di fiducia, che si costruisce piano, con le persone, in anni. Non esiste ancora un modello per questo, e forse non esisterà mai.
Ho visto prodotti peggiori vincere perché ce l'avevano, e prodotti migliori morire nel silenzio perché non ce l'avevano. Non è un fallimento del mercato. È quello che succede quando l'offerta di cose "abbastanza buone" è infinita e quella di attenzione no.
Cosa ci dice Bending Spoons
Prendi Bending Spoons, l'azienda italiana che si è quotata da poco al Nasdaq. Il loro modo di fare acquisizioni è pubblico ed è brutale: comprare un'azienda per i suoi utenti, non per il suo prodotto, e spesso nemmeno per le sue persone. Hanno comprato app con milioni di installazioni, hanno tenuto la base di installazioni e hanno ricostruito il prodotto sotto con il loro team. Il team che aveva costruito quello che hanno appena comprato è spesso la prima cosa a sparire.
Rileggilo. Pagano soldi veri solo per la distribuzione, e trattano il prodotto e le persone che l'hanno fatto come la parte sacrificabile.
Non è cinismo. È una lettura corretta di dove sta il valore. In un mondo in cui chiunque può rifare il prodotto, l'unica cosa che non puoi rifare entro martedì è un pubblico che oggi ha già aperto l'app. L'attenzione non è più una metrica che aiuta il business. È il business, e sempre di più sembra l'unico vero bene economico rimasto che valga la pena comprare, vendere o difendere.
L'altra trappola: lanciare roba solo perché puoi
C'è un effetto di secondo ordine in tutto questo, e va nella direzione opposta. Quando costruire è quasi gratis, la tentazione non è solo costruire una volta e poi passare alla distribuzione. È continuare a costruire, all'infinito, perché ogni nuova funzionalità non costa quasi niente da rilasciare. Quella tentazione è una trappola, e una trappola peggiore del fare troppo poco.
La vecchia regola non ha mai smesso di essere vera: meno è meglio. Anzi, oggi è più vera che mai. Ogni funzionalità che aggiungi dopo quella principale ha un'utilità marginale più bassa della precedente, e oltre un certo punto quel delta diventa negativo. Non neutro. Negativo. Una funzionalità di cui nessuno aveva bisogno non si limita a non aiutare: aggiunge una decisione, una voce di menu, un punto in cui l'utente esita, un modo nuovo perché quello che prima era ovvio diventi un po' meno ovvio. La confusione è un costo, e si accumula esattamente come la distribuzione, solo nella direzione sbagliata.
Costruire a basso costo doveva lasciarti libero di concentrarti. Per la maggior parte dei team è successo il contrario: è sparito l'unico vincolo (il costo) che prima imponeva disciplina, e la disciplina, a quanto pare, era sempre stata la vera decisione di prodotto.
Le eccezioni esistono, e sono rare
Le eccezioni ci sono davvero: vantaggi tecnici reali nell'addestramento dei modelli di frontiera, hardware nuovo, infrastrutture che richiedono anni e capitali enormi per essere replicate. Se stai facendo qualcosa che mille ingegneri con strumenti di AI non riescono comunque a riprodurre in sei mesi, l'eccellenza di product e di engineering ti dà ancora un vantaggio reale e difendibile.
Ma è una fetta minuscola del mercato. La maggior parte di noi non addestra foundation model. La maggior parte di noi costruisce 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 tutta questa categoria, che è quasi tutto il software, la distribuzione non è una parte del gioco. È il gioco.
Cosa sto facendo io
Questo cambia dove passo il mio tempo, e altrettanto a cosa dico di no. Meno tempo a rifinire una funzionalità che nessuno ha chiesto, più tempo a capire per chi è e come ne verrà a sapere, prima di scrivere una riga di codice. Meno funzionalità, non di più, perché ognuna che non rilascio protegge quelle che il loro posto se lo sono già guadagnato.
Costruisci in fretta, perché puoi farlo tu e possono farlo tutti gli altri. Rilascia meno di quanto saresti capace di fare, di proposito. Poi investi tutto quello che hai risparmiato nell'unica cosa che richiede ancora lavoro vero: arrivare davanti alle persone, e restarci.