Why Your Product Owners/Managers Can't Say No

Help me think through how this episode applies to my situation. Start by asking what I am trying to change. Separate the episode's claims from your suggestions, and say when the notes do not support a claim. Use the transcript to find passages, then check the audio before quoting. Transcript: https://yuvalyeret.com/podcast/episodes/why-your-product-ownersmanagers-cant-say-no/transcript.md ## Published episode notes In hardware-software companies, life sciences, and industrial tech, a familiar pattern emerges: a platform team serving multiple internal customers, one product owner caught between competing roadmaps, and no one with the standing to make the tough calls. In this episode, Yuval unpacks why this happens, what it costs, and what a more workable structure actually looks like. What you'll hear: Why platform teams often end up without real product leadership even when someone has the product owner title The difference between having a title and having organizational standing How escalation patterns are usually a structural signal, not a performance problem One approach to giving platform teams genuine product direction , and why it's usually less disruptive than it sounds From Shared Service to Strategic PlatformIf your platform team stopped shipping tomorrow, what would happen to your other products? If the answer is trouble , that team is one of the most strategically important things in your portfolio. It just doesn't look like it because it doesn't have a price tag on it. Strategic things need real ownership. This is part of a three-episode series on product ownership topology considerations in the trenches: Episode B (this one): The internal platform problem Episode A: One product, one team , who actually owns it? Episode C: Multiple teams , when do you need more than one product leader? About Yuval Yuval Yeret helps midmarket and scaleup leaders shift from product development and business growth friction to impact through nuanced product thinking and agility applied in the tech/product org and beyond. For more insights check out www.yuvalyeret.com/insights Follow Yuval's Linkedin – https://www.linkedin.com/in/yuvalyeret/ ## Transcript This transcript was edited from automatic speech recognition for readability. Speaker turns may be wrong or absent, and it may contain recognition errors. Check the audio before quoting or attributing a passage. Episode: https://yuvalyeret.com/scaling-ai-podcast/why-your-product-ownersmanagers-cant-say-no/ ## The friction around leadership You know what's funny? I just spent last week with the client working through something I see come up again and again in hardware software companies. And it's been sitting with me since they've got this platform team software that sits underneath several hardware products and enables using these products. And the team has one product owners essentially getting pulled in five different directions. Each of the platform products or the hardware products is thinking the their roadmap is the priority. Nobody else is. as the authority to actually sort it out. For sure not this product only. So everything escalates. Leadership gets getting dragged into a fertilization conversation. They shouldn't need to be in which slow everything down. And the platform came just, you know, hops from one request to the next and most of the time tried to context which too many of these things at the same time because they struggled to say no. Hi everybody, I'm Yval. Welcome to Skilling with Agility. The situation is worth unpacking, because if it's on some media, there's usually a pretty clear reason that it's happening. Here's the dynamic I often see that creates this. When a product is platform facing, when it serves internal customers, rather than going directly to market, organizations often treat it as a technical technical concern rather than a product concern. It doesn't get real product leadership. It gets somebody on the engineering side who's maybe assigned the product on a roll because nobody on the product management side is interested in it. And the engineering person is expected to figure it out. ## What is really happening in the system But figuring it out means making some tough calls. Which hardware product gets prioritized this quarter? next month, we shouldn't have commitment do we need to push back on. What are we not going to do? And those are business decisions. They're not technical decisions. Somebody without organizational standing, without proximity to the strategy, without a seat at the table, where the prioritization of the hardware products gets discussed, that person can't make decisions that stick, even if if they're making the right call technically. So what happens instead is a lot of informal escalation, a lot of power dynamics playing out in the background. The, this engineering oriented product owner, or technical product owner ends up collecting requests, trying to sequence them reasonably, getting over old and escalating and, and the cycle repeats. The, the platform team ends up functioning more like a shared service, taking requests from whoever, as the most urgency or the loudness, rather than a team with the real product direction. A useful question to think about is, if this platform team stopped shipping tomorrow, what would happen to the hardware products? If this platform team doesn't ship the feature that the specific hardware product need, what would happen, what would be the cost of that delay? The answer is that most of these hardware products would really be in trouble. That the platform is genuinely central to the ability to deliver value to customers. And it's one of the more strategically important things in your portfolio. It just doesn't look like it because it doesn't have a price tag directly attached to it. It's not a direct P&L. Strategic things tend to need real product ownership. Not just someone to manage the backlog, but someone with the standing to make trade offs when five stakeholders all say they're the priority. One pattern that I have seen work well is to connect the platform more directly to the product leader who's responsible for the hardware portfolio as a whole. ## The practical shift Not necessarily to take on all the day to day product ownership work, the team should handle a lot of that, but to own the roadmap direction to be the real owner of this product, to be the person who makes the tough calls when internal customers are in conflict. It's typically the person that really makes these calls, eventually that should actually be the owner. The thing is that in most organizations that senior leader, even though they're already making these calls informally, they don't think it's their role to be the owner for this team. Making it more explicit in my experience, at least, doesn't have much work for that leader. It just removes a lot of ambiguity for everybody else. The team knows who owns the direction. The eternal customers know who to bring their priorities too. And that product owner will not be stuck in an impossible position of being accountable for decisions they don't have the standing to make, because they actually have the responsibility and the standing that fits the accountability that they have. And that's a meaningful shift from a team that manages requests to a team that has genuine product direction. One example that I've seen in the past is where the CTO was actually the owner of such a platform, because it was so strategic for the organization. And that works as well. It's not necessarily somebody from the product organization, but it should be somebody that has the standing to make real prioritization decisions. What tends not to work is to leave things ambiguous. A platform team that's technically owned by engineering is strategically important to every product line, but no one clearly accountable for its direction, know directly responsible individual for its direction that has the say to actually do something about it. That's a setup or ongoing friction. Not because these people aren't capable, but because the structure, the ecosystem doesn't give them the standing to actually steal. So the question worth asking yourself is look at your organization who actually has the standing to say no on behalf of your platform or to shape its real direction, not who's supposed to in theory, who actually can in practice when two internal customers, two products that depend on it, are both saying their deployivity and in parallel, you want to drive a product strategy on the longer horizon. If the honest answer isn't clear, that's usually where the installations are coming from. If the honest answer is that it's the CTO or the CPO or the CIO, then maybe there's something there. ## What leaders should pay attention to If you're working through something like this, I'd be happy to hear how you're thinking about it, what are your considerations, how have you tried to solve it as it worked. Let me know. Next episode, we'll go back to the basics. One product, one team, and why even that setup can create more confusion that you'd expect, especially in organizations that do have a complex hardware software product and product management organization that is struggling to both be outbound facing and inbound facing. I'm evolved. See you soon. ## Source boundary These are the published show notes from the podcast feed. They are a starting point for discussion, not a verbatim record of the conversation. The transcript is machine-generated and may contain errors or unlabeled speakers. Check the audio before quoting anyone.