The rise of the product engineer

Introduction0:00

Hi everyone, and welcome back to the Hybrid Product Podcast. I’m Nikhil Kakarla.

Here’s a line from a job posting I just can’t stop thinking about, written by PJ Murray, CTO of a research company called Great Question: “Nobody here is going to hand you a spec.”

When I was at McKinsey setting up product teams, the spec was everything. The business brought a request, the PM turned it into a PRD, the PRD became epics and stories, and those became tickets. My job was fundamentally to make that chain run smoothly.

In the best teams today, that chain is collapsing from both ends. Engineers are moving towards the customer, product people are moving towards the code, and where they meet, they’re creating a role people are calling the product engineer.

Today I’m going to walk through what’s happening and where it’s going next, because I don’t think it’s stopping at product teams.

Product people who build0:57

The gap between product, design and engineering is getting blurrier by the day. Everyone is writing code, and people have started talking about product engineers and designer PMs. As the lines between these roles continue to erode, organizations will continue to accelerate their development cycles, and more and more people will begin to contribute to the production code base.

The most obvious example of this is Yahoo’s recent announcement about the development of its new AI answer engine, Yahoo Scout. In an official press release, the company explicitly highlighted how AI-powered development is fundamentally restructuring its product teams. Instead of relying on traditional siloed workflows, where product managers write requirements, designers draw static interfaces and engineers build the logic, Yahoo shifted to a highly fluid, cross-functional paradigm.

The press release detailed how the role boundaries dissolved during the project. The design engineer: a product designer on the team who became so prolific in writing and committing actual code that their title and role effectively transformed. The engineering designer: conversely, a traditional software engineer with a sharp eye for usability and design who shifted into heavily shaping the user experience.

Stephane Koenig, vice president at Yahoo, noted that this structural erosion is designed to increase decision velocity and cut the cost of experimentation, allowing cross-functional teams to rapidly test a hundred ideas instead of five, without carrying the usual burden of technical debt, iteration cycles and more meetings.

The spec becomes a prototype2:32

In this new paradigm, which we’re seeing all across the world, the canonical idea of a spec has moved. During my product time, specs were long written documents describing use cases, customer requirements and journeys. Today, specs are working prototypes, sometimes even built and forked from existing production code.

The natural next step, and the one we will explore further, is how those prototypes move directly to production code.

The invoice filter that never shipped3:01

Here’s where I want to take this a little further, because I think the product engineer is just the beginning.

Let me tell you a story from my McKinsey days. I worked with a finance team at a Fortune 500 company whose invoice tool had no sort and no filter. To find an invoice, people paged through screen after screen and waited for each one to load. Across the team, it added up to hundreds of hours a month.

The fix was maybe a day of engineering work. It was already specced out; someone had even vibe coded a change. It just never got done. Not because anyone thought it was a bad idea, the entire business agreed it was a good idea, but because small requests always lose out to the big projects in the engineering backlog. The person who felt the pain every single day had no way to fix it, and the people who could fix it never had the time.

This is just one story, but it’s not rare. A TeamViewer survey of 4,200 workers found that people say they lose about 1.3 days a month to digital friction: slow apps, broken flows and tools that don’t work the way they need. Almost none of it ever becomes a ticket. People just work around it.

The person closest to the problem4:13

So my prediction, and the prediction we have here at Ten, is that product engineering won’t stay in product teams. The person closest to the problem will increasingly be the one who builds the fix. The finance analyst who knows the invoice tool needs a filter. The ops lead who knows the onboarding form is asking the wrong question. The account manager who knows exactly what their biggest customer keeps asking for.

In my consulting days, the classic team had four jobs: decide what to build, specify it, build it, and verify it. AI has made building nearly free. Deciding and specifying are moving closer and closer to whoever is closest to the customer and the end user.

Verification is the bottleneck4:53

The key bottleneck here, and the one that will continue to grow, is verification. It’s almost entirely engineering’s job, and it’s why review will continue to be the slowest part of this entire cycle.

The teams that win won’t just hire product engineers. They’ll make verifying something more people can do safely, with clear rules for what can be pushed, what can’t, and what proof is required for every change. Engineering will set the rules once, and everyone closest to the problem will work inside them.

That’s the world we’re building towards at Ten: a world where anyone can contribute to production code, because there is strong governance around what is safe, what is not, and what proof is required. Engineering will stop being the bottleneck to all product development, and the world’s software will improve at the speed of the world.

If you’re a product engineer and this idea excites you, let us know. We’d love to have you on the show. See you next time on the Hybrid Product Podcast.