Who Makes the Best Scrum Product Owner?

Neil Benson: [00:00:00] Welcome to the Amazing Applications podcast. This is the podcast for Microsoft business applications builders making amazing applications that everyone will love. 

 Hi there. I'm Neil Benson. And I'm back for another episode of the Amazing Applications podcast, where our goal is to help you slash your project budgets, reduce your delivery timelines, mitigate technical risks and create amazing, agile Microsoft Dynamics 365 and Power Platform applications that everyone will love. 

I hope you've enjoyed some of the recent interviews I've had with the people in our community, building amazing business applications. 

I'm going to try a few solo episodes for a while, diving deeper into some of the topics about how we build our apps. 

This isn't a podcast that's deep into the latest features or news. It's not really a technical podcast for professional developers. But my aim is to help us get into the right mindset for building amazing applications. And I think an important part of that is using an agile approach. 

When it comes to agile approaches, there's a few different approaches to choose from. I'm a big fan of Scrum. 

I adopted Scrum for the first time on a Dynamics project in 2008. And it's been my preferred approach ever since. I did. I did have a relapse and I fell off the wagon around 2010, when I worked as a solution architect at a bank on a traditional waterfall project. That seemed to accomplish nothing except for a lot of documentation in the 18 months I worked on it. 

But that was just one time! Okay. Never, never again. 

Speaking of Scrum, I'd like to congratulate Rebecca Ulvedal Flanagan. A project coordinator at Two-Many in Copenhagen, in Denmark. Rebecca recently completed my Scrum for Microsoft Business Apps online course. And she's ready to take her Professional Scrum Master certification assessment with Scrum.org. Tillykke, Rebecca. 

 On this episode, I wanted to discuss the product owner for our Dynamics 365 or Power Platform application. I've said before that the product owner is the most critical role in the scrum team and the hardest one to fill. 

It's the role that consultants from Microsoft partners often contact me about. Usually because their customers don't understand it very well. If you're a business apps consultant, working with a Microsoft customer and you want to help them understand the product owner role, I hope that this episode, and maybe the next couple coming up, are useful and you can pass them on. 

You can find show notes and resources for this episode at customery.com/040. That's the word customer with a Y on the end .com/040. And while you're on the website, you can click on the 'Send Voicemail' button on the right-hand side, record a short question or a message, and send it in . Your question could appear on a future episode of the Amazing Applications podcast. 

The product owner is one of three accountabilities in a scrum team. The others are developers and the scrum master, but we'll focus on the product owner in this episode. 

The product owner is responsible for maximizing the value of the application by developing the product goal and managing the product backlog. 

Now, the approach of one product manager compared to another varies widely between individuals, between organizations, depending on the application you're trying to build, how large or complex it is, and their previous experience of the person who's in the product owner role. 

A product owner can delegate some of their responsibilities to other members of the team, but they alone remain accountable for those two things, the product goal on the product backlog. 

The entire organization's got to respect the person in the product owner role. That person's got sole decision-making authority. Other people in the organization, other stakeholders, shouldn't be going around the product owner, can't add anything into the product backlog, or prioritize the product backlog without the product owner's consent. 

And it's one person. It's not a committee or a team or a group. Although I've got a good example of that, I'll share with you in just a moment. It's gotta be just one person. 

Product owners in other industries for other products are often known as product managers. I think of Panos Panay at Microsoft who's just launched Windows 11. He's a professional product manager. That's his job. It's his career. He specializes in product management. He's been trained in it and he grows his skill, he grows the size of his team, grows the size of his product, and grows his impact as a career professional product manager. 

That's quite different to most product owners, that I've worked with at least, in my Dynamics 365 and Power Platform projects. Our product owners are almost always first time product owners. They've never held that responsibility before. Often, in fact, our project is the first ever agile project the customer has ever attempted and nobody really knows what a product owner does. 

It might be the first time using Scrum. It might be their first time using Microsoft Business Applications. So there's a lot going on a lot of new stuff happening in the life of these first time product owners. 

Let's discuss the different types of people who might be asked, or invited, to be the product owner. 

And I'm talking here about reasonably complicated or complex business applications that are maybe used by a department, a division, or even the entire organization. The type of application that it takes a team of people several months to build. Maybe even years to build. 

