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 towards 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
Most organisations discourage Product Engineering without meaning to. 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 the conditions where Product Engineering can emerge.
Give engineers direct access to impact data. At one company we gave everyone access to revenue dashboards, support tickets and usage analytics, with no request process and no sanitised summaries. When an engineer could see their feature had driven £200K in new revenue, or that customers were struggling with their new flow, behaviour changed quickly.
Make it safe to challenge requirements. The best Product Engineers I’ve worked with had managers who backed them when they questioned a feature. “I talked to five customers and none of them need this” has to be a valid argument, even late in the planning cycle.
Give them time to follow through. Amazon famously has engineers carry pagers for their services. The Product Engineering equivalent 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 a single Product Engineer shift a whole team’s dynamic. Once other engineers see the clarity and the recognition that comes with working this way, they start doing the same, and nobody has to mandate it.
Companies that figure this out will have an advantage, because they’ll be solving real problems rather than shipping more features. As AI handles more of the mechanical parts of software development, working out what to build matters more.
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 . Co-authored with AI.