The Rise of the Product Engineer

For a long time, software engineers had a fairly obvious job - take requirements, turn them into working software, push back when something was technically questionable, and occasionally explain why a seemingly small request was anything but small. That line was never particularly clean at startups. Engineers have always ended up doing some product work. We implement experiments, decide edge cases that never made it into the spec, instrument analytics, add session recording, look at where users get stuck, and sometimes question whether the proposed feature makes sense in the first place.

Now there's a name for taking that further - Product Engineer.

The term itself isn't new. Atlassian was writing about product engineers back in 2019, describing engineers who cared about the customer problem and the success of the product rather than simply receiving requirements and implementing them. What is new is how quickly the role is becoming recognizable as a specialty of its own.

The funny part is that I've spent years doing parts of this job without realizing it had become a job. Apparently, "wear many hats" finally got its own title, and Full Stack devs don't get to keep it to themselves anymore :)

AI moved the bottleneck

AI coding tools have made implementation dramatically faster. An engineer can hand an agent a reasonably scoped task and get much of the mechanical work done without spending the afternoon typing it out manually. That doesn't mean engineering work disappeared. It means some of our time moved elsewhere. If implementation gets cheaper, deciding what should be implemented becomes a larger part of the job.

That naturally pushes engineers closer to product management - understanding the problem, deciding whether a proposed solution is sensible, prototyping alternatives, measuring what happened after release, and iterating from there. PostHog recently pointed to the growing popularity of the role, noting that more than 100 Y Combinator startups were hiring Product Engineers.

Current Product Engineer openings increasingly describe engineers who work directly with customers, decide how problems should be solved, and own features from problem discovery all the way through production. One YC listing, for example, explicitly asks Product Engineers to talk directly with customers and translate their problems into features.

Engineers have been suspiciously close to this job already

For engineers in startups, much of this should feel familiar. Product decisions already leak into engineering constantly. APIs expose assumptions about how a feature should behave. Data models encode product rules. Frontend flows force decisions about edge cases. Analytics and observability tell us what users are actually doing. Sometimes the engineer implementing a feature is the first person to notice that the original idea doesn't quite work.

The bigger change with Product Engineering is that the boundary moves one step further. Instead of Product deciding what we should build and Engineering determining how to build it, the engineer increasingly participates in both questions.

The less familiar part for many engineers will probably be talking to users directly. Analytics can tell you that 40% of users abandon a workflow. A session recording can show you where. Logs can tell you what happened. None of those necessarily tell you why. A Product Engineer may actually have to ask.

Not a promotion, but a specialty

Product Engineer shouldn't be confused with "Senior Engineer, but more product-y." There are engineers who want to spend their careers going deeper into infrastructure, distributed systems, security, databases, browser internals or frontend architecture. Product Engineering is a different direction. The specialty optimizes for breadth across the product lifecycle.

A good Product Engineer still needs to be a good engineer, but the job increasingly includes product intuition, UX judgment, experimentation, analytics and enough customer understanding to make useful decisions without waiting for a perfectly specified Jira ticket. AI makes that combination much more practical. An engineer who previously spent three days implementing an idea might now get a credible version running in one. The remaining time can go toward trying another approach, watching how people use it, fixing what was misunderstood, or deciding the feature shouldn't exist after all.

That changes where engineering leverage comes from.

So, how do you become a good Product Engineer?

Start by understanding the problem before touching the solution. Talk to users when you can, and use analytics, session recordings and experiments when you can't. Know what success looks like before you ship.

Then keep following the feature after it reaches production. A Product Engineer owns more than whether the code works. They care whether anyone uses it, whether it solved the original problem, and what should happen next.

Use AI for what it's good at - shortening the path from idea to working software. The judgment about what deserves to be built is still yours.

Final words

Product Engineers existed long before the current AI wave. Startups have always needed people willing to cross the imaginary border between Engineering and Product. But AI is giving that way of working a much stronger reason to become an explicit role.

A lot of engineers may discover they've already been doing part of it for years.