I'm not really referring to product owners for simple applications that are used by a small team. That maybe takes a couple of people a couple of weeks to build. I think the product owner responsibility for small applications is reasonably straightforward. And some of the advice, or the the stories I'm going to share, maybe don't apply so much to those simple applications. So we're talking about complicated, complex, mission- critical sometimes business applications. 

Here are some persona, you know, some characteristics of the types of people who might be nominated to be the product owner in those types of projects that you're working on building complicated and complex applications. 

I'd love to know which one of these people you'd recommend, if you had a free choice and had to choose one person from this list to be your product owner. 

Our first option is Archie. Archie is a business analyst or a systems analyst from the IT department. Archie's familiar with some of the user's requirements. He understands the business processes. And probably some of the business data that the organization works with. He's got some experience working on projects before, so he knows how to manage requirements. He's been documenting and cataloging user requirements and nonfunctional requirements in spreadsheets and things before. He might even be familiar with some agile practices, like writing user stories and using backlog management tools like Azure DevOps and Kanban boards. So that's Archie. That's our first candidate, the IT business analyst. 

Our next is Susie. Susie is a solution architect also from the IT department. And Susie is familiar with the business processes and the application landscape across technology. Susie might've used some agile practices or being involved in an agile project at some point in her recent career. That's Susie, the IT solution architect. 

Then there's Mads. Mads is an IT leader. Again from within the IT or Technology organization. Could be a development manager or an IT director. Or maybe even the CIO, depending upon the size of the organization. Mads is familiar with all the existing applications.  Often somebody like Mads will know many of the stakeholders as well. So he knows some of the different managers in some of the different business areas. 

Then there's Taylor. Taylor is a business analyst, but this time, a business analyst who works in one of the business departments, not in technology. Maybe an operations analyst, something like that. Taylor is someone who compiles reports and supports the business processes within the department. Taylor understands the data and the user's needs. But might not have worked on a project to build a new application before. So not very familiar with techniques such as requirements analysis, writing user stories, or other software development practices. 

Another business person is Arush. Arush is a team leader in one of our departments. He's very familiar with the business processes and business rules. He knows the users and many of the other stakeholders. He knows the existing systems very well, but he's got very little previous experience working on a project to build a new business application, at least, not recently. 

Another business person could be Dave. Dave is a department manager, so more senior than Arush. He knows the other stakeholders very well and is familiar with the organization's history, its hierarchy and its business politics. He knows the current system and probably relies on it to help him run his department. Dave might've had some prior experience working on an IT project before. And he's familiar with the organization's goals and its targets, certainly the ones in his department, at least. 

Then there's Chris. She is a divisional director or maybe a vice president. She's a senior stakeholder for the application. She's got a lot of influence with the other senior stakeholders and the leaders across the organization. She's very familiar with the organization's goals and strategy, But it's been awhile since she worked on an IT project. 

Our eighth candidate is Leslie. Leslie is a chief officer that could be a chief finance officer, revenue, marketing, operations officer, and so on. She's possibly the sponsor for the application and worked on the business case to review it and get it approved. She's helped the organization define its business strategy and its goals. And she's got influence over almost all the other stakeholders. 

Our ninth candidate is Sam. Sam is actually an outside contractor. She's a consultant product owner. She's consulted with the organization for a couple of years, she's connected to the senior leadership team and probably knows them from a previous position. She's worked on several business applications projects for other organizations. And she knows a few of the stakeholders and is somewhat familiar with the business goals, processes and systems. That's Sam, she's our consultant product owner. 

Lastly, we have Mike. Mike is a senior project manager. Big difference about Mike is he doesn't work for the customer organization. He works for the Microsoft partner who's going to be implementing Dynamics 365 and the Power Platform. Mike has worked with this customer organization before. And so he knows something about their systems, their people and their processes. 

So those are our ten candidate product owners. Who would you recommend? 

Archie, the business analyst? Susie, the solution architect? Mats, the IT leader? Taylor, the operations analyst? Arush, the team leader? Dave, the department manager? Chris, the divisional vice president? Leslie, the CXO? Sam who is a consultant product owner? Or Mike from the Microsoft partner? 

