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 approach work differently. When handed a spec, they ask “what are we trying to achieve?” instead of “how should I build this?” They join customer calls, read support tickets for context, and 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 I think 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 more important 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 well. They’re not waiting for perfect requirements because they’re talking to users. They’re not blocked on product decisions because they’re making small decisions 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 what I’ve noticed: most organisations unintentionally discourage Product Engineering. Promotion systems often reward technical complexity over customer impact. Team structures can create walls between engineers and users. Planning processes assume requirements flow in one direction.
We say we want engineers to “think like product managers”, but then give them tickets, not problems. Success gets measured in tickets closed, not customer satisfaction. The loudest voice in the room is often the one arguing for the most complex solution, not the one who understands the user best.
What I’ve seen work is creating conditions where Product Engineering can emerge:
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 engineers could see that their feature drove £200K in new revenue or that customers were struggling with their new flow, behaviour changed quickly.
Psychological safety to challenge requirements. The best Product Engineers I’ve worked with had managers who supported them when they questioned 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 worried about losing control and engineers worried about losing focus. Both concerns make sense but are solvable. Product Engineers complement PMs by handling tactical customer interactions, freeing PMs for more strategic work. Customer conversations can be distracting, but less distracting than building the wrong thing for six months.
“This doesn’t scale.” I’d argue it’s actually what scales best. As teams grow, funneling every decision through a single PM becomes impossible. 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.” Engineers are hired to create value. Sometimes that’s writing code, sometimes deleting code, sometimes talking a customer through their problem until you both understand what they really need. 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.
Companies that figure this out will have an advantage. Not because they ship more features or write better code, but because they solve real problems. As AI handles more of the mechanical parts of software development, identifying and validating what to build becomes increasingly important.
Consider making your next hire a Product Engineer rather than another full-stack engineer. Someone who cares more about what happens after a deployment than the deployment itself. The rest is just typing.
Published on .