There is a particular kind of engineer who does not argue about the database, barely mentions the framework, and asks questions that sound more like a designer's — "what does the user feel when this fails?" They are called product engineers, and they are, at this moment in software, the most valuable archetype in the room.
Working backwards as a discipline
Most engineering training moves in one direction: learn the tools, then figure out how to apply them. The mental model is additive — here is what I know how to build, what can I build with it?
Product engineers run this in reverse. They start with a desired experience — something specific and human, like "a first-time user should be able to set this up without reading a single line of documentation" — and work backwards through every layer of the stack to understand what needs to be true for that experience to exist. The technology is not the starting point. It is the answer to a question the product asked first.
This sounds simple. It is, in practice, surprisingly rare. Most engineers reach instinctively for the familiar — the stack they know, the architecture they trust. Product engineers resist this reflex. They hold the desired outcome steady and let it pull the technical choices toward it, rather than the other way around.
"They hold the desired outcome steady and let it pull the technical choices toward it — not the other way around."
No stack attachment, no territory to defend
Product engineers have broad technical range — comfortable across frontend, backend, infrastructure, and design — but no ego invested in any particular choice. They will pick whatever ships the experience fastest. They will choose the database that fits the access patterns of this product, not the one they know best. What they are attached to is the outcome, and that attachment is strong enough to make all the others expendable.
Engineers develop preferences. Preferences calcify into identities. The React developer. The clean architecture evangelist. These identities can quietly distort judgment — when you are emotionally attached to a solution, you start to see every problem in its shape. The product engineer holds opinions loosely, because the only thing that matters is whether the person on the other side of the screen got what they needed.
Talking to customers is not a soft skill
There is a persistent assumption in engineering that customer conversations belong to someone else — the PM, the designer, the researcher. The engineer's job is to build what those conversations produce, translated into a spec.
Product engineers reject this division. They want to be in the room. They want to hear, in a customer's own words, where the friction is — because they know something important lives in the texture of how a person describes their own frustration. The hesitation before a word. The workaround they have built and are faintly embarrassed by.
That information does not survive translation into a ticket. The product engineer goes and gets it directly, and then carries it with them through every technical decision they make. It becomes the internal standard against which each choice is tested: would the person I talked to last Tuesday feel this? Would they notice? Would it matter to them?
"That information does not survive translation into a ticket. The product engineer goes and gets it directly."
Why this archetype wins now
AI has dramatically lowered the cost of building. The scarcity has shifted from execution to judgment. In that world, the engineer who is also practicing good product judgment — who can move fast and move in the right direction — becomes a force multiplier.
The product engineer does not need a PM to tell them what matters. They have been talking to the customer. They do not need a designer to catch them building the wrong thing, because they started from the experience. They do not slow down to defend their technical choices, because they were never attached to them.
What they produce, at their best, is something that feels inevitable — a product assembled from exactly the right pieces, with nothing wasted and nothing missing. That feeling is not an accident. It is what happens when an engineer cares about the human first and figures out the technology second.
That has always been a good way to build software. Right now, it is the best one.