I wonder if which of those personas would make the best product owner. There's no right answer here. I think your project could probably succeed with just about any of these candidates as your product owner, but not one of them is perfect. 

Generally though, I find that if you're building business applications. Product owners from the IT or technology departments are not ideal. Probably far from ideal, actually. They're great if you're building something like an enterprise service bus or an integration platform, and their customers are other developers or other development teams. They're not great if you're building a business application for your business users. So let's try to avoid a product owner from the technology department. 

Similarly, I think there's too much of a conflict of interest for Mike from a Microsoft partner. Having him act as the product owner, he's got too much of a vested interest in maximizing the goals of that Microsoft partner organization and not the customer organization. So having the Microsoft partner supply the product owner for your business applications project normally doesn't work out very well either. 

The more senior, experienced candidates are likely to have greater decision-making authority. Which we've said earlier on is really important for a product owner. They're going to be more familiar with the organization's goals and strategy, which is great. And they're going to have the trust of the other stakeholders. 

But often they're not going to be as familiar with the business processes and rules. The existing systems and the business data. And they're probably not close enough to the users to know what they want and need. 

I've found one of the biggest constraints of a very senior or experienced product owner is their availability. Not many Microsoft customer organizations can release a senior manager, a VP or an executive so that they can span at least 50% of their time devoted two product ownership in our scrum team. That's a big ask. And it doesn't often happen in a Microsoft customer organization. 

Less experienced, less senior candidates are likely to be closer to the users. Have an in-depth understanding of their business processes and the business rules. They know quite a lot about the existing applications and the business data.

It's also likely that we can free up their capacity and devote their time to our business applications project. But, the downside is that they might not have sufficient decision-making authority. They probably don't have the complete trust of the senior executives in the organization, who might not even know our candidate at all. And they probably don't have sufficient influence with the other stakeholders who are also probably senior to them. 

Let me share some stories about some of the product owners that I've worked with on some of my more successful case study Microsoft Dynamics and Power Platform projects. 

One of the early ones was Debbie. In fact, this was my first one. This is my first Scrum project from back in 2008. Debbie at Premier Medical Group. Debbie was the operations director. She had a very senior role. She sat on the board. She was trusted by them to lead the operations department, which operated the contact centers. And, you know, well trusted both by the board of directors and the outside investors. So they had some venture capital investors sitting on the board, trusted Debbie to do a good job. Trouble was that Debbie didn't have sufficient capacity. She wasn't in the same building. She was in the same city at least. But didn't have sufficient capacity to devote a lot of time to the scrum team. She was supported by Ben who was quite a junior business analyst at that time. He's gone on to do great things. But some of Ben's decisions, in the cut and thrust of the day to day decision making that the product owner's got to do probably didn't align perfectly with the way Debbie would have called it. That led to some changes in the product backlog. So some decisions getting reversed or amended after an increment has been built, but overall it worked pretty well. So, good combination, senior executive stakeholder supported by a business analyst. 

Another example is Peter at Guy's and St. Thomas's hospital. Peter was a senior engineer from the Medical Physics department. And trusted by the department head to lead a pretty small project to build a relatively complicated, but not an overly complex application, to manage the assets. Like all the medical devices and machines across the hospital. He had a small scrum team of just two developers, myself and Greg. Shout out to Greg, if you're listening. And devoted about half of his time to the project while holding down his day job. Peter sat with us in the technology department for most of the week and was available to answer questions. So a good example of an operational analyst or maybe a department manager devoting his time to the Scrum project. That worked really well. 

Then there was Beth at Advantage Solutions. Beth was the Director of Account Services, she looked after all the large supermarkets. And we were building a complicated application, complex application for scheduling demonstrations and sampling, you know, free cheese, giving out samples of wine and ham and all sorts of other products in supermarkets. She was senior. She managed most of those accounts for the organization and trusted by all her peers. Great thing about Beth is she was co located in the same building as our scrum team in El Segundo in California. Beth was supported by some subject matter experts. She didn't need them very often. She was, she knew a lot about the business. But when she needed detailed answers about business processes, or like things worked out in the field then she had some subject matter experts to tap into from across the United States. She was also supported by Victor, a director of technology who had an in-depth understanding of the application we were enhancing and the other systems integrated with. 

