Shared services teams often wonder: Does product ownership still apply here—or are we the exception to the rule? In this episode, Brian and Kert Peterson explore how Scrum principles hold up when value isn’t always customer-facing and demand never stops.

Overview

In this episode of the Agile Mentors Podcast, Brian welcomes back longtime friend and mentor Kert Peterson for a deep dive into what product ownership looks like in a shared services environment.

They explore the practical realities that differentiate shared services from traditional product teams, from endless stakeholder requests to the challenge of defining “value” when your users are internal. Together, they discuss the importance of proactive leadership, strategic alignment, and understanding who your real customers are. Kert also shares tools for improving intake, applying an experimentation mindset, and closing the feedback loop, even when your work is abstracted from the business’s end goals.

Whether you’re a product owner in infrastructure, data, middleware, or internal tools, this episode will help you reconnect your team’s work to the outcomes that matter.

References and resources mentioned in the show:

Kert Peterson

#9: Scrum Artifacts with Kert Peterson

#12: Kanban with Kert Peterson

What Happens When For Product Owners

Subscribe to the Agile Mentors Podcast

Want to get involved?

This show is designed for you, and we’d love your input.

• Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.


• Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com

This episode’s presenters are:

Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.

Kert Peterson is an experienced Agile coach and trainer who bridges the gap between business strategy and technical execution. With a background spanning engineering, marketing, and management, he’s helped teams at Amazon, NASA, and Capital One launch Agile practices that actually deliver.

Auto-generated Transcript:

Brian Milner (00:00 )

Welcome in Agile Mentors. We're back for another episode of the Agile Mentors Podcast. I'm with you here as always, Brian Milner. And today I have one of my dear friends with me, Mr. Kert Peterson is back. Welcome back, Kert.

Kert (00:13 )

Thank you, Brian. It's great to be back with you.

Brian Milner (00:16 )

Love having Kert on. Kert is one of my mentors and actually first person I ever came in contact with when I was trying to become a CST. He kind of showed me the ropes and took a lot of time helping me to understand how to do this thing. So I have a huge debt of gratitude to Kert that I can never repay. But wanted to have...

Kert (00:33 )

It's funny, Brian, let me just say I have the same debt of gratitude to Mike Cohn. So it's funny, it's coming full circle.

Brian Milner (00:37 )

That's awesome. That's awesome. So, but we wanted to have Kert on because we want to talk about something that we I know I've heard a lot of questions about in class and it's a big topic of conversation. And that is, you know, when we talk about working in the area of shared services, you know, how does product ownership fit and work into that area? Does it fit and work into that area? Or do we find the exception? Is this the place where product ownership just all of a sudden is not able to provide any value? So Kert, that's a huge big ball of yarn to unravel there, but what comes to mind when you think about this?

Kert (01:18 )

Well, I think back to the origins, what inspired the Scrum framework, which was Japanese product companies in the late 1970s doing things differently, using this sort of rugby approach and getting cross-discipline groups together and seeking to innovate and reduce time to market. So when I think about product ownership arising out of that context, it's very clear, right? There's a printer that I want to get better at. I want to take a Canon EOS Rebel and I want to make the next generation of it, or I want to take the Honda Civic. And I want to improve the way it shifts or whatever. And so there's a lot of clarity. And I think, I would say an easy vision to sort of begin to form and coalesce around the direction we're moving in. And the shared services groups I've worked with, whether it's middleware or data people or cybersecurity folks, they just experienced this constant deluge of requests from a variety of stakeholders, dozens, if not hundreds of stakeholders. And it feels like they're always operating tactically. helping those product owners that they're leading shared services teams to shift out of the tactical and begin to think more strategically and begin to get more, I guess, proactive about how they meet requests and what they're going to offer and how they're going to offer it is sort of a challenge that I think I see many of my customers and clients up against.

Brian Milner (02:37 )

Yeah. I think one of the things I hear quite often about this is it's sort of, you know, cause and for example, a product owner class or something like that. We'll talk a lot about understanding your customers and, and mapping out kind of personas and other things and how that influences our idea of value. And then how you, kind of rank value according to your backlog. And that, that to me is kind of where one of the friction points here in shared services is you've got these demands coming at you. all day, every day from all these different corners and from everyone, it's urgent. From everyone, this is the most important thing. So how can you apply some of this product ownership mindset principle to scenarios where everything is urgent?

Kert (03:21 )

Yeah, you those fundamentals, you know, when something's coming in, how do we weigh it against other opportunities? And usually we want to do so financially. How do we kind of begin to assess this particular request or opportunity against others? And when I teach product owner training in person, I hand out these little plastic covered pictures of currency. So I'll have like a yuan from China. I'll have a euro, I'll have all these varieties of currency and I won't, I make them kind of cryptic. Like I'll choose one from, you know, maybe one from Mongolia. And so I put this currency in front of them. say, okay, rank these in order of value, you know, translate it to U S dollars, which one's most to least important. And they struggle because I don't let them look at their phones and they have to, you know, sort of think or be creative. And at the end of the activity, they realized, wow, I don't have a system for translating this currency into the currency that's universal, which is US dollars. And it gets them, it sort of sets the stage for this idea of scoring, you whether you're using rice or some other scoring method, it sets the stage for that conversation, which is critical. How do you objectively assess what's coming in and make the choice on the next best thing to build? Yeah.

Brian Milner (04:36 )

Yeah, that's a great exercise. I love that because it's a great picture there to understand as a product owner, you can't make those decisions in a vacuum. If you don't have the background, if you don't have the knowledge, if you don't have source information coming in, then no, I can't rank currencies. I've got to have expertise in those areas to help me understand those things. So yeah, I love that exercise. That's awesome. One of the other things I hear quite often in the shared services space is kind of the idea of, maybe this stuff is, maybe Scrum doesn't work as well in a shared services space because of the immediacy of all this stuff. And maybe we have to do Kanban versus Scrum. What's your opinion there?

Kert (05:18 )

When I was at Capital One many years ago, shared services teams were adopting Scrum because that was the only game in town. This was 2005. really Agile was sort of very closely connected to Scrum because the Scrum and XP communities sort of were the members of the Agile Manifesto. And what Scrum teams end up doing is they say, you know, we're going to have a sprint planning session and we're going to plan 10 % of our capacity for something that is doable. And we're going to reserve 90 % for unplanned work. that's coming at us. And I see Scrum teams that retain Scrum and that want to leverage Scrum for shared services really just allow for a huge buffer of flexibility. But they also start to get curious about, you know, over the last two weeks, we left 90 % of our capacity open. We used all of it. And here's the top three, you could say offenders, right? Top three requesters, top three