Subscribe
Share
Share
Embed
AI is writing code. But can it replace the engineer who understands the customer? Here's why Product Engineers are the future — and how to become one.
--
Every software engineer is feeling it right now — the anxiety. AI and software development are colliding fast: AI is writing code faster than us, junior roles are disappearing, and every week someone claims they replaced their entire engineering team with a chatbot.
But here's what the headlines miss: the engineers who understand customers, own decisions, and drive outcomes? They're not just surviving — they're thriving. That's what a Product Engineer is. And in this episode, I share everything I've learned over four years of researching this shift, and why I'm convinced product engineering is the answer to the question every developer is asking: how do I make myself irreplaceable in the age of AI?
👍 If this resonates, hit like — it helps more engineers find this.
🔔 Subscribe for weekly research on product engineering, tech careers, and the future of software development.
---
TIMESTAMPS
00:00 Every Engineer Is Scared Right Now
01:30 How I Felt Replaceable Before AI Even Existed
03:00 The Origins: Product-Minded Engineers, Empowered Teams, and the Product Trio
08:00 What Actually Is a Product Engineer?
14:00 How Product Engineering Teams Work (PostHog, Zen Educate, Andsend)
22:00 AI Didn't Create This Trend — It Just Made the Gap Obvious
25:00 How Leadership Has to Change
28:00 What Happens to PMs?
32:00 Can This Scale? The AI-Native Company Pattern
35:00 What You Can Do Right Now
---
RESOURCES MENTIONED
- "The Product-Minded Engineer" by Gergely Orosz
- Empowered by Marty Cagan
- Continuous Discovery Habits by Teresa Torres
- PostHog — product engineering team model
- Interview with Raquel Smith (PostHog)
- Interview with Martin Pengelly-Phillips (Zen Educate)
- Interview with Kevin Ostlin (Andsend)
- Stefan Schmidt — CTO coach
- Else van der Berg — product leader
- Cursor, MidJourney, Bolt — AI-native company examples
---
CONNECT WITH PRODUCT ENGINEERS
Host: Peppe Silletti
LinkedIn: https://www.linkedin.com/in/peppesilletti/
Website: https://peppesilletti.io
Product Engineers Community:
Website: https://productengineers.com
Newsletter: https://newsletter.productengineers.com
LinkedIn: https://www.linkedin.com/company/product-engineers
---
SUPPORT THE SHOW
If you're an engineer wondering where you stand in the age of AI, or a leader trying to figure out how to structure your team — share this episode with someone who needs to hear it. Drop a comment with your biggest takeaway.
This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit
Product Engineers is the podcast about the convergence of product and engineering in the AI era: what's breaking, what's working, and the craft of doing both well.
Look, I need to talk about something that I think every software engineer is feeling right now, but nobody wants to say out loud.
We are scared, and AI is write code faster than us, junior roles are getting cut, and every week there's a new tweet about some founder who replaced their entire engineering team with code.
And, you know, honestly, I get it. Um, I am a bit scared too. Uh, but I was scared way bef... I was already scared before AI.
Um, like four, four years ago, I was, uh, sitting in sprint planning, uh, playing planning poker with random numbers, building feature I would never hear about again, and I, I had really no idea if anything I built actually mattered.
I felt replaceable. And then AI just made that feeling hit everyone else at the same time. So I decided to go out there looking for an answer, and that's really what changed everything for me.
The engineers who are in sanctions right now, I think are the ones that are... Th- they all have one thing in common. They understand the customer. They make pro decisions.
They own outcomes, and, you know, they're called product engineers. Welcome to the Product Engineers podcast.
I am Pepe, and in this episode, I will be telling you everything I know about, uh, product engineering, what it is, why it exists, and why I generally believe it's the best thing you can do for your career right now, especially if you are a bit stressed about all the AI stuff.
So let's get into it. The Product Engineers podcast. So let me tell you how I got here, because I think a lot of you will kind of relate to this.
Um, you know, a few years ago, I went through some, a kind of a career crisis.
I was sitting constantly in grooming sessions, estimating tasks with random numbers, and then building all this feature, uh, that I would never hear about again.
And, you know, in, in, in the best-case scenario, I would just ship the production and, uh, forget about it, or I would hear back from QA with all the bugs and trying to fix them.
But either way, I didn't have a clue about what impact my job had on, on the users. So that's where the, I started to ask myself, "Am I even useful? What's, what's my real role in all of this?"
Back then it was a bit more quiet because you'd sit there at your desk and thinking, "Well, something is off," you know? But I can't really explain what it is. But now it's everywhere, you know?
Um, every LinkedIn post, every podcast, every conference talk, "AI is coming for your job." You know, learn prompt engineering and all, all this stuff there. It's getting a bit exhausting. But
here's what nobody's saying. The engineers who feel threatened by AI are the ones who were already stuck in that broken system. Think about it.
If your whole job is translating someone else's decision into code, well, I think AI is really coming for that. And also, I mean, that's really exactly what AI is best for, taking instructions and producing code.
If that's your entire value as an engineer, I think you should be a bit nervous. But
if you instead, you understand what you're building and who it's for, what success look like, whether it actually worked, I think AI can't really touch that. AI has no idea who your customer is. It has no judgment.
It has no way to tell if the feature you shipped actually moved the needle or was a complete waste of everyone's time.
And that, that's how I came across the product engineer role, and honestly, it's been one of the best thing that happened to my career.
It made me better at my job, but more importantly, um, kind of stopped me from being afraid. Because once you kind of start owning the outcome and not just the output, you're not competing with AI anymore.
You're, you, you're using it. And I got to know companies like PostHog, where engineers lead product in- initiative end to end, or also ZenEduKate, Unsend, Linear, Ashby, Vercel.
They are all doing it things differently, but the, the same, the, the, they have a core idea which is all the same. Engineers are involved in product decisions.
And, um, I think the engineers at these companies are the ones that are less worried about being replaced by AI.
Before we get into the what product engineers actually are, I want to talk about where these ideas come from, because, I mean, sometimes people act like this appears out of thin air, but I think the smart peoples have always been saying engineers need to be more than coders for years, and AI is proving them right, I think.
For example, back in two thousand and nineteen, Gergely Orosz, the guy behind The Pragmatic Engineer, one of the most famous tech newsletters in the world, wrote a piece called, uh, "The Product Minded Engineer."
And, you know, when I read it, I swear, I, it was the first time I actually felt understood and someone, someone was describing exactly what I was trying to become.
He talked about engineers who are generally curious about the product, engineers who don't just ask how do I build this, but rather why are we building this? What happens if we do it differently?
Who actually uses this, and what do they care about?
And he lists-He lists, uh, I think nine traits and things like understanding business economics, building relationships with PMs and designers, and tracking the impact of your, your work, like after you ship.
And he describes the engineers who actually improve the spec instead of just following it. Uh, really at its core, the, the idea is simple, the point he wants to make.
The, the engineers become force multipliers, and they are the ones where that, uh, PMs talk, uh, first. And here's what it's different now. Every single trait he lists is something AI can't replicate.
For example, proactive ideation, business judgment, cross-functional relationships, post-launch ownership. That's all deeply human stuff. So,
you know, this was kind of an individual side on the, on the IC side, but there's always been... There's also been a movement, uh, more on the organizational level.
And for example, think about Majd Bakar's book Empowered, who made-- where he made a pretty bold case, where he said most product teams are what he calls, um, feature teams, and they get told what to build, and they just build it.
That's it. On the other side, empowered teams, they s- are assigned a problem to solve, and then they go out there and try to figure out how to solve it.
Engineers are part of the process, of course, and they are in the room with the team when the team is deciding what to build and not just sitting around waiting for the how. And
I think if you think about it, a feature team is exactly the kind of team AI is going to replace. So, you know, that's what we do now, right? Here's the spec, just build it. And I mean, that's cool.
Now, now, now Claude can do that. And, and I think an empowered team is a completely different animal. Then we get, um, Teresa Torres, right, uh, who brought the concept of product trio.
So you have a PM, a designer, and an engineer working together on doing continuous discovery. And the, the main point here is that engineers act, uh, participate actively in all the discovery, um, activities.
So from interviews to opportunity mapping and everything. They don't just wait for a ticket to be assigned.
So I think that was a kind of a big deal, and for the first time, someone was saying, "Well, engineers belong to discovery, not just delivery." So here's what's interesting, though.
These ideas are both the precursor to product engineers and also, let's say, a healthy, a healthy alternative, because not every company needs to go full product engineer, I mean, if they don't want to.
Um, but they can still f-function pretty well
with a product trio where, where engineers are generally empowered, and they can, they can influence what gets built and not just, you know, consulted during planning to see how long something is going to take. So
I think it's-- this is already something that makes people already AI-proof. So if you don't, if you're not a ticket taker, right? I think the product engineer just takes this concept and takes it further.
So instead of being one voice in a trio, you can own the, the whole loop. But the, I think the foundation is the same. So engineers who care about the customer, understand business, and refuse to just be code monkeys.
So what's actually a product engineer? I think it's a bit hard to give one answer because every company does it differently. But let me start with why the role exists in the first place.
Here's the uncomfortable truth nobody wants to hear. Product engineer exists because, you know, the way most companies build products nowadays is fundamentally broken, and AI just made this painfully obvious.
You know, just think about y- your typical product team. You have a product manager figuring out what to build, a designer making things look nice, and, um, you know, an engineer writing the code.
Sounds reasonable, right? The problem is that every time you pass information from one person to the next, you have a lot of stuff that gets lost.
Um, you know, the engineer building the next thing knows the least about the actual customer problem.
The PM doesn't understand very well how hard is, it is to build the thing, and every handoff becomes a bit of a game of telephone.
Now, add AI to the picture, and AI can write the code now, and AI can also generate designs, can even draft PRDs.
I think the kind of setup, this kind of setup works when you're dealing with well-known problems and well-known solutions. You can plan it all upfront, right? Follow the plan, ship it.
But, you know, most of what we do in software isn't really like that. You don't know what's going to work until you try it, right?
And when you're in that world, splitting the work across three people who pass notes to each other, it's kind of slow. It lacks the big picture, and it increases the risk of building the wrong thing. Think about it.
Um, engineers understand how complex something really is under the hood, while PMs and designers can't really see that.
So when engineers are kept out of product decisions, all that complexity shows up late, and you start hitting s- things like, "Oh, we didn't think about that," and then you have weeks of rework to, to redo everything again.
So, you know, the really-- the people that should have been involved from the beginning, who could have flagged the problem, were not in, in the product discovery, were not in the meeting where the product decisions were made.
So-That's really what a product engineer is, is someone who keeps all the context in one place, the customer problem, problem, the business goal, the technical constraints, instead of being scattered across three different departments who barely talk to each other.
And that's exactly why AI can't replace them. The product engineer is the person who holds the whole picture together. In practice, a product engineer has,
uh, let- let's say the knowledge, the foundational knowledge of four things.
So figuring out and framing the problem to solve, designing, uh, something people can actually use, building technical solution, and measuring if the impact of the solution. They don't get a ticket.
They, they get a goal. Like for example, let's make this research, um, feature actually return something useful,
and then they can, um, figure it out all the rest, either alone or with help with people from, from the team. And this is where it gets really interesting with AI. AI native teams are staying, staying tiny.
Y- They have like three to four people doing what used to take ten people because, you know, now execution, it's very cheap, and before it was kind of the bottleneck, right? And AI just removed it.
So if you understand the user problem, you can now prototype an UI without waiting for a designer. You can explore customer data without being a data analys-ana-analyst. And,
you know, AI is gonna handle all the execution part while the product engineer can still judge whether the output of the LLM is good or garbage. You know, I think that's really the, the new skill, right?
So getting dangerous enough across product design and tech to solve the problems end to end and directing AI when it's right and calling it out when it's wrong.
And because AI moves so fast, you get also feedback faster too. You can test your knowledge in weeks instead of waiting years to build it up the hard way.
AI doesn't only threatens software engineers, but it also makes it way easier to become product engineers. So I think right now the barrier to entry in this new role, it's been...
is lower than ever, and not many people are talking about that. So [clears throat] does it mean that product engineers are PMs or designers? Uh, well, not exactly.
I mean, they do some part of their job, but I think it means more that you care about the customer and the user experience. You care about the whole thing working together.
You have the tools to see the gaps between the different pieces, so you can tell people, "Look, you know, I think we can do this a bit better." And you know, honestly, I think this is-- this should just be
the, the baseline for any software engineer, because if you can't really think like this, if you can't do this, if your only value is to write code that, that someone else has specced out, I think you're on a borrowed time.
So how do product engineers teams work? Um, I mean, every company I talk to does this a bit differently, but there are some patterns that keep showing up, and the teams that work this way, um, aren't just more effective.
They are the ones where engineers aren't freaking out about AI because, you know, they already know their value goes way beyond writing code. So for example, let's take PostHoc.
Um, at PostHoc, PostHoc is the company that kind of pioneered the product engineer role, and their engineers make the final call. They decide what to build, when to build it, and how to build it.
PMs are there to do maybe research, competitive landscape analysis, metrics, customer feedback, and they help bring in all this information into the context that engineers can use.
But at the end of the day, engineers are the ones that decide what to work on. They work on product problems end to end. Now, think about what happens when, uh, you give someone like that access to AI tools.
They don't get replaced at all. They get super powered. They were already making the decisions, and now they can execute three times faster on top of it.
I spoke with, uh, one of the product engineering leaders at PostHoc, and if you wa- if you want to watch my full interview with Raquel Smith, um, you can watch this video here. Um, then we have also,
uh, Zen Educate, which does things a bit differently. Martin Pengelly Phillips, their VP of engineering, uh, told me something quite interesting. At Zen Educate, product engineers are not the caretakers.
They are problem shapers. They still have PMs and designers on the team, but engineers are in the mix from day one. So let's say when someone comes to them with something to build, they can push back.
They can ask questions like, "Are we even sure this is a problem?" Or, "What does success look like?" And even when they collaborate with design, the designers, they can, um, ask things like,
you know, "We can do this differently," or maybe, "We already have this thing. If we go, these are the ways it's gonna take longer. L-Let's try this shorter thing." I don't know.
I think these kind of engineers, they, they are becoming more dangerous with AI, not less. And if you're interested in my conversation with Martin, you can watch the video here.
There's one company that mapped out their bottlenecks and found they were losing forty days per week in handoffs and waiting. Forty days. I'm talking about Unsend.
And Kevin Hoslin, the CEO, told me that they started with the Scrum, the backlog sprints, designers handing off to engineers, you know, the whole thing.But then they sit down and actually measured how much time they were spending on each activity.
And once they knew the number, that kind of made them do something quite radical. They kind of dropped the backlog completely. And Kevin told me something funny, like he was still sneaking,
looking at this perfectly organized Jira project at night, crying a little that they had to let go of this thing. But once they did, I think everything changed. They built this iteration factory.
So every stand-up is basically a sprint planning for the day, and they call it actually daily sprints. They never talk about feature. They talk about hypothesis to test.
And they can ship multiple times a day per engineer. And every three weeks, they come together for two days to talk about the bigger goals and figuring out what's working.
And I think these are the type of teams where AI anxiety doesn't exist because nobody's job is writing the code. Everyone's job is just to figure out if the assumptions are true. And AI can be a force multiplier here.
It can help testing faster. Kevin also told me something that I really loved, and it's like quoting him.
What has been really interesting is how people that were traditionally very heavy engineers, they knew math, they wanted to do complex algorithms.
Those people might as well be the ones becoming your best UI designers or UX researchers. And it's almost beautiful to see people finding their strength through actually getting freedom.
I think that's really people coming alive because they finally get to use their full brain instead of just the part that writes for loops.
So if you are interested in my conversation with Kevin, you can watch this video here. Now, it almost sounds like product engineers are these lone wolves doing all the product alone, all these activities alone.
But I think they should not really work alone. Kevin from Ansen tried this, and it didn't go very well because the product started to go in many different directions.
So what they implemented is something called product groups. So it's teams of two to three people who own a problem end-to-end. So they research together, design together, build together, mission together.
So it's like pair programming, but for the whole product development cycle. And the good thing is that there are no end-offs here because there's nothing to end off. So what's the role of AI in all of this?
Does AI create this trend? Well, no. Postdoc has been hiring product engineers since 2020. There was also Ghosts and Linear who were doing this before ChatGPT even exists. And the ideas have always been there.
The thing is that AI kind of blew the gap between product and engineering roles.
You know, before AI, working as a product engineer would have been a bit more difficult because you needed to talk with customers, synthesize insights, prototyping was expensive, and learning new skills out of your comfort zone was quite slow.
And there was a real barrier there. But now you can really prototype a user flow in hours instead of days. You can pull insights from customer research way faster.
And this is where it gets really interesting for the anxiety question. AI didn't just make product engineers faster. It made the old way of working obviously broken.
If you're still a feature team where a PM writes the spec and you have a designer mocking things up and you just code it, I think AI just made each of those end-offs feel kind of pointless.
I think the question isn't really who has the skills anymore, but who owns the outcome. And that's the whole product engineers thing at the end of the day. That's literally the job description.
So while everyone else is figuring out now, you know, what am I going to do with AI? Am I going to be replaced?
Product engineers are just doing more of what they were already doing, but a bit faster and more efficiently. So you may be thinking, how does leadership changes with product engineers?
If engineers own product decisions, what do leaders even do now? This is, I think, the part that most companies get wrong. And honestly, it's the part that explains why so many engineers are anxious right now.
But leadership kind of creates anxious teams. I asked this question to Stefan Smith, a CTO coach from Amazing CTO, and he gave me a really, really interesting perspective.
He said, what matters right now is real leadership, which means setting up a direction and trusting people to get there rather than telling them what to build. And most companies have always been terrible at this.
They've been weak on vision, weak on strategy, and they just react to whatever the competition does.
And, you know, when that's your leadership style, of course, engineers feel like replaceable cogs because nobody ever gave them anything meaningful to own. Raquel Smith from Postdoc put it in more practical terms.
She said something like, the key for working with product engineers successfully is being crystal clear about who owns the decision. At Postdoc, engineers make the final call, and that's not negotiable.
But, you know, that clarity is exactly what makes it work.
Once everyone knows who decides, there's no confusion anymore, no power struggles, no endless meetings trying to reach consensus.Um, you know, the leaders are there to set the context, and then they get out of the way.
So instead of building approval layers and sign-off chains, they run a process called trust-over process. They trust engineers to make the right call, and when things go wrong, they don't blame them.
They expect you f- no, to learn from them. So you ship something that doesn't work, that flops, fine, just don't do it again. I think that's exactly the kind of environment where people stop being afraid of AI,
and, um, because they, they can just make mistakes. They can try new things, weird stuff. They can do more than they were doing before.
So if you're a leader and your engineers are anxious about AI and their future, I think that's on you, really. Give them ownership, give them a real problem, give them trust, and watch these anxieties appear.
So you may be wondering, what's then the relationship between product engineers and product managers because there is a lot of overlap now, right? Are they taking on product responsibilities?
And then what happens to PMs? Well, this is one thing that makes people a bit nervous, and I get it because
LinkedIn f- is full of "PMs are dead" statements, but, you know, that's not really what I'm saying, even though what I'm gonna say is gonna be slightly uncomfortable.
I think the PM role as we know it, as most companies have been doing it, it's been kind of a mistake. Um, you know, th- th- that's because
w- we took the most important work, which is understanding the customers, making calls under uncertainty, and having the big picture, and gave it all to one person. I believe that the, the role needs to change a bit.
Uh, PMs need to become, um, like a compass for product engineers. They should help the team know if they're headed the right way but without picking the destination.
Their job should be to share context and not owning the roadmap. So, you know, uh, think about this in this-- thi- think of it in this way.
The PM's job is to make the product engineer smarter and not to tell them what to do.
There's actually a very nice quote from Martin from Zety and Educate who said bluntly, "If you have engineers, you can build and maintain a product without anyone else.
PMs and all management in general is overhead, and the, the job of PMs and leadership and management should be to make engineers more efficient and faster and not creating obstacles."
So I'm sure you're thinking now, "Well, this is all great, but I'm sure this is only for startups. It w- it will never work for bigger companies." And this is a common concern which I understand.
Um, look, I think it's a fair question. There's not much data on this because it's a fairly new role in, into the industry, so I can just give you my two cents about this.
So I think the job is not gonna really change at scale. Um, what's gonna change is the scope. So
at a startup you may have a product engineer who owns the whole thing or the whole domain, uh, while at a bigger company they will be owning a smaller product outcome. It's a, a bit the same as product managers, right?
A PM at a startup has a bigger scope. They, um, work on multiple product initiatives, while at Google they, um, I dunno, they are assigned at how well a button performs if you change the color, right? [laughs] So
I think the principle scales even if the s- scope shrinks. But h- here's where it, it gets wild. Uh, my friend, produ- product leader Els van den Berg pointed out something that really blew my mind.
Um, if, if you see AI-native companies, um, they are showing a completely new pattern. Um, they have tiny teams with huge results. For example, Cursor hit 100 millions in revenue with just 12 people.
Midjourney did 200 millions with 40. Bolt went from nothing to 40 million in five months with about 20 people. And if you remember, at a certain point, um, growing headcount used to be kind of a flex,
and now it's kind of embarrassing. And, you know, I think really these companies, people working at these companies didn't have much anxiety ab- about AI because every person on the team, every person
working there owns something real, and that's really-- and there's zero room for passengers.
So what if there is already a big company that wants to change the way they work so product engineer can thrive in their, in their, uh, organization?
Unfortunately, I believe it's quite difficult, uh, because the bigger companies are the ones where you find people that tell you to stay in your lane, uh, that don't want you to touch y- your own little garden.
So-- and change is one of the most difficult things to do in an organization, most of all if it's huge and there is a lot of bureaucracy and politics.
So yeah, mm, I am not very, uh, convinced that something like this can work if there is already a big established company. All right.
So before wrapping up the episode, let me leave you with something that you can actually do because I don't want you to feel just like, "Okay, this was an interesting episode."
I really want you to, to change how you think about y- your career. Um, let's say if you are an engineer who's anxious about AI taking your job, I think that feeling is awful but very useful. It's telling you something.
It's telling you that your current way of working isn't working, and honestly, it never really worked.
You have been always undervalued.You were already disconnected from the impact of your work, and AI just made it impossible to ignore. So here's what you do. You start small. Next time you get a ticket, ask why.
You can push back on the problem. You can try to suggest something different. Of course, do your own work before. You can, if you can, try to talk with a user before writing a line of code.
I, I believe you don't need permission to care about the product. You never did. And
every time you can do this, you're building the one thing that AI can't really replace, which is judgment, product judgment, the ability to look at a problem and know what matters and what doesn't.
So find the right place, of course. Uh, not every company will want this, and if I can give you a tip on how to identify these companies, you should have a lot of engineers compared to non-technical people.
Um, engineers should be involved in product conversations. PMs, um, will be helping engineers making product decisions instead of gatekeeping. Uh, you know, flat structures, a process where trust is everything.
If your company where you're working right now doesn't have any of these things and it doesn't want them, I'd be a bit worried. Um, if you can, just leave. Please leave.
Go work for a startup because life is too short to be anxious at a job that's making you replaceable. If you're a leader instead, don't just rename everyone to product engineer and call it a day.
Just make it like a promotion, like, uh, CTO coach Stefan Schmidt recommended to one of his clients. Set a high bar and give your people vision and strategy and direction because that's what they actually need from you.
They don't need tickets to be implemented or road maps, but, you know, they need direction. The best thing you can do for your team's AI anxiety is give them something mean- meaningful to own.
If you enjoyed this episode and you want to go deeper, um, you can find all the interviews and articles at productengineers.com.
And please, if you are on YouTube, subscribe to this channel, and if you are on a podcast, um, streaming platform, please follow and leave a good review.
Look, I started this episode saying that every engineer is a bit scared right now, and I think that's true, but I also think it doesn't have to be.
Um, you know, the engineer who understand the customer, who make product decisions, who own outcomes, I think they are excited because AI make them more powerful.
And the dream us builders have had all along, you know, to own the whole thing, you know, from problem to solution to impact, it, it, it has become real. It's becoming real.
You know, the walls between roles are coming down finally because, in my opinion, they never really made sense in the first place, and AI is that thing that is finally making everyone see it.
So product and engineering are converging. The only question is, are you going to be part of that, or are you going to sit there waiting for the next ticket while AI writes the code faster than you ever could?
I personally know which one I'm choosing. Bye.