Something shifted. Engineers aren’t waiting for product specs anymore. They’re challenging assumptions, talking to users, and influencing what gets built. The boundaries between engineering, PM, and design are blurring.
AI accelerated this trend, but it didn’t create it. Companies were hiring “Product Engineers” years ago. Now more are following.
They’re all doing it differently. Some want engineers who think like PMs. Others want full-stack builders with design sense. Some emphasize ownership, others collaboration.
What’s actually in common? Is there a pattern beneath the different implementations?
Hi, I’m Peppe. I started coding at 14, building websites and dreaming about creating products that would change the world. Fast forward to 2022, I was working as a software engineer but feeling trapped as a code monkey. I wanted to shape what got built, not just how.
I wrote about that frustration in this article, calling engineers like me “product thinkers.” I didn’t know it was called “product engineering” back then.
My hypothesis: Product Engineers are expert generalists who own product problems end-to-end. They can talk to users, design solutions, implement them, and measure impact. They may be stronger in discovery, UX design, or engineering, but they all start from the same foundations. Like soldiers in a squad with different specialties.
This Lab is where I’m testing that hypothesis. I’ve interviewed engineers and leaders, documented real stories from the field, and patterns are starting to emerge. I’m figuring it out in public, and you can follow along.
Real Stories from the Field
”Every technical choice opens some product options and closes others”
A senior engineer at an enterprise product company prevented weeks of wasted work by asking one simple question: “What’s the first action users actually do?”
The product team had planned to replicate pages one-by-one. The engineer challenged this by focusing on actual user behavior instead of page structure. Result: Complete direction change before a single line of code was written.
The shift: From implementing tickets → to shaping problems through questions.
From Zen Educate
“We’re not ticket-takers anymore. Engineers are problem shapers.”
VP of Engineering Martin Pengelly-Phillips transformed the entire engineering culture:
- Before: Product managers wrote tickets, assigned work, and approved engineer’s output before shipping
- After: Engineers challenge problem definitions, participate in design discussions, partner directly with commercial leaders
Quote from Martin: “A product engineer is someone who loves solving real problems for users and just happens to be skilled at leveraging technology to do that. The mark of a product engineer is someone who solves a problem sometimes by not building anything.”
What I’m Learning
From interviews with engineers, leaders, and PMs, I’m documenting:
- How roles are converging - What’s driving the blur between engineering, PM, and design
- The organizational structures that enable Product Engineers (with examples from real companies)
- What skills enable this shift - Discovery, user research, design thinking, business acumen, and how to develop them
- How engineers transitioned from ticket-takers to problem shapers (with practical paths you can follow)
- How PMs and designers evolve in product engineering teams (roles don’t disappear, they change)
- Navigation strategies for resistant organizations (when culture blocks the shift)
- What actually works (and what doesn’t) from practitioners in the field
Follow the Exploration
Monthly Newsletter
Get packaged insights from my exploration: interview highlights, patterns emerging, and what I’m figuring out.
Other Ways to Explore
This Website - Raw notes, interview transcripts, working thoughts. A digital garden where exploration happens in public.
Read Stories · Listen to Podcast · Explore Patterns
Community - Join Discord to discuss with fellow explorers
Latest Content
Podcast
- Software Engineers As Problem Shapers (Not Ticket Takers) - with Martin Pengelly-Phillips, VP of Engineering at Zen Educate
Stories
- Senior Engineer #1 - How asking questions changed project direction before code was written
- CTO #1 - The struggle of enabling product-minded engineers: “Both conditions are needed—leadership that believes AND engineers who want to do it”
Who This Is For
IC Engineers - You want to shape WHAT gets built, not just HOW. Navigate your organization to make this shift.
Engineering Leaders - You want to enable Product Engineers but don’t know how to structure teams or develop people internally.
Product People - You’re navigating how your role evolves when engineers become more product-minded.
This is my opinionated exploration, not neutral research. I believe product engineers > specialized handoffs. But I’m testing that belief against real experiences from real teams.
Follow along if you’re curious.
— Peppe
Content licensed under CC BY 4.0 — Free to share and adapt with attribution to Product Engineering Lab