10 Product Owner Myths on Power Platform and Dynamics 365 Projects

Welcome to the Amazing Applications show for Microsoft Business Applications creators who want to build amazing applications that everyone will love. 

 Hi, I'm your host Neil Benson. My goal on this show 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.

In this episode, I'm going to cover 10 myths about the product owner role specifically in Power Platform and Dynamics 365 projects.

You'll find show notes at csutomery.com/042. 

The [00:01:00] product owner is responsible for maximizing the impact of the application that the scrum team is building. And I think our product owners in Power Platform and Dynamics 365 projects have a couple of twists compared to product owners on other scrum teams. 

They're quite often first-time product owners, at least in my experience on my projects. They're very rarely professional product managers with a lot of training and certification in that realm. More often than not, they've got lots of line of business experience, maybe a manager or a director from a business. They very rarely have any Microsoft business applications experience either. This is their first rodeo, their first time working with Dynamics 365 or the Power Platform.

Sometimes they don't even have any software development experience or for that matter, any Scrum experience. So coming from [00:02:00] a completely different point of view than a professional product manager. 

Sometimes, they're leaving another role to be your product owner. And sometimes they're more successful leaving that other role than others. Availability is always an issue. A lot of our product owners have still got a day job to do. 

So lots of differences. It's a pretty stressful, new and exciting position to find yourself in, if you're a product owner on the types of projects that we work on. 

Here's 10 myths about that role. 

Myth # 1. The product owner must meet all of the stakeholders' requirements. 

Our stakeholders could include the project sponsor, the executives, or board of directors and other senior people with significant influence. 

Other types of stakeholders can include IT. They often have the power of veto. Think of security, enterprise architecture, release [00:03:00] management. They all have the opportunity to block our application and prevent us from going into production. 

We have outside third parties like regulators, assessors, or auditors who are going to come along and inspect our project or inspect our application.

Internally, we have people like change managers, trainers, communications people who are going to help us with user adoption, get the good word out there about our application and help people learn it and adopt it. 

Then of course, we have the users, the wonderful folks who got to use our business application, and their leaders.

And then we have the folks that our users support every day, our organization's customers. 

All of our stakeholders are important. But the very best business applications I have found deliver value for users first. Supporting our users and enable them to serve our customers in new and amazing ways. 

I think it's the product [00:04:00] owner's job to do everything you can to delight your users. And do whatever you have to do to satisfy everybody else. But you can't possibly please all of the people, all of the time. Somebody's requirements are going to get deprioritized. Somebody is going to come away from the project with some of their requirements never met. That's life. We have a backlog, it lasts forever. 

Myth #2. The product owner is the proxy for the stakeholders. 

What I mean by that is that the developers go through the product owner to speak to, or to meet with, any of the stakeholders. 

It's true that the product owner spends a lot of time with those different stakeholder groups. She's updating them and telling them about our progress. She's listening to them and gathering their feedback. 

That doesn't mean that the rest of the scrum team, the developers and the scrum master can't get in front of those [00:05:00] stakeholders. Quite often, we're working very closely with the users, especially subject matter experts who have been asked to devote some of their time to our project. Our developers should also be listening to those other stakeholder groups as well, diving into their requirements, drawing out the details, discussing options with them, perhaps showing prototypes to them and demonstrating completed increments to them. That doesn't always mean that we have to wait until a sprint review to do that. We should be out working with those stakeholders as often as possible, with the product owner in those meetings as well, if we can, but bear in mind what I said earlier about the product owner's availability. Sometimes that's just not possible. 

Myth #3. The product owner is a tactical role.

 I've seen that organizations where the product owner is treated like a super business analyst or a senior business analyst focused on managing the product [00:06:00] backlog. They are guiding day-to-day decisions about your developers work and priorities, but they're not doing much more than that. 

And it is so much more. It's a strategic role.

It includes facilitating those discussions about the product vision, preparing the business case that outlines that business and user goals. And if you want to know more about goals, you can listen to the last episode. The product owner of course, is also setting product goals and drafting the sprint goals that together the scum team will agree on. 

