The job description goes something like this: "We're looking for a product engineer - someone who thinks deeply about user problems and can implement the solution end-to-end." Then the requirements list includes five years of React, three years of backend, experience with design systems, and ideally familiarity with data infrastructure.
The implication is that the product engineer is a unicorn. Rare, possibly fictional, worth a premium if you can find one.
This framing is wrong, and it's wrong in a way that's harmful - to the people trying to hire, and to the people trying to become.
What product engineering actually is
Product engineering is not about having more skills. It's about having a different relationship to the work.
A software engineer's job, in the conventional framing, is to implement specified requirements correctly. The product manager decides what to build. The designer decides how it should look and feel. The engineer decides how to make that happen in code. Each role has a lane.
A product engineer doesn't have a lane in the same way. They're involved in the decision about what to build, the decisions about how it should feel, and the decision about how to implement it - not because they've annexed someone else's responsibilities, but because these decisions are deeply interdependent and separating them produces worse outcomes.
The engineer who understands the user problem will notice when a technical constraint is worth pushing back on because it degrades the experience in a way the spec didn't anticipate. The engineer who's been in the design conversation will build the component in a way that makes the next design decision easier, not harder. The engineer who sees the data will know which features to build next.
That's the job. Not doing three jobs at once - having enough context to do one job well.
How it develops
Nobody becomes this kind of engineer through a curriculum. It develops through a specific kind of exposure over time.
The most direct path is working on small teams where the roles are necessarily blurred. When there are four people building a product, you end up in every conversation. You see the user interviews, you hear what the customers are saying in sales calls, you're in the room when the design decisions get made. That context accumulates.
The second path is caring about the outcome, not just the output. Output is the code. Outcome is whether anyone uses it, whether it solves the problem, whether the product is better. Engineers who optimise for output - who close tickets and move on - don't tend to develop product instincts, because they're not paying attention to the right signals.
The third path is reading. Not engineering books - product thinking books, design books, writing about how businesses work and why users behave the way they do. The engineering skills are learnable through practice. The product thinking requires deliberate input from outside the codebase.
What it isn't
It isn't a designer who can code, necessarily. The product engineer's design instinct is primarily about product decisions - what to build, how it should work, what the right tradeoffs are - not visual craft. Those overlap but they're not the same thing.
It isn't a generalist who is mediocre at everything. The engineers I know who fit this description are genuinely strong technically. The product sense is additive, not compensatory.
It isn't a title or a certification. You can call yourself a product engineer and behave exactly like a conventional software engineer, because the difference is invisible in a job description. It shows up in how you work, not what you write on a CV.
Why it matters now
The economics of software are changing. Building is getting cheaper and faster. The constraint is increasingly not "can we implement this" but "should we build this, and is this the right version of it."
In that environment, engineers who can participate in the should-we and what-version conversations become disproportionately valuable. Not because the technical craft matters less - it matters as much as it ever did - but because the value of that craft is multiplied by good judgment about where to apply it.
The product engineer isn't a myth. They're just what a good engineer looks like when they've paid attention to the right things.