Before, there were software engineers, product managers, and designers. Now, these roles are merging: someone owns the product and the code, understands users, and takes ownership over outcomes. 

But until about a year ago, the org chart and its job titles stayed the same. Last summer, there was a shift, and companies started hiring a new type of role: the Product Engineer. 

Today, the term “Product Engineer” is mentioned 100 times/week. That’s a ~335% increase since June 2020, but this growth didn’t really happen until May 2025.

So, what is this new role? 

What is a product engineer?

In today’s companies, the product engineer is exactly what it sounds like: someone who combines product judgment with technical know-how to prototype, build, and iterate quickly. 

Here's what our Chief AI Officer, Zain Lakhani, said:

“Traditionally, an engineer ships something, a product manager talks to users to see if it was viable or not, and that loop continues. But as we move closer to the center of the spectrum—what I'll call "product engineers"—it's a one-person band. Someone who's shipping, iterating, collecting user feedback, and iterating again, all in one, rather than splitting it across engineering, product, and design.” 

Because they can spend less time writing code thanks to Codex, Claude Code, or their preferred agent, this role focuses on higher-value work: creative problem-solving, talking to users, and answering the “what-ifs” rattling around the back of their brains.

While this may seem like a threat to designers or PMs, it’s actually a promise to work together. Here’s what Productengineer.org says in an open letter to product designers: 

“You might see talk of “product engineering” and wonder if we’re trying to step on your toes…But the truth is: it’s mostly written for ourselves. It’s a reminder to stop coding and start thinking. To look beyond the Jira ticket and ask: Does this feel right? Is it intuitive? Would we be proud to ship this?”

What companies are asking of Product Engineers

Product Engineers are more than coders. Rather, they’re blending judgment and taste, data orientation, and technical execution to get to root problems, understand users, and bring solutions to life.

In this job description for a Product Engineer, the role balances technical engineering with product taste: building LLM-powered tools and shipping features, while also talking to the target audience, shaping the platform's direction, and maintaining excellent product taste.

The role also remains rooted in engineering, and product-led, developer-facing companies are championing this concept.

How is this different from the PM role that’s been around for decades? 

Product engineer vs. product manager: What’s different, and what’s the same

Here’s another way to think about this division of labor between PMs and Product Engineers: PMs own the “why” and “what,” whereas product engineers own the full loop, acting on feedback themselves. 

This is how we’re thinking the division of labor: 

Product Managers Product Engineers
Primary focus What to build, and why What to build, how to build it, and if it worked
Feedback ownership Partial. Collects feedback and hands it off to developers End-to-end. Ships and learns themselves
Code ownership None Writes and ships it
User relationship Interviews, research, and synthesis Direct: reads product data and iterates in real-time
Works through Backlogs, PRDs, and handoffs Coding agents
Analytics and product agents
Judgement


Here’s where they do overlap: defining user problems, shaping the product’s direction, and prioritizing what to build. But owning this full loop comes with its own tradeoffs. 

3 core challenges facing Product Engineers

As this role takes shape in organizations, here are a few core challenges facing product engineers: 

  1. Fewer guardrails. Speed is the priority (and the point). But moving from prototype to production with less time to test, think through strategy, and iterate means there’s more risk behind what you ship. 
  2. Reactive analytics. Because you’re shipping at a totally new pace, traditional product analytics and measurement platforms struggle to keep up. PMs used to define what to measure, but now Product Engineers need proactive insights: tooling that surfaces behavioral signals and tells you what to build next and where you’re already working (like Slack). 
  3. Instrumentation as an afterthought. Observability, research, and testing may seem mundane, but it’s what separates an okay product from a great one. In the market these days, that’s generally treated as a second step when it should be a first, and we made the same mistake when building Novus. 

What this means for you

All of this is pointing to a broader shift: generalists are winning. You need to be able to think like a product person, talk to users, look at data, and ship code without the traditional three-meeting handoff. 

The question now isn't "should I hire a product engineer?" If you’re reading this, you probably already know the answer is a resounding yes. Instead, the question to sit with is: how do you give yourself the right foundation to operate this way? 

The hardest part now is knowing what to build next, and whether what you shipped actually works.

That takes staying close to your users and your data, and that’s what separates a Product Engineer from someone who’s shipping slop.

Good news: that’s exactly what we built Novus to do. It’s free, so you can get started today.