What Is a Product Engineer? (And Why More Companies Should Hire One)
"Product Engineer" is a title that's been appearing with increasing frequency in job listings, LinkedIn profiles, and company org charts — often without a consistent definition attached to it. Ask five people what a Product Engineer does and you'll get answers that range from "basically a PM who can code" to "basically an engineer who cares about the user experience" to something genuinely more interesting than either of those.
I've been doing work that fits the Product Engineer description for most of my career, even when my title said something else. Here's my attempt at a clear definition — and a case for why more companies should hire for it deliberately.
What a Product Engineer Is Not
Start with the negatives, because the misconceptions are instructive.
A Product Engineer is not a Product Manager who codes a little. This version exists and is sometimes valuable, but it's not quite right — it still treats engineering as secondary, as something layered on top of a fundamentally PM-shaped role. The PM-who-codes is still primarily a PM.
A Product Engineer is not an engineer who does their own product requirements. This version also exists — and is often a symptom of under-resourced teams rather than a genuine role design. "Full-stack including the product thinking" is usually code for "we don't have a PM and the engineers have to figure it out."
And a Product Engineer is not a designer who can implement. Design engineering is a related but different discipline — it sits at the intersection of design and code, not product and code.
What a Product Engineer Actually Is
A Product Engineer is someone who can hold the product perspective and the engineering perspective simultaneously, in both directions.
In one direction, they think like an engineer while doing product work. When they're writing requirements or thinking about features, they're also thinking about implementation complexity, data architecture, system constraints. They don't write requirements that are architecturally impossible. They don't scope features without understanding the technical cost. They can sit with an engineer and say "I know why that's hard, here's a version that achieves the same outcome with less complexity" — and be right.
In the other direction, they think like a product person while doing engineering work. When they're building, they're thinking about user experience, business context, and outcome rather than just task completion. They flag when the thing they're building doesn't make sense for the user, rather than quietly building what they were told. They bring judgement to technical decisions that affects how the product behaves, not just whether it works.
The result is a role that sits in a different place from either a PM or an engineer — not in between them, but at a different point in the space, closer to both simultaneously.
What Makes Someone Actually Good at This
Technical capability is necessary but not sufficient. Plenty of strong engineers have never developed product thinking, and plenty of PMs with technical backgrounds never fully develop the depth to contribute meaningfully to implementation.
The people I've seen be genuinely excellent Product Engineers share a few things:
Comfort with ambiguity in both directions. Engineering problems often have clear right answers. Product problems often don't. The Product Engineer needs to be comfortable operating in both modes and knowing when they're in which one.
A genuine interest in user behaviour, not just user requirements. Product Engineers don't just implement user stories — they care about whether the implemented thing actually solves the problem it was supposed to solve. They look at usage data. They talk to users. They notice when the metrics don't match the intention.
The discipline to scope. Engineers can be pulled toward building things completely and correctly. Product Engineers need to make the same judgements about scope that PMs make — what's the minimum that solves the problem? What can be deferred? What doesn't need to be built at all?
Credibility in both rooms. This is the thing you can't shortcut. A Product Engineer who engineers can't take seriously isn't a Product Engineer — they're a PM with some coding knowledge. A Product Engineer who can't navigate product and business conversations isn't a Product Engineer either. The credibility has to run in both directions.
Why Companies Should Hire for This Explicitly
The traditional separation of product and engineering into distinct functions creates some structural problems that Product Engineers solve well.
The translation problem. In most teams, there's a translation layer between what product decides and what engineering builds. Requirements go into a spec, engineers interpret the spec, implementations come back, product reviews, feedback loops. Every pass through the translation layer is an opportunity for information loss. A Product Engineer reduces the translation layer — not because one person is doing two jobs, but because the gap between intention and implementation is smaller.
The feedback latency problem. When product and engineering are fully separated, feedback from the built product takes a long time to reach the people making product decisions. Product Engineers are closer to both the decision and the implementation, which makes the feedback loop faster.
The early-stage problem. At the early stage, you often can't afford to fully staff both a product function and an engineering function separately. A Product Engineer can cover more of the ground without the loss of quality that "engineer does everything" usually produces.
The innovation problem. The most interesting product ideas often emerge from the intersection of a technical possibility and a user need. Product Engineers live in that intersection. They notice technical capabilities that could solve user problems, and user problems that could be solved by technical approaches nobody has tried.
Where This Role Is Growing
I've seen Product Engineer roles appearing most often in:
- Early-stage startups where the team needs range and the product/engineering separation isn't yet warranted
- AI product teams where the product decisions and the technical decisions (about models, prompts, data pipelines) are too intertwined to separate cleanly
- Developer tools companies where the user and the builder are often the same person, and deep technical empathy is a product requirement
- Scale-ups that are investing in product quality rather than just feature volume
The role is also appearing in larger organisations as a specific sub-function within engineering — not replacing PMs or engineers, but creating a bridge layer that reduces the friction between the two.
Is It Right for You?
If you're an engineer: do you find yourself more engaged by the "what should we build and why" question than by the "how do we build this" question? Do you get frustrated when you build something technically correct that doesn't actually work for users? Do you naturally think about the user experience of the things you're implementing?
If you're a PM: is your technical background deep enough to contribute meaningfully to implementation decisions, not just understand them? Do you feel constrained by the distance between your decisions and the built product? Does hands-on work with the product energise you rather than distract from the "real" job?
If you answered yes to the questions in either category, it might be worth looking at whether the Product Engineer label fits better than the one you're currently using.
It's a real role. It's increasingly in demand. And if the industry's direction of travel is any indication — AI tools making individual contributors more capable, product and engineering decisions becoming more intertwined — it's likely to become more central, not less.