„Product engineer” pare o denumire nouă pentru o meserie veche, dar diferența este reală. Un inginer clasic este evaluat după volum: tichete închise și funcționalități livrate conform specificației. Un product engineer este evaluat după rezultat: au reușit utilizatorii să finalizeze acțiunea? S-a mișcat indicatorul? A primit afacerea ceea ce a plătit? Codul este același; întrebarea pusă înainte de a-l scrie este diferită.
În practică, un product engineer face câteva lucruri altfel. Întreabă „de ce?” înainte de „cum?”: ce problemă rezolvăm, pentru cine și cum vom ști că am reușit? Contestă specificația când o versiune mai simplă oferă aceeași valoare într-o treime din timp. Are în vedere întregul parcurs al utilizatorului — inclusiv stările de încărcare, eroare și conținut gol — nu doar scenariul ideal din machetă. După lansare verifică analiticele, tichetele de suport și înregistrările sesiunilor, nu doar insigna verde CI.
Rolul cere o perspectivă largă. Nu trebuie să fii cel mai bun expert în baze de date sau designer, dar trebuie să te descurci pe tot parcursul: model de date, API, UI, deployment, analitice și acum AI. De aceea, mulți ingineri full-stack devin product engineers: când deții o funcționalitate de la un capăt la altul, nu ai cui să pasezi întrebarea „de ce?”. Pentru mine, traseul merge de la schema Postgres la ecranul Next.js și apoi la evenimentul care arată dacă a folosit-o cineva.
Product engineerii livrează în pași mici și învață repede. Prima versiune este o acțiune măsurată în producție, sub un feature flag, nu o platformă care se lansează peste șase luni. Știu unde pot face compromisuri (un panou de administrare poate fi urât, un pas manual poate rămâne manual o lună) și unde nu (plăți, permisiuni, integritatea datelor). Această judecată reprezintă cea mai mare parte a muncii și apare doar când trăiești cu urmările propriilor decizii.
Este și un rol de comunicare. Un product engineer vorbește cu fondatorii despre risc, cost și timp, nu despre framework-uri. Discută cu designerii ce e costisitor de construit și propune variante mai ieftine. Vorbește cu utilizatorii ori de câte ori poate. Și documentează deciziile: după șase luni, o notă scurtă despre motivul unei alegeri valorează adesea mai mult decât codul în sine.
Mă numesc product engineer pentru că aceasta este partea muncii care contează cel mai mult pentru mine: nu pull request-ul, ci momentul în care o persoană reală folosește ceea ce am construit și funcționează. De aceea prefer colaborarea pe termen lung în locul predării după două săptămâni: nu poți răspunde de un rezultat dacă nu ești acolo să-i vezi efectele. Dacă ai nevoie de un inginer care pune întrebări incomode și apoi livrează soluția, scrie-mi.
Oferă-i următorului produs cuiva care rămâne.
Ești gata să începem? Trimite-mi un mesaj - pot începe acum și pot rămâne alături de produs. Colaborări pe termen lung, nu o predare în două săptămâni. Să discutăm proiectul, cerințele și cea mai bună cale de urmat.