Can You Build an App Without a Product Owner?

Neil Benson: [00:00:00] G'day. I'm Neil Benson. Welcome to Amazing Applications. This is episode 122, which means you'll find show notes and resources at https://AmazingApps.Show/122. 

It's been a couple of weeks since the last episode. I've been busy wrapping up the second private preview of my Winning Agile Projects masterclass with two Microsoft partners in the UK. A shout out to Advantage Business Systems and Incremental Group who were fantastic in the workshops. Thanks, everyone, for all of your participation. 

I've also just finished the first three sections of my Estimating Business Apps course. If you want to sign up for that, the first three sections are free. They cover: why estimate at all, story points, and how to estimate requirements. And it includes a lesson from my wife about why you should use relative estimation instead of measuring units of time. You can sign up for free at https://Customery.Academy. 

Right now I am working on the advanced content and it'll be published in a few weeks. So you can still get access to that advanced content on the pre-release price of $47. Once it's released the price will revert to $97. 

On Amazing Apps, I've got some more interview shows planned. Meantime, I'm gonna create a couple of solo episodes like this one, addressing interesting challenges that Microsoft customers or partners are having while adopting an agile approach to building business apps. If you've got a challenge and you'd like some help, you can send me a voicemail by visiting https://AmazingApps.Show and clicking on the Send Voicemail button to record your question. 

The question in this episode comes from Ethan who works for a Microsoft partner.

Ethan asks, 

Ethan: "We haven't had a product owner for the first few sprints of our new project. What should we do?"

Neil Benson: Ethan, you can't run a scrum team without a product owner. You're a certified scrum master. So I'm sure you know that. 

The product owner accountability is critical to the success of any scrum team building a Power Platform application. The product owner is accountable for maximizing the value that the customer's organization receives from its [00:02:00] new application. They do that by guiding the work of the scrum team by communicating their goals and clarifying the product backlog.

If there's no one communicating the product goal or clarifying the product backlog, then the scrum team will have to take a wild guess at what the customer organization needs. Nine times outta 10, they'll miss. 

I think there's two parts to this missing product owner problem. The first is how we got here. The second is how do we fix. 

How do we get here? Well, one of the recommendations I make to Microsoft partners in my Winning Agile Projects masterclass is to name the customer's product owner in your statement of work and agree with the customer, the product owner's capacity for working in the scrum team.

If the customer wants to reassign the product owner responsibility to someone else, then there should be a mechanism for that in the master services agreement, just like there should be for any other key person that the contract relies on. 

I like to go a step further and name all the subject matter experts that the scrum team will also be relying on to support the product owner either by clarifying requirements or verifying increments are done.

By agreeing their capacity upfront, we're being very clear about our expectations and our assumptions about what's needed to make this project a success. By including these names, roles, and capacities in the statement of work, we're compelling ourselves to have that conversation upfront with the customer before the start of sprint one. This should help us avoid starting projects where the product owner is missing or the need for the product owner wasn't made clear to the customer. 

As the business owner of a Microsoft partner organization, I wouldn't sign a statement of work until my sales team had discovered who the product owner was going to be, ensured that person was familiar with what was going to be asked of them, and their name and required capacity was stated in this statement of work.

It's common that a Microsoft Business Apps product owner is a first time product owner. They [00:04:00] probably haven't been a product owner before or worked with the Microsoft Power Platform before either. That's okay. We don't need them to be an expert in either of those things. 

We need them to have decision making authority, the ability to engage their stakeholders, and a firm grasp on the problem our app is going to solve. Our scrum master can coach them on everything else along the way. And our scrum team is also there to support them. 

Ethan, I hope you'll raise this issue with your leadership team and help them update their sales process and the statement of work template to ensure that naming the customer's product owner is in it. And you don't run into these problems on future projects. 

But now that you're facing this situation, what can you do to fix it?

You're going to need to act fast to find a product owner. And you're gonna need help to do this. As a scrum master, you're licensed to work within the organization to help them adopt and apply Scrum. And that means both working within your Microsoft partner business and your Microsoft customer's organization, to highlight the necessity for a product owner. 

You need to raise this massive risk on your project. Both organizations, if they have any experience managing projects, should have risk registers and you need to ensure that this big fat risk lands right at the top of it and gets acted upon immediately.

This isn't even a risk that you can mitigate anymore. It's a risk that's come true. It's an issue and it needs to be addressed. 

You could also help by working with any stakeholders you've met so far. Do any of them seem like they could become a product owner? Ideally, they'd have decision making authority. They'd be trusted by and can engage with the other stakeholders, and have a firm grasp on the problem the app is going to solve. But, you know, in a pickle like this one or two of those qualities might just be enough.

I've worked with one customer who hired a consultant to hold the product owner accountability. I wouldn't normally recommend this option, but it worked out for this customer because Frieda, the product owner at the University of New South Wales had experience as a student, a lecturer, and had worked on several [00:06:00] engagements and was trusted by the university's senior stakeholders. That might be an option for your customer. 

Otherwise you might need to pause the project until your customer finds a product owner. That's painful for you as a Microsoft partner, because now you suddenly have a team that isn't billable and you probably can't afford to have them sitting on the bench for a few weeks waiting for a product owner to show up.

But here's what can happen if you don't. 

After two years of working successfully with Frieda at UNSW, my business was invited to build an expense app for three other UNSW departments. Frieda told me not to touch it because another team had already failed to build the expense app, and she knew it was an impossible project. But I wanted to be the hero, and I thought we had a team that could build anything. Each of these departments provided a project manager and a couple of users who had divergent expense management requirements. After fumbling around for way too many sprints during which project managers came and went, eventually a new project manager from IT reviewed where we were up to and canceled the entire project. 

In the post project review, it was clear that I should have known better than to limp along without a product owner. I should have raised the risk and called it earlier. I should have stopped the project several sprints before the customer did. We had to write off $60,000 worth of consulting services. And I ran back to Frieda's project and my organization with my tail between my legs.

You can hear the full story about my Power Apps Portals Disaster in episode 31 at https://AmazingApps.Show/31. 

Ethan, I hope my sorry story serves as an incentive for you to avoid that kind of disaster. Do whatever you can to find a product owner right now. Raise it as a high priority high severity issue internally and with your customer. If you haven't found a good product owner by the end of your current sprint, consider pausing the project. Otherwise you might find yourself refunding your customers, like I did. 

And good luck to you finding a great [00:08:00] product owner for all of your Power Platform and Dynamics 365 projects. Keep sprinting.