# Defining Product Engineering Boundaries

**Podcast:** All Things Product with Teresa and Petra
**Published:** 2026-02-24

## Transcript

Hi folks, this is All Things Product with Petra Ville and Teresa Torres.
And we're so happy you're here.
Teresa, we had an off mic conversation the other day, and you shared that something really bugged you.
In a conversation, you got asked from product people about the relationship with engineering.
And they shared that, for example, they report the product people report into the entire organization about a status of bugs, for example.
Or there was one other case you need to remind me of, and you will in a second.
But I think it's really important that we unpack this in this podcast because I see this so often in my coaching as well.
It's a leadership conversation, oftentimes.
So, what is the relationship between engineering and product?
Who is responsible for which part of the work?
How should they collaborate?
So let's dive into that super small topic.
Yeah, so uh this is a big topic, and I think it's a really important one.
Here's something I've seen over my entire career.
Most product organizations decide our prioritizing bugs, which bugs get fixed when.
They're tracking bugs, they're communicating to the rest of the organization what the status of bugs.
They're deciding, some are even deciding how to pay down tech debt.
When tech debt like how to pay down tech debt, what tech debt um even matters.
So, like they're literally putting in their sprint planning.
We need to re-architect this very specific component because it's blocking engineers.
Umtimes engineers are product managers are even getting into like architecture system design.
Um, and I think this is all a problem.
Like we there's this saying that historically I've disagreed with, but now I can sort of see the why it's arising.
There's a saying that product managers own like some people say the why, and software engineers and designers own the what.
I actually think the better um way to put this is the product trio owns the what.
Yeah.
And engineers own the how.
And I think this is really important because I want to unpack a couple of these examples.
If an engineering team is a good idea, the other example remind us or remind me of the other example.
Yeah, it was how it was all in the how.
It was a product manager came to me and said, We've written a spec, we've just we've decided our iterations of how we want to get there.
It's a zero-to-one product, but my engineers don't even know where to begin.
They need help with like what are the first components to build.
And I think this is a problem.
Like, it's not product manager's job to know what order of components to build.
And here's what I think is happening.
Historically, we have treated engineers as a cost center.
They're an IT team.
We create tickets, they deliver those tickets, and it's led to this like order taker mindset of I'm just gonna tell you literally what to do, and you're gonna do that.
Okay, well, when we work in an organization where we have evergreen products, they're always evolving.
Um, we have code complexity, we have interdependencies.
Like there, it is not possible for a product manager to also own code quality, system architecture, um, the how we build.
And I think the challenge is we've let these bound this the boundaries between these two roles blur for so long that we're burning out our product managers, and we're not getting good engineering quality.
Like a product manager doesn't have the expertise to decide what order to build components, and so I think there's a few things at play here.
I think we just like in the product world, we have a lot of product leaders today who grew up in a different world.
They didn't grow up in a continuous um product mindset world, they grew up in a project world, and so when they're leading product teams, they have to upskill, they have gaps to close, they have to learn this new way of working.
I think we're seeing the exact same thing on the engineering side.
When engineers grow up on an IT mindset and then they become engineering leaders, they don't realize that like it is the engineering team's responsibility to manage tech debt, it is the engineering team's responsibility to manage bugs, it is the engineering team's responsibility to manage system architecture design.
And when these lines blur, uh when these line when these lines blur, like it leads I think it leads to like a really toxic culture because we're protecting our engineers, like they're not responsible for their own quality anymore.
And all of that is falling on the product manager to defend, and they don't even know why those bugs happen.
Yeah, and it is what so what I can add is so from my personal experience, it is impossible to work that way if you have skilled engineers.
So if you have skilled engineers that you can work with as a product person, they would not allow you to split um the stuff that you want them to build into components or even share with them how you think this the cake should be made, right?
Because they would push back and say, like, hey Petra, please, we decide on the architecture, we plan in how many sprints we need to put all this work.
We have more experience than you to discuss complexity and discuss dependencies and discuss when to fight tech legacy, and and in a really skilled engineering team, I was never even bothered with the question of when they want to fight the tech legacy.
They just did the refactorings because the most senior engineer on the team coached the other engineers on the team how to constantly fight tech legacy, for example.
So it might be a skills gap in an organization where this is a conversation.
Because with the engineering teams that I work with, they would not even have asked me to do all these things unless it involved bigger communication within the organization.
Sometimes they knock my door and say, like, hey Petra, this is something we need a press release to talk about this bug.
It's so big, it is influenced a lot of users for a few days or even weeks.
So we need a communication plan.
We need to decide on when to inform whom.
It's a bit of a ballet to talk about this back being fixed.
So can you help us and step in?
Because you're good in this interface communication thing.
Um, but it was never something that the organization would hold me accountable for, or the engineering team would hold me accountable for.
But I see it a lot in organizations that I'm working with.
Yeah, I actually think this is really common.
And it's because the root of it is there's this belief that the product manager is the interface between the engineering team and the rest of the organization.
Yeah, that person being the CEO of the thing didn't help with that either.
And so now suddenly the product manager is responsible, is responsible for another organization's quality of work.
And I cannot think of another function in business where this is true.
Where one organization, one function is responsible for another function's um quality of work.
And I think um this happens for a few reasons.
I think you're right.
Like the CEO of the product is um metaphor, is a big part of the problem.
And here's what I want to acknowledge like if I'm a product manager on a product, I am responsible for that product.
Which means if it is full of bugs, and every time we build something, we introduce new bugs.
I have a problem.
This is my product that I'm responsible for.
But here's the line I want to draw.
It is not my job to go to the engineers and talk to them about quality.
What's my job is to talk to engineering leadership and surface the quality issue.
And so I want to talk about this.
Yeah, I want to talk about this as a line, like the a literally literal boundary between product and engineering.
Product managers don't manage the engineers on their team.
Rarely, like I know sometimes they do, but I don't recommend that, right?
It's not quality though.
Oh my god.
Yeah, it's not like the product manager is the people manager who can hold those engineers accountable to quality.
No, there's an engineering manager that is responsible for that.
And so I think this is where we have to think about it as it is an engineering job to produce quality code, to test their code, to make sure it's ready for production.
And like it's insane to me that like anybody would think this falls on the shoulders of a product manager.
But I'm not saying the product manager can just ignore the problem, right?
They are responsible for their product, but the way they have to solve the problem is by working with the engineering organization, not just like battling with their engineers over it and then being the face to the rest of the organization.
Because like the product manager that brought this up, the one about bugs, he he was like, I don't even know what the answer to their bugs questions are.
So he's literally in a role where somebody is coming to him and saying, hey, what's the status of this bug?
And then he literally goes to his engineering team, gets the status, and then reports back to the person that asked him.
That's a colossal waste of time.
It's a middleman thing, right?
Then it's not modernizable position to be in.
Yeah.
And then oh my God.
Okay, the second example was an organization where they're starting to build a zero-to-one product.
Their engineers don't have experience building zero-to-one products.
So they're getting stuck, they don't know where to start.
And so this is a skills gap.
And this is a skills gap that ideally an engineering leader is helping to overcome.
The challenge is this organization doesn't have an engineering leader.
And again, this is a symptom of the IT mindset.
They've got a bunch of engineers that take orders from the business.
Yeah, exactly.
Um, and so I think this is a part of the like project to product, the IT mindset to product monitoring model.
Yeah.
Like transformation that has to happen.
If you want to have product teams, not IT teams, you need engineering leadership that is helping with managing tech debt, code quality, automated testing, um, CICD pipelines.
Maintain available.
This was, yeah, this was non-existent in these organizations.
And these are product companies, like they're building products.
Um, so that's my little rant.
I feel like this is a good idea.
So you would advise.
Yeah, let's let's make it a bit more actionable, actionable for a second.
So what would you advise these product people to do?
And to some extent, you already talked about fix the system, not the any particular bug ticket uh kind of setup.
But what should they do?
Because it's given that the engineers that are on their team are the engineers on their team, so they cannot kind of just like wave their magic wand and tomorrow this will be fixed.
So, yeah, how would you go about that?
Because should now these product people start to push for more product transformation within the organization?
Yeah, so for the product manager that had the bug that was being asked to report on bugs, what I suggested was a two-pronged approach.
One, he facilitates setting up a place where people in the business can ask engineers for bug status reports.
So whether that's a Slack channel, whether that's a dashboard, whether that's a bug tracking system, don't care.
But the key is he can facilitate that connection rather than being the middleman.
And then the second prong was: I don't think that's enough.
You there also is clearly a code quality concern, and he needs to be escalating that with his engineering leaders about how do we improve the quality of our code overall.
Yeah.
Did we, by the way, record a quest um an episode on escalation?
Maybe that's something we should do in the future.
I have a lot to say about it.
Yeah, let's do that.
Thanks, Teresa.
Amazing.
Thanks, Petra.