Something weird is happening in product teams right now. Engineers are getting involved in product decisions that would have traditionally belonged to PMs. Product managers are shipping code. Designers are ditching Figma for vibe-coded prototypes that ship faster than polished mockups ever could.

You might be wondering if this marks the end of role specialisation as we know it, but the answer to that question is more nuanced than a simple yes or no.

A few years ago, I went through something of a career crisis. I had grown tired of feeling like a code monkey, someone who just translated other people’s ideas into working software without having much say in what those ideas should be in the first place. The feeling gnawed at me enough that I started looking for alternatives, speaking with dozens of PMs, engineering leaders, product leaders, and other software engineers who seemed to have found a different path. I also started experimenting with my own work, pushing boundaries where I could, trying to understand what was possible.

What I found through all of this research genuinely changed my perspective on how our roles are going to evolve in the coming years. This isn’t really about AI making everyone more capable, though that’s part of the story we’ll get to later. This is about a trend that’s been growing steadily in how we build products, one that I’ve watched gain momentum over the last several years.

My research led me to discover the product engineer role, and I can honestly say it’s been one of the best things to happen in my career so far. Over the last four years, I’ve spent countless hours trying to understand how this actually works in practice, conducting extensive research and talking to people who are living this reality every day.

The PostHog Model: Engineers at the Driver’s Seat

The company that really pioneered the product engineer role is PostHog. They're a startup that develops an open source product analytics platform combining multiple tools into one to help developers understand user behaviour and build better products. What makes them fascinating isn't just their product, but how they build it.

PostHog keeps its teams deliberately small, with a maximum of six people per team. The most interesting part, though, is that engineers are the ones leading product initiatives. Not PMs, not anyone else. Product managers and designers still exist at PostHog, but they play a fundamentally different role than in most other companies.

PMs at PostHog act as a compass for engineers rather than as directors. They hold the context in which engineers can operate and make good decisions, but the final decision always remains the engineer’s responsibility. Designers aren’t assigned one-to-one with teams either. Instead, they’re available to multiple teams and can be consulted when needed. If there’s a complex user interaction to solve, an engineer can bring in a designer to collaborate on finding the right solution.

As James Hawkins, one of PostHog's founders put it:

"PMs exist to empower engineers, not to control them."

This isn't just empty philosophy either. In one article, he describes the story of Karl, a product engineer who was adamant about building a session replay feature. Karl believed customers would benefit from it because they were actually asking for it, but the founder was skeptical and unconvinced. Karl built it anyway. The feature turned out to be a massive success and even influenced the company's broader strategy going forward.

Today, PostHog has developed more than eight products and hit significant revenue goals, all with engineers leading product initiatives. I should note that PostHog isn’t paying me to say any of this. This is simply what emerged from my research, and I’m just documenting what I’m finding.

PostHog probably represents the most extreme example of what a product engineer can do. Their engineers have such a strong sense of ownership over product initiatives that they can take them end-to-end, from talking to users to designing the user experience to actually implementing the solution. It’s empowering to see, but for most companies I’ve encountered, the reality looks somewhat different.

The More Common Path: Engineers as Problem Shapers

Take companies like Zen Educate or New Store, for example. These are organizations where there’s still a clear separation of roles with strong cross-functional teams composed of a product manager, a designer, and one or more engineers. The real differentiator is that product engineers aren’t sitting around waiting for specifications to arrive in their inbox, maybe written by a product manager in Jira or handed off by a designer in the form of polished mockups.

Instead, these engineers are involved 360 degrees in the product definition space. When someone approaches them with something to build, they’re there to challenge assumptions and ask the hard questions. Are we sure this is even a problem worth solving? Could we be looking at this problem from a different angle? They help define solutions and contribute to prioritization decisions. In these companies, product engineers aren’t positioned at the end of the assembly line. They’re involved from the very beginning, and their contribution to the product’s success is substantial.

Martin Pengelly-Phillips, the VP of Engineering at Zen Educate, put it beautifully during our conversation on the Product Engineers Podcast. At Zen Educate, product engineers aren't ticket takers. They're problem shapers. The power in that distinction is enormous.

He also said something else that stuck with me.

"If you have engineers, you can build and maintain a product without anyone else, but product managers represent overhead. Their main responsibility should be to find new ways to accelerate the work of engineers, not to create obstacles."

There’s a lot of wisdom packed into that perspective.

PostHog and Zen Educate aren’t alone in this approach either. Over the last three years, I’ve seen the product engineer role mentioned in job postings more and more frequently. Companies like Ashby, Linear, and Vercel all have their own implementations of the role. The details vary from company to company, but the core idea remains consistent across all of them: engineers are involved in product decisions in one way or another.

