Wait… what? That seems like an odd question to ask on a site for product people, after all some of the people reading this are product owners and the fact you are reading this is a pretty good indication that you are probably engaged.
Stick with me for a second….
Product Ownership in Internal Products
This topic was inspired by a question that came from a recent business analysis discussion group I facilitated. The specific question was “What are some ways to get BRM / PO more involved with team?”
Many organizations that do internal product work tend to identify a product owner from the business unit that “owns” the business process supported by the product. It stands to reason that is the person who has the information and authority to make the key decisions about the product.
Most of the people at the discussion group were working with product owners selected with this thought in mind.
What they found is that the people filling the product owner role were not focused on product ownership full time. In fact most of those product owners already had full time jobs before getting tapped as product owners and didn’t have any of their other responsibilities removed.
What’s more, these product owners didn’t have the detailed knowledge necessary to make all the day to day decisions to effectively work with a development team.
So these product owners did not have sufficient availability to work with the team and they did not have sufficient knowledge to effectively participate in backlog refinement. In effect they weren’t really in a position to meet the expected responsibilities of a product owner.
These weren’t the product owners the teams were looking for.
What you can do about it
In these cases, someone on the team (often someone with a business analysis background) ends up managing the backlog and taking on unofficially the role of product owner. I’m not going to dive into the religious wars about whether this person is a “proxy product owner” and whether proxy product owners are good or bad. There are just sometimes things you have to do build a product and get to the outcome you’re looking for.
So if you find yourself in this situation (I can speak from recent experience) here are some things I’d suggest.
Establish clear decision boundaries
Treat the products owners for what they really are: sponsors or key stakeholders. They are not going to have time to make every decision. They do not have the detailed knowledge to make day to day decisions. They may not even use the product on a regular basis.
But they are the right people to make the big decisions about the product overall. What problem are we trying to solve? From a broad perspective how should we solve that problem? Are there aspects of the problem that we don’t want to solve? What constraints (time and money) do we need to think about with our solution.
Establish clear decision making boundaries with the product owner. What decisions do they need to make versus which decisions can someone on the team make as long as you run it by them.
Try those decision boundaries out and see how they work. Revise if necessary. Make sure you make the best use of the product owner’s time, but also include them at the appropriate level for the decisions you need to make.
Identify subject matter experts to supplement the product owner’s knowledge
Figure out what information the product owner has and what information you need to work with others to get. You’ll often find that you need to work with people who are involved with the business process on a daily basis to get additional information.
These folks are usually the people who are going to use the product anyway so you’ll want to work with them to understand their usage pattern, their environment, and their needs.
You’ll also want to verify the information they provide with other sources. Look at the existing database if you are revising or rebuilding an existing product. Look at industry information about how other organizations have dealt with a similar process. Talk through examples with those subject matter experts.
Find a different product owner
If you’ve established decision roles, found additional subject matter experts, and still are running into delays because of your product owners lack of engagement, it may be time to find a new product owner.
You may be able to find someone who is able to spend more time with the team, can still make the key decisions, and may have more of the necessary knowledge. You’ll probably still need to establish decision roles and have other SME’s, but at least you’ll have a product owner who is more engaged.
Is this product really that important?
If you can’t find someone who can be engaged enough to even make the key decisions, your next question could be “should we bother continuing to work on this product?”
I’ve yet to see an organization that had more work than they could get done. If you can’t find someone who sees fit to spend a sufficient amount of attention to the product, take it as a sign that the product isn’t that important and your team’s efforts could be better spent on other places.
Asking this tough question should hopefully cause your organization to take a long hard look at their portfolio and make some important decisions about which efforts to continue and which ones to stop.
Your mileage may vary
I covered this and other issues with product ownership in when product ownership goes bad. If you’re running into challenges with other product people, you may find some helpful suggestions there.
It’s also important to note here that these ideas are relevant for internal product situations. If you’re working on a software product and your product person is not engaged, you’ve probably got different, and bigger issues altogether.
Finally, have you found yourself in a similar situation? If so, what are some of the things you tried and what did you experience?