The Proxy Product Owner
When your company adopts Scrum, upper management may think about the product owner role like this:
The product owner manages the product backlog. That sounds like something a business analyst should do, right? Sure, it comes with a little more responsibility, but people in the organization might freak out if we adopt the term “product owner.” We can make product backlog management the person’s sole purpose, and other duties such as managing the budget will remain the way we do them now. If we give up control of the money, what happens to our job?
Let’s repurpose the project manager or business analyst role and call this new role the “product backlog manager.” We’ll outline our higher-level initiatives, have weekly status meetings, track the return on investment, and manage the budget the way we do now in different corners of the organization. After all, aren’t the VP roles in place for those kinds of duties?
The product backlog manager simply writes the requirements that stakeholders provide and ensures that the team delivers exactly what’s listed in the backlog. There’s even a chance that HR has created a role with the official title of “Product Owner.’’ The responsibilities defined in the HR document might read like that of a glorified business analyst or a product manager. Yet, the role is stripped of the responsibilities and accountabilities that a product owner needs to be successful.
Sometimes the issue is simple: The organization or product owner just doesn’t understand Scrum. If that’s the case, now is a great time to dust off your teaching boots and teach the PO and/or organization what the product owner role entails. Focus on the clear accountabilities of each Scrum role and why it’s imperative that the product owner be given all the capabilities and ownership that he needs to maximize the value of what the development team is working on.
When an organization implements a product backlog health metric, it signals that a proxy product owner exists. Organizations often implement this “metric” as a way to gauge whether the proxy PO is doing his job appropriately. People in management often believe that by creating this kind of metric, they can tell whether a development team has what they need in the product backlog to appropriately plan sprints.
“Healthy” is a red herring anyway. If you want to know if your product owner is doing his job, measure the value delivered. But if your management team is insisting on some kind of product backlog metric, look at transparency. In Scrum, transparent doesn’t mean “visible,” it means “well-understood.” During the next sprint review, ask the development team and stakeholders to discuss what the product vision is and how the product backlog supports that vision. After 30 seconds of blank stares, ask the PO to step up and walk through the product backlog and discuss how it ties back to vision and value.
If your project doesn’t have a fully empowered product owner who has a holistic view of the product-development effort, including financials, the proxy product owner will make ill-informed decisions on the contents and order of the product backlog. Stakeholder priorities, while important, shouldn’t necessarily determine the order of items in the product backlog. There may be more valuable things to work on.
It’s important for a product owner to know financial and return-on-investment information about the project so that he can have informed discussions with stakeholders. A proxy product owner often doesn’t have budgetary information. He is often put in tough spots when having conversations with stakeholders about the product backlog’s contents and order. It’s hard for the PO to push back when he doesn’t have numbers to back up his opinions.
As you can see, a proxy product owner won’t cut it and can doom a product. So what can you do if you’re working with a proxy product owner? Discover the de facto product owner by asking a simple question: Who do we have to talk to in order to get more money to fund another sprint? Usually you won’t need more money, but it’s helpful to know who makes that call. (This is similar to our advice earlier in this chapter: Trace the money.)
As a Scrum master, it’s important to help your product owner gain more authority. Once you know who can approve more money (a.k.a. the decider), it’s time to go have a talk. By meeting with your PO and the decider, you can help instigate some changes. Ask this decider—who’s often very busy—to attend the Scrum events and product refinement sessions. We need decision makers front and center, right?
This person will likely push back due to time constraints and a jam-packed calendar. This is your opportunity to suggest that the PO can take on a more active role in decision making. Be sure not to have this conversation in a bubble: Bring your product owner with you. Advocate for decentralized decision making and quantify the amount of time and money that’s wasted by waiting for decisions. This will help highlight the importance of the product owner role.