So the product owner is connecting the scrum team to the business strategy. They are accountable for the vision and they own the product. That requires experience, decision-making authority, and the trust of the organization's leadership. And that's not a typical business analyst role. 

Now a great product owner could be a former business analyst. The skills are certainly really useful in a product owner role, but we [00:07:00] need a product owner who's got broader business management or product management experience and is now supported by business analysts.

In my experience, most business analysts just don't have the sufficient delegated decision-making authority from the project sponsor or the application sponsor into the product owner role 

Myth #4. The product owner role is like an agile project manager. 

Project management responsibilities include looking after budgets, timelines, and scope. And often our product owner is accountable for those things. She looks after the budgets, understanding how much the scrum team has cost sprint over sprint. Is responsible for the timelines, trying to figure out when releases are going to be deployed into production. And manages the scope by managing and ordering the product backlog. 

Other project management responsibilities include assigning work and managing resources. [00:08:00] Usually those project management responsibilities are best handled by the developers, or perhaps with some assistance from the scrum master. 

Lastly, there are a couple of project management responsibilities, things like risk management and resource management, but I think can be shared. Either held by the product owner, by the scrum master, or by some of the developers. Sometimes there is a project manager assisting your scrum team, but there doesn't have to be. And if there is, that project manager is a stakeholder and not an intrinsic part of the scrum team. So the product owner and a project manager completely separate roles. 

Myth #5. The product owner is responsible for the developers' performance.

Now the product owner is responsible for maximizing the impact or the value of the application that the scrum team's building, that the developers are building. She does this by clarifying the goals and setting the priorities [00:09:00] for the developers from sprint to sprint. 

But the developers manage themselves. They're responsible for their own performance. The product owner champions them, clarifies things for them, and to some extent cares for them. But she's not there to tell them how to do things or when to do things. They manage their own activity. They manage their own time. The product owner gets to focus on the application and the vision and the future, not on how it's being developed.

Myth #6. The product owner writes the user stories. 

User stories are a shorthand way of capturing the essence of our requirements. And yes, the product owner is accountable for the content of the product backlog. First of all, not all product backlog items need to be user stories. Some are non-functional requirements. We can have, um, chores and spikes and all sorts of other items in there as well. 

User stories are really [00:10:00] helpful and they're used by almost every scrum team that I've worked with, but they're not always written by the product owner. Sure, the product owner can write them. Developers can also write them. Stakeholders can also write them. But only the product owner can get rid of them, can delete them. And can order them in the product backlog.

I've worked on lots of projects where the product owner never even wrote a single story, but she was still accountable for ensuring developers have a steady stream of items ready to turn into increments in every. So in that sense, the product owner owns the backlog refinement process, even if she's never writing a single user story. 

Now if she's not writing a user story somebody has to. And quite often it's one of the developers with a business analyst background who is managing the details in the user stories on behalf of, and a responsibility delegated by, the product owner who continues to own [00:11:00] the accountability for the content of the product backlog. 

Myth #7. The product owner has prioritized the product backlog.

This one is kind of true. The product owner does order the product backlog based on lots of factors. The necessity, the value to the users, the willingness or the desire to pay down technical debt, maybe the severity of a defect that's in the backlog. Whatever she wants, whatever she judges will have the biggest impact for the organization, she can order their product backlog items based on those factors. 

But ordering the backlog isn't just a one-time event. It doesn't happen just at the start of the project. It's a frequent activity. The product backlog is ordered and reordered. With feedback and input. As things get done, it'll get reordered many times during each sprint.

It gets reordered after every sprint review when our stakeholders give us feedback and they give [00:12:00] us new requests and they tell us what they would like us to work on next. The product owner has a chance to take onboard that input and reorder the product backlog. And it can get reordered again just before sprint planning. If anything last minute comes up that the product owner would like to like us to take on board. She can do that just before sprint planning. And she can reorder the sprint backlog at any time during the rest of the sprint. 

The order of the product backlog isn't carved in stone. Any document that is an output of the product backlog. You know, somebody's sent you an extract in Excel, that backlog priority is at a point in time. It may not be true five minutes later because our real product backlog is a living, breathing thing. 

