Product Owner Patterns - From Absent to Exceptional | Salum Abdul-Rahman

Summary

Scrum Master Toolbox Podcast: Product Owner Patterns – From Absent to Exceptional with Salum Abdul-Rahman

Date: August 29, 2025
Host: Vasco Duarte
Guest: Salum Abdul-Rahman
Episode Focus: A deep dive into product owner (PO) patterns—examining the detrimental effects of absent POs and the transformative qualities of exceptional ones, grounded in real-world Agile team experiences, especially in the public sector.

---

Episode Overview

This episode explores the spectrum of product owner behaviors and their impact on Agile teams. Salum Abdul-Rahman, an experienced Agile coach, shares stories highlighting a frequent anti-pattern of the "absentee PO" and contrasts it with the qualities of exemplary product owners he’s encountered. Together with host Vasco Duarte, they dig into organizational obstacles, cultural baggage, and actionable strategies for supporting product owners—especially in high-stakes public sector environments.

---

Key Discussion Points & Insights

1. Product Owner Anti-Pattern: The Absentee PO

• Definition:
  The most common anti-pattern in the public sector is the absentee product owner. These are specialists who are already fully engaged in another role and only allocate 10-20% of their time to PO duties.
• Consequences:
  • POs lack the bandwidth to be effective.
  • No time or support to develop necessary skills.
  • Projects suffer from lack of decision-making and prioritization.
• Salum’s Approach:
  • Salum would "book time in their calendar" and walk them through basics like backlog refinement and user stories:

    "It was very, very, very kindergarten style learning of 'we'll do this backlog refinement thing together. And this is how you use JIRA and this is what a user story is.'"
    (Salum Abdul-Rahman, 03:35)

  • These POs often saw their job as simply transmitting requirements, not actively making decisions.

    "It was not just passing requirements from stakeholders, but actually making decisions. And making decisions is hard."
    (Salum Abdul-Rahman, 05:12)

• Cultural Challenge:
  • Decision-making is discouraged in traditional hierarchies.
  • Many organizations create layers of committees, slowing down necessary PO action.

    "You need a committee to talk about the multiple possible outcomes and then another committee to make the final decision and then another committee to validate that the previous committee made the right decision."
    (Vasco Duarte, 05:50)

2. Role of Scrum Master and Agile Coach

• It often falls to Scrum Masters and Agile Coaches to provide the necessary guidance and hand-holding:

  "It's very important to recognize the importance of roles like Scrum Master and Agile Coach, because you do need to do this hand holding if you want to bring that product owner into the software development process."
  (Vasco Duarte, 06:59)

3. What Makes an Exceptional Product Owner

• Salum’s Best PO Story:
  • Salum worked with a PO who had a PhD in data science and was extremely systematic, particularly in working with stakeholders on a data visualization tool for the public sector.
  • Key qualities:
    • Decisive from the outset (no hand-holding required).
    • Highly analytical, always focused on meaningful metrics—even in environments (like the public sector) where monetary feedback doesn’t exist.
    • Bridged the abstract (“changing the world”) with the concrete (stakeholder communication, value metrics).
    • Engaged cross-sector stakeholders, facilitating communication between private and public entities.
    • Could translate high-level value into actionable guidance for teams.
  • Notable Reflection:

    “You have to talk about how we're actually changing the world. Like, what is the value we bring to society, what is the value we bring to our users to make it meaningful for the team?”
    (Salum Abdul-Rahman, 11:04)

• Challenge in Value Communication:
  • Many POs default to reporting metrics, but it’s critical to connect those numbers to real value and context for the team.
  • Host Perspective:

    “If we don't have this clear vision of what the value is, we're going to make many of those decisions wrong, not because of lack of competence, but rather because lack of understanding of what is the value and who are the stakeholders that we are serving.”
    (Vasco Duarte, 13:37)

4. Abstraction, Decision-Making, and Impact

• Multi-Layered Complexity:
  • Decisions made at each abstraction layer (dev, design, ops, business) can have enormous, systemic impacts.

    "The decisions made on different abstraction layers can have like large systemic effects on the other layers and eventually to business and value and project and even people's health and well-being."
    (Salum Abdul-Rahman, 14:08)

• Developer Needs:
  • Developers, designers, DevOps engineers depend on PO clarity to make sound, value-aligned decisions.

---

Notable Quotes & Memorable Moments