Then there was Steve at American Homes 4 Rent. Steve was the Director of IT, and kind of forced into the product owner role to mediate between Carrie and Bryan two senior vice presidents of different divisions who were competing for the scrum team's attention. Steve tried his best but in hindsight looking back on it, a few years later, I think we should have split the team into two scrum teams each with a divisional product owner. One building a product for Carrie, another building a product for Bryan. They would have had their own backlogs delivering different increments into the same Dynamics environment that might've worked better, satisfied more stakeholders rather than the constant friction that Steve had to deal with trying to satisfy too many stakeholders. 

Frieda at the University of New South Wales was one of my first product owners here in my projects in Australia. Frieda is an example of a consultant product owner, hired by John, the Director of Student Services to lead a multi-million dollar, multi-year CRM project for multiple departments and faculties across the university. Freida was supported by a project manager, a team of business analysts, and subject matter experts. She was dedicated full time to the program and she had sufficient character to influence a diverse group of stakeholders. University faculties are notorious for being fiefdoms and running their own little business. Sometimes they have their own technology team. They might've had their own CRM system. And Frieda had the unenviable job of corralling them all into a unified vision and direction and CRM system. She did a great job. She had ultimate decision making authority for the product decisions and a passion for keeping it simple. And as Frieda would say. I'm paraphrasing here, but maximizing the amount of work not done, choosing which requirements not to meet, choosing which features we didn't need to build. 

And my last example is Lizzie at RACQ. Now, Lizzie was one of three product owners on the Jupiter project at RACQ. The program spanned three internal pillars of our RACQ:  assistance, insurance and banking. So we had multiple people with product owner accountabilities. It was, if you like, a product owner committee, which the Scrum Guide, and I!, recommend avoiding. Having a team or committee or a group of product owners. In fact, the three product owners at RACQ answered it to a committee of general managers known as business owners. So there was another layer of decision making. And there was also a technical design authority of IT folks also helping us make technical decisions. So decision making in that kind of environment is often really challenging. Thankfully, Lizzie is a bit of a force of nature and she, somehow I made at work. She's just got a. personality that helps bring clarity to situations. She speaks her mind. She makes decisions. She makes them work. She did a great job as well. 

My amazing product owners might not neatly match one of the personas exactly. And that's the thing about personas. You know, no one's going to ever match the 10 examples I gave you earlier. 

But hopefully you got a glimpse of how product owners from diverse backgrounds, diverse experiences, and diverse persona can lead projects to create amazing Dynamics 365 or Power Platform applications. 

If you're a scrum master or a Microsoft consultant consider the strengths of your candidate product owners or your current product owner. And ask yourself how you can coach them to greatness. Perhaps you need to find them a business analyst to support them and free up some of their capacity. Or they need assistance finding their voice in front of challenging stakeholders. Or they need help clarifying their vision for the product goal or for the requirements. Or they need more decisive prioritization of the product backlog. 

Finally, I'll include a couple of resources for aspiring product owners in the show notes. You'll find them at customery.com/040. They include some of my favorite books, such as:

Product Mastery - from good to great product ownership, by Geoff Watts. I highly recommend the audio book read by Geoff himself. 

Agile Product Management with Scrum, by Roman Pichler, who's one of the leading voices in the Scrum community on product ownership and product management. Roman's also got a really great podcast to listen to. It's called Product Management by Roman Pichler. 

 And finally, there's the Professional Scrum Product Owner, by Don McGreal and Ralph Jocham from Scrum.org. You could also consider the Scrum.org Professional Scrum Product Owner training courses and the PSPO I certification. 

Speaking of training and certification, my Scrum from Microsoft Business Apps training course has got 14 videos covering: product owner, proven practices for product ownership, the product backlog and lots of advanced product backlog management tools and techniques. You can find out more at Customery.com/Scrum. 

That's it for this episode of Amazing Applications. Thanks for tuning in. Go out there find an amazing product owner, have them listen to this episode. Send to me your questions by visiting Customery.com and clicking on the 'Send Voicemail' button. Or you can leave a comment when you see this episode listed on the Amazing Applications page on LinkedIn. Ask a question, leave a comment underneath the post for this episode, and I'll try and answer it on a future upcoming episode of the Amazing Applications podcast. Until then, thanks for listening, and keep sprinting.