«Product engineer» sembra un nuovo nome per un vecchio mestiere, ma la differenza è concreta. L’ingegnere tradizionale viene valutato in base all’output: ticket chiusi e funzionalità realizzate secondo le specifiche. Il product engineer viene valutato in base ai risultati: gli utenti hanno completato davvero l’azione? La metrica si è mossa? L’azienda ha ottenuto ciò per cui ha pagato? Il codice è lo stesso; cambia la domanda che ci si pone prima di scriverlo.
Nella pratica, il product engineer lavora diversamente. Si chiede «perché» prima di «come»: quale problema risolviamo, per chi e come capiremo se ha funzionato? Rimette in discussione una specifica quando una versione più semplice offre lo stesso valore in un terzo del tempo. Si interessa all’intero percorso dell’utente — inclusi caricamento, errori e stati vuoti — non solo al caso ideale del mockup. E dopo il rilascio guarda analytics, ticket di assistenza e registrazioni delle sessioni, non soltanto il badge CI verde.
Il ruolo richiede ampiezza. Non occorre essere il miglior esperto di database o il miglior designer, ma bisogna sentirsi a proprio agio lungo tutto il percorso: modello dati, API, UI, deployment, analytics e ora anche AI. Ecco perché molti ingegneri full-stack diventano product engineer: quando segui una funzionalità dall’inizio alla fine, non hai nessuno a cui delegare il «perché». Per me significa passare dallo schema Postgres alla schermata Next.js fino all’evento che mostra se qualcuno l’ha usata.
I product engineer rilasciano in piccolo e imparano in fretta. La prima versione è un’azione misurata in produzione, dietro un feature flag, non una piattaforma che partirà fra sei mesi. Sanno dove si può semplificare (un pannello di amministrazione può essere brutto, un passaggio manuale può restare tale per un mese) e dove no (pagamenti, permessi, integrità dei dati). Questo giudizio occupa gran parte del lavoro e nasce solo vivendo le conseguenze delle proprie decisioni.
È anche un ruolo di comunicazione. Il product engineer parla con i fondatori di rischi, costi e tempi, non di framework. Con i designer discute di ciò che è costoso da realizzare e propone alternative più economiche. Parla con gli utenti ogni volta che può. E documenta le decisioni: dopo sei mesi, una breve nota sul motivo di una scelta spesso vale più del codice stesso.
Mi definisco product engineer perché è la parte del lavoro che mi sta più a cuore: non la pull request, ma il momento in cui una persona reale usa ciò che abbiamo costruito e funziona. Per questo preferisco le collaborazioni di lungo periodo ai passaggi di consegne dopo due settimane: non puoi assumerti la responsabilità di un risultato che non sei lì a vedere. Se ti serve un ingegnere che faccia domande scomode e poi realizzi la risposta, scrivimi.
Dai al prossimo prodotto qualcuno che resti.
Pronto a iniziare? Scrivimi: posso cominciare subito e restare. Collaborazioni a lungo termine, non passaggi di consegne dopo due settimane. Parliamo del progetto, dei requisiti e del modo migliore per procedere.