• On Systemic Change (03:00):
  “This is something that has changed on a systemic level, that people understand the role of a product owner a bit better... but I remember working with a product owner that had time for meetings with stakeholders, had time for meetings with the team and nothing else related to the project.”
  (Salum Abdul-Rahman)

• On Decision-Making in Hierarchical Culture (05:12):
  “A lot of organizational culture discourages us from making decisions and helping people to understand that your role is to actually make decisions is really difficult because I think it's disincentivized in traditional hierarchical management.”
  (Salum Abdul-Rahman)

• On the Public Sector and Value (11:04):
  “You have to talk about how we're actually changing the world... what is the value we bring to our users to make it meaningful for the team?”
  (Salum Abdul-Rahman)

• Value Engineering Reference (13:11):
  “[Tom Gilp] talks about the incredible necessity of understanding, defining and even quantifying value, but not only to one stakeholders, to all of the stakeholders... the ability to bring all of these different perspectives into a coherent message that does not feel too abstract for the team is incredibly important because as developers, we're making decisions that affect the value delivered every single day, many times an hour.”
  (Vasco Duarte)

---

Timestamps for Key Segments

| Segment | Timestamp | |------------------------------------------------------------- |------------| | Intro & Anti-Pattern Setup | 01:11 | | Absentee PO Explored (Practical Experiences) | 01:48–05:50| | Organizational & Cultural Obstacles to PO Effectiveness | 05:50–06:59| | Role of Scrum Masters and Agile Coaches | 06:59–08:07| | Transition to “Best Product Owner” Experiences | 08:07–09:14| | Story: The Exceptional Data Scientist PO | 09:14–12:41| | Value Communication and Stakeholder Engineering | 12:41–14:08| | Multi-layered Abstraction, Developer Decision-Making | 14:08–14:43| | Closing Remarks and How to Connect with Salum | 15:19–15:45|

---

Episode Takeaways

• A true product owner must be full-time, empowered, and supported—not splitting attention or acting only as a requirements relay.
• Decision-making is core; organizational cultures must encourage, not stifle, PO agency.
• Great POs bring a blend of strategic vision and practical communication—they quantify and contextualize value, especially critical in non-monetary environments.
• Team empowerment hinges on clarity: Developers and all Agile team members rely on a PO who can translate vision into concrete, actionable guidance across abstraction layers.
• Supporting new, underprepared POs is a key Scrum Master/Agile Coach responsibility.

---

Learn More & Connect

• Find Salum Abdul-Rahman on LinkedIn:
  “If you want to send a connection request, please mention that you found me on this podcast. I don't accept anonymous connection requests, but you can always follow and I post links to whatever thoughts I'm sharing to mostly the public.”
  (Salum Abdul-Rahman, 15:19)

---

This episode is essential listening for Agile practitioners aiming to understand and cultivate effective Product Owner behaviors, especially amid the complex dynamics of the public sector and large organizations.

Transcript

[Vasco]

Hey there, Agile adventurer, just a quick question.

What if for the price of a.

Fancy coffee or half a pizza, you could unlock over 700 hours of the best agile content on the planet? That's audio, video, E courses, books, presentations, all that you can think of. But you can also join live calls with world class practitioners and hang out in a flame war free and AI slop clean slack with the sharpest minds in the game. Oh, and yes, you get direct access to me, Vasko, your Scrum Master Toolbox podcast. No, this is not a drill. It's this Scrum Master Toolbox membership. And it's your unfair advantage in the Agile world. So if you want to know more, go check out scrummastertoolbox.org membership, that's scrummastertoolbox.org Membership. And check out all the goodies we have for you. Do it now. But if you're not doing it now, let's listen to the podcast.

Hello everybody, it is Friday dgif, as they say. And on Fridays we talk about product owner this week with Saloom Abdul Rahman. Hey Saloom, welcome back. Good to be here again to talk about product owners. So Friday we talk product owners and we'll talk about what great product owners do and how they work. But before that, let's dive into something perhaps more scary. Who knows? I don't know what story you have to share with us, of course, the product owner anti pattern. So share that with us. Saloon.

[Saloom Abdul Rahman]