What Makes a Product Engineer?

So what are the skills that actually make someone a product engineer?

It’s challenging to give a single, definitive answer because every company has its own implementation. They’re all doing it in different ways, adapting the role to their particular context and needs. What I’ve tried to do is develop my own hypothesis, my own definition of what I think we’re going to see more and more in the coming years. This evolution won’t just come from software engineers expanding their scope either. It will also emerge from product managers becoming more hands-on thanks to AI, upskilling themselves in technical areas, and from designers who are getting involved in the coding and engineering side of things.

In my view, a product engineer is a generalist expert with solid foundational knowledge across the four core activities that make up product development. These are product discovery, user experience design, the actual technical implementation, and making sure the work that’s been done delivers real impact and value for customers.

The way I see it, product engineers start their work when the business provides them with a business goal. For example, maybe the company needs to increase customer acquisition in a specific segment of the business. The question becomes how we can update or change the product to meet that goal. This is where product engineers begin working, helping to define the actual problem and then scoping down what needs to be done to solve it.

From there, they move into experimentation with prototypes, which nowadays with AI is becoming faster and more accessible. They leverage pre-made design systems to create user experiences efficiently. I’d expect a product engineer to have knowledge about how to create user experiences that are both nice to look at and functional to use. Then comes the implementation side, building the actual technical solution, followed by tracking whether what was built is actually working as intended.

Now, I do think it’s important to set some boundaries here. Everything outside of this core flow probably shouldn’t be part of the product engineer’s scope. Platform work and DevOps, for instance, should ideally be automated as much as possible so that engineers don’t have to worry about where the software is running, how deployments happen, or how testing gets executed. All of that should be automated to let them focus on the product side of things. If there is work to be done in those areas, a product engineer certainly could do it, but an expert in server administration and infrastructure would probably be better suited for that kind of work.

You might be thinking that this sounds like too much for one person to handle, and you’d be right. I don’t expect a product engineer to be doing all of that at the same time, every single day. The role needs to be flexible. We can agree that product engineers should have foundational knowledge across the four core activities, and that model works quite well in early stage startups where there are fewer people and everyone needs to do more with less.

But as companies grow and teams start to form, product engineers can specialize in one area while maintaining their broader understanding. Each of us is stronger at something specific. Some product engineers might excel at user experience, making them a natural fit for the intersection of UX design and frontend development. Others might be stronger at discovery or at the systems level. Having this diversification of experiences and perspectives within a team becomes incredibly valuable as the company scales.

Here’s where I draw inspiration from extreme programming practices. When product engineers work in a team, they shouldn’t be working alone on different initiatives. That isolation creates problematic behaviors like the lone wolf mentality or the hero complex, where someone feels they need to save the day single-handedly. I think it’s still better to work in pairs or in ensembles where people come together to work toward a shared goal. The overhead might seem concerning, but nowadays with all the help we’re getting from AI, I think the headcount needed can be quite small. Still, there’s enormous value in bringing different people with different perspectives together to work toward a common objective.

This is my working hypothesis for what product engineering looks like. Some companies like PostHog are already close to this model, while others aren’t quite there yet. But this is what I see happening over the next few years, and it’s exactly why I started the Product Engineering Lab. I want to keep exploring this space and see if this vision actually materializes. I hope it does because I genuinely love it, but we’ll see what happens.

Beyond the structural definition, let me give you a sense of what the traits of a good product engineer look like compared to a more traditional approach.

What a good product engineer does:

  • Ships quickly to get fast feedback while preserving quality, ruthlessly scoping down to the minimum viable work that brings real value rather than rushing things just to check boxes

  • Understands the company’s strategy and the broader product ecosystem deeply, using that knowledge to help prioritize effectively and bring real business value

  • Proactively proposes ideas and alternatives instead of waiting around for specs to materialize in their inbox

  • Tracks the impact of their work and stays deeply curious about whether what they built is actually working

  • Actively wants to talk with users when given the opportunity, seeking out those conversations to inform their decisions

  • Cares about what happens after they ship, staying engaged with the feature beyond the deployment

What someone who isn’t a product engineer does:

  • Implements a feature, ships it, and then completely forgets about it, moving on to the next ticket without looking back

  • Doesn’t want to engage with users even when the possibility exists, preferring to stay in their technical comfort zone

  • Doesn’t care about measuring impact or understanding whether their work actually solved the problem it was meant to solve

  • Spends months building something elaborate before getting any feedback from real users, over-engineering solutions in isolation

  • Waits passively for specifications and requirements to be handed to them rather than challenging or shaping the work

  • Views the business side as someone else’s problem, focusing purely on technical implementation without context

