Practical Applications of the Agile Product Operating Model (APOM)
On this episode of the Scrum.org Community Podcast, Dave West welcomes Professional Scrum Trainer Bogdan Onyshchenko to explore the Agile Product Operating Model (APOM). They discuss how APOM offers a holistic, principle-based approach for product organizations—going beyond Scrum to address team motivation, vendor management, strategic decision-making, and more.
Bogdan shares insights on the importance of transparency, frequent delivery, and self-organization. The episode also gets into balancing prescriptive advice with flexible principles, understanding the “why” behind agile practices, and using APOM as a practical tool for improving outcomes and value delivery.
Listeners will gain practical guidance on applying APOM in their own organizations and learn how this evolving model continues to support teams and leaders in delivering value effectively.
Topics covered:
Defining the Agile Product Operating Model (APOM)
Practical Applications of APOM
Balancing Prescriptive and Principle-Based Approaches
The Importance of Understanding the "Why"
Operating Models vs. Frameworks
Transcript
Speaker 1 0:00
Welcome to the scrum.org community Podcast, the podcast from the home of Scrum. In this podcast, agile experts, including professional scrum trainers and other industry thought leaders, share their stories and experiences. We also explore hot topics in our space with thought provoking, challenging, energetic discussions. We hope you enjoy this episode.
Dave West 0:25
Hello. Welcome to the scrum.org community podcast. I'm your host. Dave West CEO, here@scrum.org Today, I'm with a PST one of our professional scrum trainers. Bogdan arnesh chenko, welcome to the podcast.
Bogdan Onyshchenko 0:43
Thanks for having me. So today
Dave West 0:47
we're going to be talking about the Agile product operating model and its practical application, which is exciting right now for the listeners. Hopefully some of you have listened to other podcasts on this topic a palm we've spent quite a lot of time talking about portfolio planning. Maybe you listen to the Toyota one. We talked about incentives. You may have listened to our friends at Accenture and Demetrius talking about that. So there's been some other podcasts on this. But I wanted to invite Bogdan, because Bogdan and I have been working together now for, gosh, over a year, I guess, on a palm. And it's apple, it's practical application. So I'm excited to have you here, Bogdan, talking about this, so let's kick it off. What does a palm mean for you,
Bogdan Onyshchenko 1:42
blimey, that's a good one. This is the way to release knowledge and expertise that is way beyond Scrum, because normally we mostly talk about Scrum, but when you try to apply Scrum, you always run into this different problems and issues that you have to solve, where you have to organize the team, you have to motivate the team. You have to have some incentives and rewards. You have to deal with vendors and contractors. You have to balance the discovery delivery within the development process. You have to think about strategic decision and small tactical decisions. And it just turns out that to make sure that the product organization is successful, you really must take a holistic view on things. And I feel that a bomb is the way to crystallize all those things that have been learned by myself, by other PSTs, by smart people@scrum.org and put it all together, make some minute out of it.
Dave West 3:06
That's That's an awesome answer, because I was thinking as I asked that, gosh, how would I answer that? And I would answer it a little differently, but I'd end up in the same place, you know, ultimately, to be successful with Scrum and agility in general. You need certain things in the environment you're working in, and those things need to be aligned so they don't undermine transparency, they don't undermine frequently, frequent delivery, empiricism, self organization, all the things that we talk about, and there's many things that do, and what we have discovered as a community and and I'm just writing it down really, and maybe I've had some experiences myself, is that if you don't think this holistically, and you don't think about how These things impact each other, you end up ultimately undermining these teams and not allowing them to deliver on their potential, and and that ultimately means more value, it means more happiness, which then means more value, and then the world is a better place. So, yeah, I think I think you nailed it, and I think that the thing that's so interesting about a palm and is that it it has a perspective on all these things. But of course, all these things might not be aligned, but that's okay. You just gonna, it's gonna have an impact, and it's making sure that impact is more transparent, which is, which is really, really cool. So I loved your answer, but now I'm sorry I put you on the spot. And did you notice listeners? He said, blimey. So that proves that he's been speaking to me a lot, because that's a very English expression. Thank you for that. I appreciate that. Okay, so that was a really nice sort of I. Definition of how what apon means for you. But what do you think it means for people? What are the practical applications of all this work that we're doing around a palm today? For people, I
Bogdan Onyshchenko 5:15
feel that, first and foremost, it would be amazing to have a body of knowledge that encapsulates various different aspects of how product organizations who are successful do operate, and allows anyone to assess themselves and try to understand what they are, good at, what they are potentially could improve. Helps them, say, redefine or define the products in the way to focus on outcomes and value delivery, not some org charts or projects or some systems. It would help drive decisions on portfolio level better. It would suggest the path to change by taking it, one thing at a time, one product at a time, and incrementally moving to a better place, a better spot that you are now at.
Dave West 6:24
That's that's super interesting. Yeah, I mean, that is my dream, that we've got that, and as we've been working on it, it's interesting because there's a lot of advice that is very detailed and very prescriptive, like some scaled, agile framework and those things. I'm not dissing any of these frameworks and ideas less and the like, but what I've noticed is one that incomplete, you know, they don't like I that safe does not have anything on incentives. For instance, yes, there's some written stuff maybe that I now can't get access because it's not of a side of a firewall, but, but the generally, they don't talk about that. They don't procurement. Yes, some people have written some blogs, but there's very little about that. So they're not so it's not complete, but the bits that are there almost too complete for your organization. So what I think you and I have been sort of wrestling with and the community on hold, but obviously it's just you and I talking at the moment is, how do we balance the prescriptive you know, get really down in details and trying, but trying to build this body of knowledge that is complete, but is flexible enough for you for an organization to say, hey, we've got these things, you know, this is, this is how we're doing it. How does that fulfill? And I think we've come to this idea, and it's evolving, is that it's going to be principle based. The white paper sort of alludes to it. But we're sort of moving, moving that way. Principles could provide us with that body of knowledge or mechanism in that body of knowledge to effectively, you know, describe the situation in a way that's not prescriptive, but it is complete enough for us to have to be able to determine whether my organization is working in that way or not. Does that that's how I'm feeling the practical elements of a palm are emerging.
Bogdan Onyshchenko 8:26
Well, you're spot on here, because I feel that principles are to be enshrined in practical applications specifically. So this is not something that someone has invented. There are over 300 PSDs who are lucky enough to be working with different clients all around the globe in different environments, from smaller startups to large enterprises. And as you work and as you observe stuff patterns emerge, and if we see that something is working, and we know it's working, regardless of the environment, then it's probably a good thing that people are doing. Can we learn from that? Can we frame it in a way to help people make decisions based on those principles, that would be a challenge that I think we should be and will be tackling next. But in the essence, it comes down to not inventing stuff, but understanding what works and why it works. How do we generalize it in a way that people can take and apply regardless of their current environment. Exactly.
Dave West 9:48
I mean, it is funny you say, you know, it providing a way that describes these ideas in a mechanism that allows people to effectively say. Okay, that's why, oh, we're not doing that. That might be okay, but this is going to be the implication. And it's funny because scrum has been around 30 years, or coming up to its 30 year anniversary. And I talk to a lot of organizations about Scrum, as you do, and it's funny people go, you say, if you ever ask, why'd you do a daily why'd you do a sprint review? Most people get why they do sprint planning, but you why'd you do a retrospective? It's funny how people have got so focused on the mechanics. And that's true of a lot of these operating model, a lot of the not necessarily operating models, but the elements of operating and they sort of forget the why. It's like the Spotify model, right? Really good set of fundamental ideas. However, if you apply it without thinking about the why, the underlying principle, as it were, and understand that you end up in a bit of, a bit of a mess, and I think it's trying to describe it in a way that allows that. I think it could be an incredibly powerful tool, and we're starting to do that, of course, it's, it is, as you said, work in progress, as it were, all right. So I want to take you somewhere else. Now, a little bit about operating models. Why is it an operating model? Why is a palm What was your take on this? Because I know why I originally did it, and it was quite mercenary. We'll come back to that in in a sec, but or quite fashion oriented. But why do you think operating models when, when it seems quite a cold term, necessarily a very inclusive term, it's an operating model. So why do you think we do that? Why is it called an operator?
Bogdan Onyshchenko 12:02
Hmm, I guess because we are trying to help product organizations operate more effectively, more efficiently, we already mentioned that we must take a holistic view when it comes to how things are done because with a simple butterfly effect, the clip of the winds somewhere in legal department can just result in catastrophic storm elsewhere, and vice versa. So you really have to take a step back away from specific methods and tools and frameworks and look beyond the organizational design, or beyond how you deliver, how you discover the customer needs, or how you leverage technology, unless you take a good look at the big picture and try to understand how it all works together, and see for yourself that you can't leave something unattended, you can't outsource lots of stuff and still hope for technical excellence, because we all know how well it went for Boeing and number other companies, right? So we are trying to underscore one important thing, that if you want to succeed, you must take care about many different things at the same time. Of course, not all of them at the same time, but you have to understand the connections, the dependencies, the boundaries you're operating in the wider company context. And it all has to work together. If there is diluted accountability, if there is siloed structure, if you just outsource risk without thinking about it, then you're doomed to fail. And we've also seen countless examples of exactly this happening, and we are trying to draw knowledge as from the companies teams that succeed, but also try to avoid the mistakes of the companies that have failed. Why did they fail? What went wrong? This is something that we are keeping a close eye on and studying carefully to make sure that whatever a bomb will have will be worth it.
Dave West 14:38
It is interesting talk about failing companies. And fail is maybe a very strong word we live in. Companies get away with it quite a lot when they're not as good as they could be that that obviously can always change it a moment. But it's funny whether it's Sonos, whether it's Boeing versus, you know. SpaceX, whether it you know, when you look at these organizations, it is possible to see the fundamental mistakes that they make, and those mistakes aren't that these companies are all great, you know, companies with great people in them, but the problem is the silos and the disconnection of the model have implications. You know, the Boeing it was, it was a combination of things, or it seems to be a combination of things that basically put their their manned space flight program in a bit of a mess, but, but when you look at it, you know, it's their procurement, the way in which they manage contracts. It's the their underlying project management philosophy about resourcing and people. It's that, you know, you start adding these things up, but they all impact each other, and they create, you know, sort of discord in the overall model. So I like the word model, because, one, it makes things transparent to a model you can test and look at. I think that's an interesting perspective on model and and, and I got Fred up calling things frameworks, honestly, because we have so many of them, Nexus, EVM Scrum, and some of you know other people like Marty Kagan, ThoughtWorks, McKinsey, also have used the framework phrase as well, not necessarily badly, but so I that was perhaps the reason why I initially called it an operating model. All right, so let's finally, and we try to keep these podcasts relatively short, and you and I can talk about a palm until everybody leaves the bar, as proven in other moments, where can people learn more about a palm? You know, there's obviously a lot of content around what, what? What can we do? What can What are you telling your your customers, your your your friends, your random people you meet in the street? What? What are you telling them where they can find out more about the Agile product, operating model.
Bogdan Onyshchenko 17:23
Well, I'm not yet going from door to door with a small Pam flat. Want to talk about the apom and letting it in your life, but getting there slowly. So beyond this podcast, there have been a series of webinars, I think recorded. There was a white paper published. There are individual blog posts that are maybe not yet obviously tied into the whole apom ecosystem, so to speak, but they are related to important things like product definition or portfolio management or something else that might be useful to people. We are, of course, working on more stuff to be produced, but I don't want to spoil any fun, so staying tuned and seeing what else will be published there, being in touch through the social media is one way to keep a close eye on what's coming.
Dave West 18:28
Yeah, I think the Yeah, it's evolving. We are trying to, we're trying to make this as transparent as open. It's not a closed system. It's a community kind of driven event. And the nature of our communities, it can be a little hot and cold as people get involved, do stuff, and then step back and have client work and do other things, and then come back and share their experiences, etc. But that stay connected as this evolves, I think, is great, great words of wisdom. Bogdan, thanks for joining us today and just spending in just a moment, sort of like reflecting on the Agile product operating model and the state of play as it were, and and the why, and giving your perspective, I spend a lot of time talking about this, and it's nice to have somebody else talk about it in a relatively positive way.
Bogdan Onyshchenko 19:28
Thanks for having me, Dave. I'm looking forward to providing people with even more of the stuff that is there in the works. And just to give a little teaser, we have ran survey for the product organizations about how different things work or do not work in their specific environments. We have plenty of responses. The survey is still running, so we haven't, if you haven't had a chance to have. Complete it and share the data with us. Please do so. But otherwise, if you have already done it, stay tuned, because we will be dissecting the information there very thoroughly and trying to bring you some insights that are evidence based, as we'll have to do at ScrumOrg.
Dave West 20:20
Bogdan, I'm sure you'll be back on this channel talking about our observations from that process. Okay, everybody, thank you. Thanks for listening today to today's scrum.org community podcast. I was your host, Dave West, I was fortunate to have Bogdan, a PST based in Poland join us today and talk a little bit about his perspective around a palm and what it means to him. It was really interesting that without any prompting or preparation with I asked him that one question, what does a palm mean to you? And though it was different, which I'm quite grateful, it ended up in the same place as what it means to me. Which is, which is good. If you liked what you heard, please subscribe, share with friends, and, of course, come back and listen to some more. I'm lucky enough to have a variety of guests talking about everything in the area. Professional Scrum Product thinking a palm and, of course, agile. Thanks, everybody. Scrummarg.
Transcribed by https://otter.ai