I once worked with an engineer who’d built exactly what the PM requested: a beautiful dashboard showing user engagement metrics. It shipped on time, tests passing, code clean. Two months later, we discovered nobody had looked at it since launch week. The engineer had already moved on to the next sprint.
On the same team was another engineer who’d shipped a scrappy CSV export instead. Nothing fancy, just a daily email with the numbers our biggest customer actually needed. They’d discovered this by sitting on support calls and watching the customer copy-paste data from three different screens into Excel. That CSV export? Still running three years later.
The difference wasn’t technical skill. It was attitude. The second engineer was what I’ve come to recognise as a Product Engineer.
The Pattern
Product Engineers show up differently. When handed a spec, they ask “what are we trying to achieve?” instead of “how should I build this?” They join customer calls. They read support tickets for context. They ship the quick fix today while planning the real solution for next quarter.
These engineers share certain traits:
- They instrument their features to answer “did this work?” not just “does this work?”
- They follow up weeks after shipping to see what actually changed
- They’ll argue against building their own features if the data suggests otherwise
- They know the names of actual customers and their specific problems
Why This Matters Now
The industry has been moving toward full-stack engineers for years, but we’re solving for the wrong thing. We don’t need engineers who can work across the entire technical stack. We need engineers who can work across the entire value stack, from customer problem to business impact.
This becomes critical as teams get more autonomous. When you can’t hide behind handoffs and specifications, someone needs to own the full loop. Product Engineers fill this gap naturally. They’re not waiting for perfect requirements because they’re already talking to users. They’re not blocked on product decisions because they’re making micro-decisions constantly based on customer feedback.
I’ve watched teams transform when even one engineer starts working this way. Sprint planning becomes a discussion about outcomes, not story points. “Definition of done” evolves from “deployed to production” to “customers are successfully using it.” The PM stops being a gatekeeper and starts being a partner.
The Organisational Challenge
Here’s the uncomfortable truth: most organisations actively discourage Product Engineering. Our promotion systems reward technical complexity over customer impact. Our team structures create walls between engineers and users. Our planning processes assume requirements flow in one direction.
We say we want engineers to “think like product managers”, but then we give them tickets, not problems. We measure success in tickets closed, not customer satisfaction. We create a culture where the loudest voice in the room is the one who can argue for the most complex solution, not the one who understands the user best.
What does work is creating conditions where Product Engineering emerges naturally:
Direct access to impact data. At one company, we gave every engineer access to revenue dashboards, support tickets, and usage analytics. No request process, no sanitised summaries. When an engineer could see that their feature drove £200K in new revenue or that customers were rage-quitting at their new flow, behaviour changed overnight.
Psychological safety to challenge requirements. The best Product Engineers I’ve known all had managers who backed them when they pushed back on features. “I talked to five customers, and none of them need this” has to be a valid argument, even late in the planning cycle.
Time to follow through. Amazon famously has engineers carry pagers for their services. The equivalent for Product Engineering is owning your feature through its first month of real usage. If you build it, you should see how it lands.
The Counter-Arguments
“But engineers shouldn’t talk to customers.” I’ve heard this from PMs who fear losing control and from engineers who fear losing focus. Both concerns are valid but solvable. Product Engineers aren’t replacing PMs, they’re making PMs more strategic by handling tactical customer interactions. And yes, customer conversations can be distracting, but not as distracting as building the wrong thing for six months.
“This doesn’t scale.” Actually, it’s the only thing that scales. As your team grows, you can’t funnel every decision through a single PM. You need engineers who can make good product decisions independently. Would you rather have 10 engineers waiting for perfect specs or 10 engineers each solving real problems?
“We hired engineers to write code.” You hired engineers to create value. Sometimes that’s writing code. Sometimes it’s deleting code. Sometimes it’s talking a customer out of a feature request because you understand their problem better than they do. The best engineering work often looks nothing like engineering.
Starting Small
You don’t need to transform your entire engineering culture overnight. Start with one volunteer on one feature. Let them own something small end-to-end, from customer conversation to post-launch metrics. Make it safe to succeed or fail.
I’ve seen single Product Engineers shift entire team dynamics. Once other engineers see the impact of working this way the clarity, the purpose, the recognition, they start adopting similar practices. Not because someone mandated it, but because it’s obviously better.
The companies that figure this out will have a massive advantage. Not because they’ll ship more features or write better code, but because they’ll solve real problems. In a world where AI can increasingly handle the mechanical parts of software development, the ability to identify and validate what to build becomes the differentiator.
Your next hire shouldn’t be another full-stack engineer. It should be a Product Engineer. Someone who cares more about what happens after the deployment than the deployment itself. The rest is just typing.
Published on .