Boundaries Between Product & Engineering

Hi, folks. This is all things product with Petra Villa And Theresa Schwartz. And we're so happy you're here. Theresa, 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 the 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, 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, even matters. So, like, they're literally putting in their sprint planning. We need to rearchitect this very specific component because it's blocking engineers. Sometimes engineers or product managers are even getting into, like, architecture system design. And I think this is all a problem. Like, we there's a 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, 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 wanna unpack a couple of these examples. If an engineering team was the 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 wanna 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. Mhmm. We create tickets. They deliver those tickets. And it's led to this this, like, order taker mindset of I'm just gonna tell you literally what to do, and …