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.