I think the most common product owner anti pattern that I've seen working in the public sector is the absentee product owner. They're a specialist who has been assigned the role of a product owner. But they have, but basically they're already working a full week as a specialist in their own role. So they are designated 10 or 20% of their working time to work on building this software product. But in reality there are no other responsibilities that they have that are taken away from them. So like the initial investment is too small to actually be a good product owner and then they don't have the capability or skill set to actually invest in doing the work or developing the skill set. This is this problem. It's one of those things that when you're selling a project, when you're starting a project with a client, that it should be really explicit that working as a product owner is a full time role. So the practice I've taken is that this is sort of, that we make it clear in the kickoff at the latest, this actually should be resolved earlier, that we need a full time person Somebody who has the capability to do the work. I think this is something that has changed on a systemic level, that people understand the role of a product owner a bit better in the finished public sector. So I'm not hearing about this as much, but I remember working with a product owner that had time for meetings with stakeholders, had time for meetings with the team and nothing else related to the project. So what I started doing was just booking time in their calendar and then organizing like having the backlog refinement sessions with them. And that slowly helped them understand what the job of the product owner actually is. But it was very, very, very kindergarten style learning of we'll do this backlog refinement thing together. And this is how you use jira and this is what a user story is. And they didn't really have time for developing any of those skills. So I had to take it really slowly and just do the work together with them. And slowly, when they started developing the understanding of what their role actually is, then we also needed to do some other things to support them in order to help them understand that it was not just passing requirements from stakeholders, but actually making decisions. And making decisions is hard. I think a lot of our corporate culture, a lot of organizational culture culture discourages us from making decisions and helping and helping people to helping a person to understand that your role is to actually make decisions is really difficult because I think it's disincentivized in like traditional hierarchical management that you need to go confirm with a senior what decision you should make.

[Vasco]

You need a committee to talk about the multiple possible outcomes and then another committee to make the final decision and then another committee to validate that the previous committee made the right decision.

[Saloom Abdul Rahman]

And when we're doing knowledge work, the speed of the decision is so much more important. And when we're working with software in an agile way, we understand that we sometimes need to rework stuff and that's part of the process. And that's very hard for people who are conditioned to work in hierarchical management, work in waterfall type project management to understand that rework is part of the process. And it's a cost. We do, but it's a cost. That means that we get improved learning, we get faster results, we get faster validation of what we're doing. But it's counterintuitive, it's disincentivized by hierarchical culture.

[Vasco]

Absolutely.

And it's a great insight. Right? Like sometimes we need to do the hand holding and hence why we need Scrum Masters, for example, because the manager of this PO is not less busy than they are, they're not going to have any time to teach them, even in the odd chance that they themselves would even know what a PO does, because usually they don' so it's very important to recognize the importance of roles like Scrum Master and Agile Coach, because you do need to do this hand holding if you want to bring that product owner into the software development process and really help the team.

[Saloom Abdul Rahman]

And the product owner needs to understand that their role is to create that understanding that learning that they are capable of making those decisions. Of course, in some situations, I think with a very mature team, the product owner can offload a bit of the decision and knowledge and understanding creation. But even in those cases, the product owner should be responsible for driving to get that decision made on time.

[Vasco]

Absolutely, absolutely.

Salum. This was a anti pattern. But of course there aren't only product owners that struggle. There are many product owners out there that are excellent at the work that they do. So let's explore one of those saloon. Share with us the best product owner you've ever worked with. How did they work?

[Saloom Abdul Rahman]

Well, I've got a couple of options. One of them was that like I was working with a product and unfortunately it got canceled like within two months. But it was really strange to start working with a product owner who was capable of making decisions straight off the bat. I didn't have to teach them that, but I think that's one of those like the fish that got away because we already ended up working for a couple of months and then the product was canceled due to Covid and completely unrelated stuff. But before that I work with a product owner.

[Vasco]

Who.

[Saloom Abdul Rahman]

