My first job, two decades ago, was building farm administration software in VB and SQL Server — for an Argentine company that still sells management systems for grain elevators, cattle consignment houses, and meatpacking plants. You'd think I'd be handed a requirements document by a product manager, and the work would then get split into tasks for backend and frontend engineers. Well... not quite. The job was actually closer to what today you'd call an FDE (Forward Deployed Engineer) or a product-minded engineer. I went to clients. I sat with them. I was a consultant even before I was a programmer. The role was called "Analyst Programmer."
Over the years, as organizations grew, we specialized. The stack got waaaay complex. Frameworks multiplied. We have backend, frontend, data, infra, ML, etc. Each layer demands its own tooling, its own patterns, its own mental overhead. And as a by-product of that, we split ownership. The customer problem got distributed across teams and roles.
What's a Product Engineer?
I like how Intercom's job description captures what a Product Engineer is:
"As a product engineer, you'll be taking ownership of real customer problems by building smart, efficient solutions to both back-end and front-end systems."
The key is ownership of customer problems. Not "implement tickets", nor "build features". Solve. Freaking. Problems. Gergely Orosz calls this being "product-minded": engineers who are curious about the business, not just the code. They ask "why" before "how."
The role emerged (reemerged?) from a gap in how product teams work. Luca Rossi describes the shift as well: in traditional Scrum, Product Owners handled tactical work: grooming backlogs, writing user stories, managing tickets. And Product Managers, on the other hand, were supposed to handle strategy: product vision, market positioning, long-term roadmap.
If you have enough budget, that is. Most teams collapsed them into one PM role. And that PM was responsible for both strategy and writing tickets. As you probably might guess, strategy usually suffered.
Two of my best friends and my brother are Product Managers. Extremely smart people that I've seen many times be asked to become glorified secretaries/babysitters of the engineers.
But in high-performing teams, where engineers absorbed the tactical layer, PMs could focus on strategy. In those teams, engineers owned execution from design through delivery. The coordination is simpler, the feedback loops are shorter... man, it's very difficult to explain to someone who's never worked in a team like that how fun and fulfilling it feels.
And when that happens, brain cells are spent in a higher abstraction layer: metrics. PMs focus on lagging indicators: revenue, churn, MAUs. Outcome metrics. They matter, but they move slowly and respond to many variables at once. Product Engineers focus on leading indicators: feature adoption, activation rates, time-to-value. These predict future outcomes. They're harder to identify but faster to move, which means you can actually iterate on them.
Facebook famously tracked how many users added at least 7 friends, and how fast. That was a leading indicator for long-term engagement. The engineers who owned that metric could run experiments, ship changes, and see results in days.
What Product Engineers Actually Do
In a nutshell, they don't consider a new feature done until it moved (or failed to move) a metric. That's it.
Of course it's easier said than done. For starters, it requires picking a metric beforehand. Anyone who has ever tried to implement something like OKRs knows what a pain this is. It requires almost a different mindset than coding. But hey, that's closer to what the engineer's work is supposed to be anyways.
The day-to-day is a loop. A new feature goes out behind a feature flag, to a slice of users. If the metric moves, it rolls out wider. If it doesn't, iterate or kill it. With enough traffic they A/B test. Most of the teams I work with don't have that luxury, so they do the poor man's version: watch session recordings, check adoption account by account, and call the user who tried the feature and never came back.
As teams become better at this the definition of done moves from "merged" to "deployed" to "measured".
And they talk to customers. Directly, not through a PM acting as interpreter. There are teams that define a proportion: customer success engineers spend 80% of their time with customers and 20% coding, and software engineers the exact reverse. It helps engineers to have more skin in the game. When they watch a client fighting with the feature they delivered live, they take fixing it to heart. It looks nothing like reading a ticket three weeks later.
Back to the Future
I know, I know, I know. This modern version of the analyst programmer looks way more sophisticated, automated, efficient, than the one we had two decades ago.
But don't fool yourself, the mindset behind it is not new.
I often read reddit channels where someone says something along the lines of "don't even try the fullstack engineer path, it's nonsense". There's an entire generation that got so far away from customer problems that they can't even recognize the work as part of the craft they decided to pursue in their professional life.
The over-specialization created handoffs, silos, endless alignment meetings. We got really good at building things nobody wanted.
So, I reckon any argument pro AI in the current climate of layoffs and lost jobs is controversial at best, but I can't be happier about the comeback of T-shaped/"paint drip" people.
When tools can scaffold a React component, debug a Terraform config, or explain an unfamiliar codebase in hours, the drop in cognitive load enables the best engineers to expand across the stack. Owning customer problems end to end becomes viable again.
For years I looked at "indie hackers" (and had side projects on my own) as a lost version of what a software engineer used to be. Now the best teams I work with are going back to those basics: owning the outcomes.