Myth #8. The product owner should not attend the retrospectives. 

I know some developers get pretty nervous when the product owner attends the retrospective. And I get that, especially [00:13:00] when you're a group of developers, a team of developers who works for a Microsoft partner and your product owner works for the Microsoft customer organizations. 

In those retrospective workshops, we are baring our mistakes. We're discussing the times when we stuffed up. 

We want to look like heroes to our product owner, but your product owner wants to learn from her mistakes too. She wants to learn and to grow, and she wants to be a better product owner for the scrum team. How can she do that if she doesn't participate in our sprint retrospectives? And it's the same for your scrum master too, by the way. 

So. Invite your product owner along. Make sure she gets to participate in every sprint retrospective as a full-fledged member of the scrum team. Because she is.

Myth #9. The product owner can't change the sprint backlog. 

Ah, this one's kind of true as well. The product owner can't [00:14:00] change the sprint goal unless she's going to terminate the sprint because it's no longer valid. And she can't add items from the product backlog to the sprint backlog either. And she can tell developers how to meet a requirement that is, you know, impose a design upon them. And we don't want her making significant changes to the acceptance criteria either. 

But having said all of those can'ts, can'ts, cant's, I still allow my product owners to make some changes to the sprint backlog.

Here's a couple of example scenarios. The product owner wants to remove an item from the sprint backlog before it's been started. Early in the sprint, none of the developers have touched an item, the product owner wants us to drop it from the sprint backlog. Something's changed. I'll normally accept that request. No problems with that one. And if she wants to replace it with something that's about the same size from the top of the product backlog, that's ready to go, that's probably okay, too. Of [00:15:00] course, I'd like the product owner to clarify any acceptance criteria, clarify any story details.

There's always room for negotiation in the sprint backlog. The sprint backlog is going to evolve during development, as the developers learn more about the product backlog items they're building, and as the product owner gets to review early prototypes, she's going to be learning too. We're in it together. 

Sticking to your guns? Well, it'll get you shot in the foot. So, negotiate your sprint backlog with your product owner. As long as both parties are reasonable. 

Myth #10. The product owner can not attend the daily scrum. 

The daily scrum is for the developers. It's their event to review and adjust their plan for the day. They've got to focus on how they're going to achieve the sprint goal. 

 The product owner and the scrum master can definitely attend if invited by the developers and it helps them with the purpose of the daily scrum. The product owner is not there to check on [00:16:00] progress. And she shouldn't need to, if the developers have a transparent sprint backlog. You know, if there's a scrum board, it's kept up to date, everybody should know where all the sprint backlog items are in the development process.

I love having my product owner there for a couple of reasons. One, to clarify any items, quite often, there's a little bit of input needed from the product owner to unblock a user story and keep it going. The product can also learn about any new impediments at the daily scrum. And the daily scrum isn't a place to solve those or fix those or remove the impediments. But we can schedule some time to follow up with the relevant developers later. So, product owner very welcome to attend our daily scrums if she accepts the fact that it's their event, and if she's invited by the developers, because her inputs are helpful for the developers.

So those are my top 10 myths about the product owner [00:17:00] role in Power Platform and Dynamics 365 projects. I'd love to find out about the other myths or questions you have about the product owner role in your projects. You can leave our questions or comments on LinkedIn on the Amazing Applications page, where you see this episode posted. 

You'll find show notes at customery.com/042. You'll always find a transcript for the episode, if reading is your thing. But you've got this far listening to me. 

Amazing Applications has got a new website coming soon. We've had 50 episodes under the previous podcast name of Scrum Dynamics, and this is episode 42 of the new podcast name, Amazing Applications. So I'm going to combine the numbering and shoot for episode 100 very soon. And we're going to launch the new website to celebrate. So watch out for that. I'll give you an update as we get closer.

If you have any ideas for special guests or topics, you'd like [00:18:00] me to cover, send me a message on LinkedIn or on Twitter. I'm @Customery on Twitter.  Until next time, keep sprinting.