Had a PhD in data science and we were doing this thing on visualization, visualizing information. And he was extremely systematic about working with stakeholders. It was a public sector project and he had this. And because it was like he was, he had a background of working with data and we were doing a data visualization tool. He was always thinking about like, how do we get the metrics out of this? Because when you're working in the public sector, a lot of the tools, a lot of the stuff you build, you don't get monetary feedback. And that's I think, one of the big challenges when, big challenges when working in product development. And so much of the literature is built on the expectation that we're going to measure this by how much money we make. And there are inherent problems with just thinking about monetization. I mean, of course you need monetization for sustainability, but it can, but as we've seen, it leads to engineification. Lot of products. And if you're not familiar with the word engineification, please Google Corydoctoral and get familiar with all of this work. But when you're working in the public sector, like creating that understanding about what is actually valuable, what value does this product we're building bring? And thinking about how to communicate that and how to make it meaningful for the team is very important. So I've seen a lot of product leads communicate by showing graphs of, well, we've got engagement up by this and we've got this number up by that, and we have internal feedback this and that. But you have to talk about how we're actually changing the world. Like, what is the value we bring to society, what is the value we bring to our users to make it meaningful for the team? And if you're using numbers, you need to be able to explain them to the team. So I think having this capability of bridging the abstract were changing the world with this new tool and this understanding we're bringing. And of course they had the duty to communicate that stakeholders because it had. They had multiple stakeholders from different departments and also from like the private public sector. There's a large crossover in Finland and in some of those institutions. So I think he did it really well. And this is something that I couldn't at that point in my career teach him, though this was something he brought from his own background.

[Vasco]

And actually you make a great point that in businesses, it's not only public, but in businesses or projects where the goal isn't monetization, we need to constantly look for what that explains the value that we are creating, of course, for all stakeholders. And this is an important thing. I interviewed Tom Gilp a few months ago. The link is in the show notes for those who want to listen to that episode where he talks about the incredible necessity of understanding, defining and even quantifying value, but not only to one stakeholders, to all of the stakeholders. He calls it stakeholder engineering or value engineering is the term that he usually uses these days, where he talks about the need to understand that there's a lot of. I mean, and it's not even only people, right? Like the law is a stakeholder as an example. And the ability to bring all of these different perspectives into a coherent message that does not feel too abstract for the team is incredibly important because as developers, we're making decisions that affect the value delivered every single day, many times an hour. Right. And if we don't have this clear vision of what the value is, we're going to make many of those decisions wrong, not because of lack of competence, but rather because lack of understanding of what is the value and who are the stakeholders that we are serving.

[Saloom Abdul Rahman]

I think software is very fascinating because we work on so many abstraction layers and the decisions made on different abstraction layers can have like large systemic effects on on the other layers and eventually to business and value and project and even people's health and well being. And in order for the developers to be able to make the best decisions at the level they're working, the DevOps engineers, the designers, they need to understand what is the value we're going for here.

[Vasco]

Absolutely.

And when we talk about abstraction, this is very important point that you make, we also have to humbly recognize that we need to bring all of those abstraction layers into a very concrete machine that only works with ones and zeros and only does deterministic operations.

Yeah, absolutely.

Well, that was a great story and a great insight about a great product owner. Salum, thank you for sharing that. Now we're getting close to the end, but before we go, share with us, where can we find out more about you and the work that you're doing?

[Saloom Abdul Rahman]

I think the best place to look for me is LinkedIn. If you want to send a connection request, please mention that you found me on this podcast. I don't accept anonymous connection requests, but you can always follow and I post links to whatever thoughts I'm sharing to mostly the public.

[Vasco]

Absolutely.

Salum, it's been a pleasure. Thank you very much for being with us and for being so generous with your time and your knowledge.

[Saloom Abdul Rahman]

Thank you Vasco, and it's been great getting to know you through Agile Finland.

[Vasco]

Alright, I hope you liked this episode, but before you hit next episode, here's the deal. This podcast is powered by people like you, the members who wanted more than just inspiration. They wanted real tools and real connection to people who are practicing Agile. Every day we're talking access to over 700 hours of agile gold, CTO level strategy talks, Summit keynotes, live workshops, E courses, Deep Dive interviews, books. And if you're into no estimates, we got the pioneers of no estimates in those Deep Dive interviews as well. Agile Business Intelligence, creating product visions, coaching your product owner courses, you name it. You'll get invites to monthly live Q&As with agile pioneers and practitioners, plus a private Slack community which is free of all of that AI slop you see everywhere. And of course, without the flame wars, it's a community of practitioners that want to learn and thrive together. It's the best place to connect with community and learn together. So if this podcast has helped you before, imagine what you will get from this podcast membership. So head on over to scrummastertoolbox.org membership and join the community that's shaping the future of Agile. We have so much for you, so check out all the details@scrummaster toolbox.org membership because listening is great, it's important. But doing it together, that's next level. I'll see you in the community.

[Saloom Abdul Rahman]

Slack.

[Podcast Host/Producer]

We really hope you liked our show. And if you did, why not rate this podcast on Stitcher or itunes? Share this podcast and let other Scrum masters know about this valuable resource for their work. Remember that sharing is caring.