How to Help a Product Owner from "The Business" Learn Their Role
A while back I shared the story of Arthur, a middle manager in the agent support department of a medium-sized insurance company in a medium-sized city in the middle of the United States. I told Arthur's story as a cautionary tale for product development teams to consider how they involve product owners from business units in their efforts.
A recent conversation with a product owner who came from a marketing background made me realize I may have missed some critical pieces of advice.
While it's important for product development teams to involve their product owners in their agile adoption, it occurred to me that what is more important is how the development team works with the product owner on an ongoing basis.
It's Not the Process That Counts
Let's face it, when teams adopt any new approach to work, they tend to obsess about process. And in most of those cases the folks working with those teams, commonly referred to as "the business," tend to be less concerned with the process than with what it will do for them.
Depending on the nature of the stakeholders, they may find somewhat devious ways to use the team's infatuation with process to get exactly what they think they want. Other stakeholders fall into a state of learned helplessness (often because the team themselves go there) and claim that someone just needs to tell them what to do because they don't understand the process.
What if you used frameworks as a guide to structure how to work together, instead of as a crutch, or even a prison? What if you used lessons learned from other teams living agile values and principles to work with your stakeholders to structure how they interacted, without invoking the framework du jour?
How You Interact with Your Product Owner Is Important
The product owner I talked to did not talk about how great agile was. She did talk about how helpful it was to talk to the members of the product development team on a daily basis so that they could stay up to speed with what she wanted and she could keep up to speed on what they were doing and how it would impact her going forward.
She also commented about how nice it was to know that the team was focused on her work exclusively, and not getting pulled in 14 different directions. It was nice for her to know that the project was their primary target of attention and they would be there if she needed to extend their conversation.
It also meant that they'd have a better chance of remembering what they had talked about a couple of days ago, that they'd be more likely to get things done for her project sooner, and that they would be thinking deeper about her project before just getting something done so they could rush off to something else.
Product owners from "the business" usually don't care about daily scrums or user stories or sprint planning unless the team forces them to care. They do care about how they should interact with the team to make sure that they can reach the outcome they want. The process by which they can get there is helpful, but it can also very easily get in the way.
Focus on the Results of the Process, Not the Process Itself
Several might read the above paragraph and interpret that to mean that teams should force their product owners to know the ins and outs of Scrum.
You and your product owners should sit down as a team and discuss how you're going to work together. In English, or whatever language everyone on the team speaks. Not process-ese.
Let your product owner know that their responsibility is to help the rest of the team understand what success looks like in terms of the outcome that you all seek. Find out how they are going to measure that success.
Hint: it's not going to be typical process-focused output metrics such as velocity or story points.
The product owner might ask for those things, probably because they have been trained by previous product development teams to think that's a good measure. What they really want to know is "when am I going to get my problem solved and how much is it going to cost?" Focus on whether you've solved their problem.
Talk to your product owner about how best to reach a shared understanding about what you are trying to do. You may have to listen to their original idea for a solution and back into the problem she's trying to solve.
Discuss how you are going to interact on a regular basis to stay in agreement about what you are trying to accomplish. How often are you going to interact? What's the best way to reach her? What's the best way for her to reach you? What should she do when she finds out new information? What's the best way for her to convey information for you? How can you work together to refine how you work together along the way?
What if You Didn't Call What You Are Doing "Agile"?
Yes, agile frameworks have special names for techniques you can use to accomplish those things. Here's the bit that agile coaches won't tell you: Most product owners from the business could care less what those things are called. They just want to know how they can do it to make sure their project is a success.
Find out how your product owner likes to make decisions and what information you can provide to her to help her make those decisions.
This is probably where they'll need the most help.
They may not feel they are in a position to make decisions, or they worry they'll get overridden. Or they may have to balance the needs of a large number of stakeholders who seem to exist solely to disagree with each other. Find out if there are ways you can help your product owner assess that information and decide what to do.
But also expect decisions from your product owner, and let her know the implications when she doesn't make timely decisions. Let her know as soon as you can when you need a decision made, and why you need it made when you do.
Agile approaches generally don't do a good job of providing guidance here. This is just the messy job of decision making in a group.
When all you teach new product owners is the terminology of the framework you're using, the ceremonies you follow, and the artifacts you produce, you do them a great disservice. You don't let them know what you really need them to do.
Spend more time discussing how you want to work together and adjust that based on experience, rather than teaching what a framework indicates worked in some other very specific situation that may not be the same as the situation you're in right now.
What are some ways you've helped a new product owner from "the business" get up to speed? Share your experiences in the comments.