Forse hai notato un nome nuovo: Omar.log() è diventata The Builders Log. Stessa persona, stesso tipo di contenuti, solo un focus più definito.
Qui dentro condivido quello che imparo costruendo prodotti come Product Engineer: riflessioni su engineering, prodotto e carriera, casi studio concreti presi da prodotti veri, con cosa ha funzionato e cosa no e perché. Troverai anche opinioni nate dal confronto con chi fa questo mestiere ogni giorno, founder, engineer, product people. Se è la prima volta che mi leggi, qui sotto puoi iscriverti.
Detto questo, partiamo.
Nell’ultimo periodo ho visto una cosa che un anno fa era rara e oggi è quasi quotidiana: founder che vanno da zero a uno da soli. Aprono Claude Code, descrivono il prodotto che hanno in testa con un minimo di metodo, e in qualche settimana hanno un MVP che gira. Lo mettono online, lo fanno provare, iniziano a vendere e a validare.
E funziona. Non è un giocattolo: è abbastanza vero da raccogliere feedback reali e, a volte, i primi clienti paganti. Più i modelli migliorano, più questa parte diventa accessibile a chiunque abbia un’idea chiara e un po’ di metodo per spiegarla a una macchina.
Quando abbiamo lanciato Learnn nel 2020, questa fase ci era costata mesi. Oggi la validazione iniziale di quell’idea sarebbe stata molto più rapida. Ma è proprio qui che voglio fermarmi, perché è la domanda che quasi nessuno si fa: e dopo?
Dopo che hai il tuo MVP validato arriva la parte che l’AI non ti regala. Capire quali feature costruire davvero e quali no. Capire come misurarle. Sciogliere i colli di bottiglia dell’infrastruttura quando gli utenti iniziano ad arrivare sul serio. Decidere quando usare un servizio già pronto e quando costruirlo in casa. Tenere insieme un sistema che regge sotto carico invece di crollare al primo picco.
Questo lavoro non è scomparso. Si è spostato al centro. E ha un nome.
Il salto che conta non è da zero a uno
Lo zero-a-uno è diventato la parte “facile”. Lo dico senza retorica: è un bene, abbassa la barriera per chi ha buone idee. Ma è anche una trappola, perché ti convince di aver fatto il lavoro quando ne hai fatto il dieci per cento.
Il lavoro vero è da uno a scala: trasformare un MVP che funziona per dieci persone in un prodotto che funziona per diecimila, che cresce in modo sostenibile, che si può mantenere senza riscriverlo ogni tre mesi. Qui il vibe coding non basta più. L’ho verificato sulla codebase di Learnn: scrivere codice in fretta ti porta a uno, ma oltre quella soglia, senza disciplina ingegneristica, accumuli debito più velocemente di quanto cresci.
L’AI ti porta da zero a uno. Ma per scalare davvero, fare in modo che gli utenti usino un prodotto che funziona, serve qualcuno che tenga insieme visione di prodotto e competenza tecnica. È il mestiere del Product Engineer.
Chi è il Product Engineer
Qui vale la pena essere precisi, perché è un termine che si sta diffondendo in fretta e finisce per voler dire cose diverse a seconda di chi lo usa.
Un Product Engineer è un ingegnere che pensa al prodotto. Non un ibrido a metà strada tra developer e project manager. Non un “developer più commerciale”. E soprattutto non qualcuno meno tecnico perché guarda anche alle metriche.
È il contrario, ed è il fraintendimento che voglio togliere di mezzo subito: proprio perché ha autonomia decisionale su cosa costruire, un Product Engineer deve avere basi tecniche più solide, non più deboli. Il focus sul prodotto non sostituisce la competenza tecnica: la amplifica. Decidere bene cosa costruire senza saper valutare come si costruisce è velleitario. Le due cose stanno insieme o non funzionano.
La differenza rispetto a uno sviluppatore tradizionale è la bussola. Uno sviluppatore riceve un task e lo esegue bene. Un Product Engineer parte dall’utente e dal business, e da lì decide cosa vale la pena scrivere. Possiede la feature dall’inizio alla fine: dal database alla UI, fino alla produzione, con la responsabilità del risultato, non solo della consegna.
Provo a metterlo a fuoco lungo tre assi…
La testa: il prodotto come fine, la tecnologia come mezzo
È orientato al valore per l’utente. Non scrive codice fine a sé stesso. Ogni riga esiste per risolvere un problema di qualcuno.
Usa la tecnologia come mezzo, mai come fine. Niente esercizi di stile, niente framework adottato perché è di moda. La domanda non è “è elegante?” ma “serve?”.
Approfondisce il dominio del prodotto. Fintech, edtech, e-commerce, health: conosce il settore in cui costruisce abbastanza da capire perché una feature conta, non solo come implementarla.
Ha una mentalità imprenditoriale. Pensa in termini di sperimentazione e validazione rapida. È a suo agio con l’idea che la maggior parte delle cose vada testata prima di essere costruita per intero.
Le mani: il mestiere ingegneristico
Ha ownership end-to-end. Costruisce la feature dall’inizio alla produzione, frontend e backend, senza scaricare i pezzi scomodi a qualcun altro.
Ha un focus sulla delivery. Automatizza deploy, integrazione e testing, e non ha paura di usare i feature flag per rilasciare e testare in produzione in sicurezza. Sa che un prodotto che non arriva in produzione in modo affidabile non esiste.
Tiene basi tecniche trasversali e aggiornate. La varietà di competenze è un vantaggio competitivo: vede soluzioni che un profilo verticale non vede. Non è il super-esperto di ogni singolo ambito, è il generalista che sa di cosa si sta parlando in ognuno.
Il modo di lavorare: in mezzo agli altri, non sopra
Parla direttamente con gli stakeholder. Non delega del tutto a PM, PO o BA il rapporto con chi ha il problema da risolvere. Vuole sentire il contesto di prima mano.
Decide in modo data-informed, non data-driven. Non insegue ciecamente i numeri, ma non decide nemmeno a sensazione. Usa i dati (Mixpanel, PostHog, GA, A/B test) per informare il giudizio, non per sostituirlo.
Ha un mindset cross-funzionale, e non è un one-man-show. Lavora bene con designer, marketing, business. È un facilitatore tra mondi diversi, non un eroe solitario che fa tutto da solo.
Sotto a queste caratteristiche ci sono cinque aree di competenza che un Product Engineer tiene insieme: business (capire come l’azienda funziona), conoscenza di prodotto (roadmap, prioritizzazione, UX/UI), competenze tecniche frontend e backend (per portare una feature end-to-end in produzione), analisi dei dati, validazione e sperimentazione. Nessuna di queste, da sola, definisce il ruolo. È la loro combinazione che lo rende raro.
Se dovessi riassumerlo in una frase:
Il Product Engineer tiene una mano sulla tecnologia e gli occhi sul prodotto e su chi lo usa. Non sceglie tra le due cose, le tiene insieme.
In un mondo dove scrivere codice costa sempre meno, è questa figura che non si svaluta. E il suo valore, oggi, si gioca su due cose concrete.
Capire cosa costruire e cosa no
Quando costruire era costoso, il filtro era automatico: non avevi le mani per fare tutto, quindi sceglievi per forza. Ora che le mani sono economiche, il filtro devi mettercelo tu. Ed è qui che si separa chi fa prodotto da chi fa rumore.
La velocità abilitata dall’AI è anche un pericolo: puoi sfornare feature a ritmo settimanale e scambiare la quantità per valore, mentre gli utenti faticano a starti dietro. L’antidoto è poco appariscente ma decisivo:
Dire di no alle feature. La maggior parte delle cose che potresti costruire non andrebbero costruite. Il Product Engineer difende il prodotto dall’accumulo, perché ogni feature in più è anche debito, superficie d’errore e complessità che qualcuno dovrà mantenere.
Partire dal problema, non dal codice. Prima di scrivere una riga, valida che il problema esista. Quando abbiamo lanciato Learnn, ho mandato un sondaggio prima di costruire l’app: trecento risposte mi hanno detto cosa serviva meglio di qualsiasi mia intuizione.
Comprare invece di costruire. In early stage, un servizio già pronto batte quasi sempre la soluzione custom. Costruisci in casa solo quando il controllo è davvero un vincolo, non per esercizio di stile. L’AI sposta ancora di più questo confine verso il “compra”: se generare codice è facile, generare codice che poi devi mantenere a vita è ancora più pericoloso.
Misurare. Non data-driven da slogan, ma data-informed: sapere se una feature è usata, da chi, e se sposta il numero che conta. Senza misura, “cosa non costruire” resta un’opinione. Con la misura, diventa una decisione.
Scalare il prodotto
Questa è la metà che si tende a dimenticare quando ci si entusiasma per quanto è facile partire. Da uno a scala non è un problema di idee, è un problema di ingegneria e di prodotto messi insieme:
Infrastruttura che regge. Sciogliere i colli di bottiglia prima che diventino down. A Learnn questo ha voluto dire passare da un monolite a un’architettura a servizi, costruire lo streaming video su AWS serverless, reggere la crescita senza riscrivere tutto da capo.
Sistemi sostenibili. Codice che un team piccolo può mantenere ed evolvere, non una pila di prototipi incollati. Buildare veloce con l’AI è facile; tenere il sistema sano significa riorganizzarlo per domini man mano che cresce, invece di lasciarlo diventare un’unica tabella piatta che nessuno osa toccare.
Processi che reggono la crescita. Una way of working condivisa: come si decide cosa fare, come si fa refinement, come si rilascia. Un team non scala senza un processo, esattamente come un sistema non scala senza un’architettura.
Analytics come parte del prodotto, non un pannello che guardi a fine mese. Misurare deve essere una capacità costruita dentro il sistema, non un ripensamento.
Ownership end-to-end. Una feature dal database alla UI, in produzione, con la responsabilità del risultato. È il filo che tiene insieme il giudizio di prodotto e il mestiere tecnico.
I principi del software engineering non sono diventati obsoleti con l’AI. Sono diventati il differenziatore. Quando tutti possono produrre codice, chi sa produrre codice che scala vale di più, non di meno. L’AI è un assistente straordinario, non un autore: ti accelera dentro un processo, non lo sostituisce.
Perché alle aziende serve adesso
Mettiamo insieme i due pezzi. Pensa a una startup post-MVP: un prodotto che funziona ma non scala, dei founder che fanno ancora tutto. Deve decidere come crescere.
La prima opzione è assemblare un product team: un product manager, un designer, sviluppatori front-end e back-end, magari un tech lead a tenere insieme tutto. E poi dedicare mesi a coordinare le persone e le figure tra loro, prima ancora che ingranino sul prodotto.
Un Product Engineer ti permette, soprattutto in una fase iniziale, di avere una visione più completa del tuo prodotto con un team potenzialmente più piccolo: una persona che tiene insieme giudizio di prodotto e profondità tecnica, e che possiede il problema dall’inizio alla fine. Quando l’esecuzione costa poco, il valore non è in chi esegue, ma in chi sa cosa far costruire e come farlo reggere. Il futuro non è team più grandi: è team più piccoli, più autonomi, con più leva.
Nota bene: non sto dicendo che un designer o un product manager non servano. Dipende dalla fase in cui sei. Sto dicendo che, all’inizio, una figura che copre prodotto e ingegneria insieme ti porta più lontano con meno, e ti fa capire meglio di cosa hai davvero bisogno quando arriverà il momento di allargare il team.
Non è una previsione azzardata: Linear, Vercel e PostHog costruiscono i loro prodotti esattamente su questa figura. All’estero il termine è maturo, a Londra un Senior Product Engineer è una posizione ben definita e ben pagata. In Italia, dove “Product Engineer” nei motori di ricerca restituisce ancora offerte dell’automotive, in pochi sanno cosa significhi. È esattamente per questo che mi interessa parlarne adesso: provare a spiegare, con esempi concreti, cosa significa davvero.
Dove l’ho imparato
Niente di tutto questo è teoria. È Learnn, dal 2020 a oggi: da un’idea su un Google Doc a una delle piattaforme di apprendimento più grandi d’Italia, con oltre 300.000 utenti. Sono entrato come primo developer e ho contribuito a costruire quasi tutto quello che c’era da costruire: il primo MVP, la prima app iOS e Android, l’architettura di streaming video, l’evoluzione da monolite a servizi, il sistema di referral, l’hiring del team, e oggi la sperimentazione di AI nell’esperienza di apprendimento.
La validazione iniziale, quella di sei anni fa, oggi sarebbe stata più rapida. Tutto il resto, quali feature, come misurarle, come reggere la crescita, cosa comprare e cosa costruire in casa, è stato il lavoro vero. Ed è il lavoro che, con l’AI, conterà sempre di più.
In sintesi
Costruire non è mai stato così facile, ed è una buona notizia: più persone possono trasformare un’idea in qualcosa di reale. Ma la facilità di partire non è la capacità di arrivare. Da zero a uno oggi è più facile arrivare; da uno a scala, decidere cosa costruire e cosa no, misurare, reggere la crescita, far sì che le persone usino davvero un prodotto che funziona, resta un mestiere.
È il mestiere del Product Engineer, e più il codice diventa una commodity più quel mestiere conta. Non credo che il futuro sia di chi scrive più codice: è di chi sa quale codice vale la pena scrivere, e sa portarlo fino in fondo.
È questo che racconto qui dentro: cosa imparo costruendo prodotti come Product Engineer. Sostanza presa da prodotti reali.
Omar
Oltre a scrivere, affianco alcuni founder e team post-MVP a costruire prodotti che gli utenti usano davvero. Se può servirti, parliamone.
Se questo articolo ti è stato utile, condividi Omar.log() con qualcuno a cui potrebbe servire 👇