These contrasting traits tell you everything about someone’s approach to the work.

The hard skills side:

As for the technical capabilities, this is something I’m still actively figuring out through my research, but here’s a solid starting point for what a product engineer should develop:

  • Learning to talk with customers and users effectively, conducting interviews and gathering feedback that actually informs decisions

  • Having at least a basic understanding of what makes good UX, knowing the established design patterns and foundations that make interfaces intuitive and functional

  • Strong engineering fundamentals, though I’d expect some product engineers to be stronger in frontend technologies compared to backend, and that’s perfectly fine depending on where they can bring the most value

  • Analytics skills for experimenting and understanding impact, being able to measure whether features are actually moving the needle for customers and the business

I know this is a lot to absorb, but I want you to remember something important. This is what most of us engineers actually signed up for when we got into software engineering in the first place. We wanted to have an impact with our work. We wanted to solve product problems before we wanted to solve technical problems. That initial spark is still there, even if it’s gotten buried under years of process and handoffs.

The AI Question: Accelerator, Not Creator

People often ask me about the role of AI in the rise of product engineers. Did AI create this trend? I don’t think so. PostHog has been hiring product engineers since 2020. Companies like Ghost and Linear have always hired product engineers, even before ChatGPT was a thing.

The main reason companies have been looking for a new way of working has been overspecialization. In my experience, overspecialization brings significant inefficiencies because it requires extensive coordination between different roles and between people who can’t work independently because they’re constantly relying on each other. It also incentivizes the creation of those fake agile processes that we’ve all suffered through.

You know the pattern: PMs do all the discovery work, talk with customers, and decide what needs to be built. Designers create mockups in isolation. Then everything gets handed off in the shape of a Jira ticket to engineers who are just waiting at the end of the assembly line. This creates massive delays because every activity produces outputs that take time to create before being passed down the line. Inevitably, something gets lost in translation along the way.

It’s not uncommon for engineers to misunderstand what needs to be built or to build something in the wrong way because they’re not aware of the actual problem the solution is meant to solve. The handoffs create distance, and distance creates misunderstanding.

What AI has done is accelerate the trend of having all these roles converge rather than creating the trend itself. AI can help engineers do discovery work and support them with user research. It can help PMs and designers write code, particularly for prototyping, which used to be far more costly and time-consuming than it is now. PMs and designers are increasingly aware of how valuable it is to upskill in coding, to understand what they’re doing with the help of AI.

AI has made everyone more capable across the board. The question now isn’t who has the skills anymore. The question is,

who owns the outcomes? Who owns the problem? It doesn’t matter how that problem gets solved or what tools are used along the way. That’s why the roles are converging, not because AI has replaced anyone, but because AI has removed the barriers that kept us trapped in our lanes.

What You Can Do About This

If you’re reading this and feeling excited, good. You should be. If you’re feeling a bit overwhelmed, that’s normal too. This represents a big shift, and navigating it isn’t always straightforward.

So what can you actually do about this? First, start small. You don’t have to transform yourself overnight into a fully-formed product engineer. Next time you get a ticket, ask why. Challenge the problem being presented to you. Propose an alternative approach. Talk to a user before you start building. These are small steps that add up over time.

Second, build the skills you’re missing. Maybe it’s Discovery. Maybe it’s Design. Maybe it’s understanding business metrics. Pick one area and try to get one percent better every day. Once you feel more comfortable, pick another skill to develop. Progress compounds when you’re patient with yourself.

Third, and this is crucial, find the right environment. Not every company is ready for this shift, and some will fight you every step of the way. You can look for green flags that indicate a company might be fertile ground for product engineers. A ratio of engineers to non-technical people that skews heavily toward engineers is a good sign. Engineers being involved in product decisions matters. PMs who are seen as enablers rather than controllers. Flat hierarchies and trust-based environments. These are all important ingredients of a culture where product engineers can actually thrive.

The Shift Is Happening

I believe this shift is real, and it’s happening right now. The dream that so many of us builders have, of having end-to-end impact on the products we create, is becoming a reality. The walls between roles are coming down, not because anyone decided they should, but because they were never really necessary in the first place.

But we’re learning that there are other ways to scale, ways that preserve autonomy and ownership and the joy of seeing something through from beginning to end. Ways that let engineers be the problem shapers they’ve always wanted to be.

The question isn’t whether this is coming. The question is whether you’re ready to step into it.