We asked 36 teams about merging product and engineering into a single role
A few days ago, I ran some polls across various platforms asking how successful is it for engineers to take on product responsibilities—from shaping features and talking to users to owning outcomes and mini-roadmaps.
📊 Out of 36 responses:
✅ 11 said “Yes – it works really well”
🤔 20 said they had mixed results
❌ 3 said “No – it hasn’t worked for us”
🤷 2 said “They hadn’t tried or considered it”
Given the perceived rise of product engineering roles, I was surprised by the amount of mixed results and had predicted more success. I dug deeper given the limited sample size and had some excellent conversations with CTOs and product engineers. Here are the takeaways.
🧩 Success depends on culture
Many leaders expect engineers to think in outcomes, not just implementation
“The best systems are engineered from a great understanding of the customer problem.”
— but in reality what they actually work on is still being fed to them in a top-down hierarchal manner.
Whether it works depends heavily on how aligned leadership, incentives, and autonomy really are.
For example, one product engineer described a culture of low process, high independence, and deep technical work—but still felt frustrated by leadership misalignment:
“We’re sometimes told to work on what we feel is not the highest impact business opportunities. It’s hard to redirect leadership.”
🔑 Takeaway: Product thinking only thrives where engineers are empowered to challenge or set their own priorities at the highest level.
⚖️ The role only works if engineers want it
This is kind of a no-brainer but arguably remains to be implemented into your existing hiring process as a product competency section.
“We don’t hire unless engineers show clear motivation for product outcomes.”
You can do this by asking open-ended questions such as
What gets you out of bed in the morning?
What makes you feel like it’s been a good day?
What gives you a sense of achievement?
You can then see if they include the customer or business outcomes in their answers.
But it doesn’t work for everyone. Not every engineer wants to operate this way, and trying to force it can create more confusion than clarity.
“Success is varied when I have tried to implement this within existing teams.”
🔑 Takeaway: This model works best when it’s part of your hiring DNA — not an afterthought.
⚠️ Product Engineers ≠ Magic Fix
Several engineers expressed a desire for tighter feedback loops with users—often bypassing PMs entirely.
“Product managers are like a broken phone line. I’d rather talk to customers directly.”
— but this model can fail if there’s no support structure, unclear product direction, or a mismatch in motivation.
“It’s rare that it works well. Engineers often jump to solutions instead of understanding the problem.”
Rather than eliminating product roles, some teams are finding success by having PMs mentor engineers into product-minded contributors — for example:
getting them involved in product updates
telling a customer their issue was fixed
shadow you in customer call
🔑 Takeaway: Like most things, product thinking is a muscle that needs to be developed not an instant switch.
So where does this leave us?
It seems like the Product Engineer is not a formal title everywhere, but it is a mindset that many teams are either hiring for, growing into, or aware of. The teams that have embraced it fully have observed successful outcomes.
As AI accelerates and the mechanics of software delivery become increasingly commoditised, the value of engineers who can think in bets, not just specs is only going up. The “Product Engineer” might not be standard today, but it’s likely a glimpse of where things are headed.