When Product Ownership Goes Bad

Photo by NeONBRAND on Unsplash

In Product Ownership In the Wild, I described the four common models for product ownership. As people started reading the book they sent in several questions, many of which directly or indirectly mentioned that the model descriptions assumed a perfect situation:

But what about when things go bad?

What are some of the common issues that each model can experience?

What happens when you try to apply the model in an “unhealthy agile environment” or what obstacles prevent it from maturing?

Basically, what can go wrong with each of those models?

I thought I’d take a pass at the issues that can arise with any of the models as well as issues that occur with specific models. I also tried to suggest some possible solutions.

Keep in mind as you read some of the solutions, especially those that come up consistently, that i’m writing this as an “unemployable”. (Note that I’m not using the definition of unemployable you may initially think of)

Also note when I use the term “product people” I’m generally referring to the product managers, product owners, and business analysts that are working on the product.

Common Issues Across The Models

 

There are some issues that can happen regardless of what model you use. These issues usually arise because an agile mindset is missing either on behalf of the product people, organizational leadership, or both.

Lack of Agile Mindset

These models for product ownership are predicated on the assumption that the product work is done in an organization with an agile mindset. That means that people want to organize their work in such a way that they can learn and drive continuous improvement. They believe in the value of distributed decision making, and want to work in a manner that invokes trust and honesty.

Not all organizations are like that. Although they rarely proclaim they don’t want to learn and change, they act in a manner that conveys that. Often that attitude exhibits itself in the form of doggedly staying with approaches they have always used. It also shows up as people staking out territories, hiding information from each other in order to solidify their own position, or making decisions based on self interest rather than what is best for the product or organization.

If that is the case, seek some coaching for the leaders of the organization so that they can change their approach to work. Strive to change from command and control to intent based leadership.

If your leadership and your organization don’t change, consider changing your organization.

The lack of an agile mindset also tends to present itself as one of the following two issues.

Product person hoards decisions

These models don’t work when the product person (or people) makes all the decisions without involving the team.

While one of the product person’s main responsibilities is making decisions, it’s really a specific set of decisions that they are responsible for, primarily those regarding vision for the product and what’s needed to deliver the desired outcome. What output the team delivers and how the team goes about their day to day work is really the responsibility of the team.

Even for those decisions where the product person is responsible, they shouldn’t make those decisions in a vacuum. A sole product person is not going to possibly know everything there is to know about a given situation, so they need to reach out for other information, perspective, and insights.

If you find yourself in this situation coach the product person on the benefits of distributed decision making and the idea that making timely, informed decisions means getting information from a variety of sources, time willing.

If your product person doesn’t change their behavior as a result of that coaching, you can always find a different product person.

Product person lacks the authority to decide

A twist on the issue above is where even the product person does not have the proper authority to make a decision – there always seems to be someone else countermanding their decisions.

If this is the case, sit down with the product person who is supposed to be making decisions, and the person or people who keep stepping in on the decisions. Understand why those decisions keep getting changed.

Is it because the product person isn’t aware of the limits of their decision making responsibility? If so, clarify them.

Does the product person clearly understanding how the product fits in the broader organization? If not establish some decision filters they can use.

Does the other person think they should be the product owner? Suggest they do that, but also inform them of the expectations that come with that role.

If all of that does not work, find a different product person.

Product person (people) aren’t respected

These models won’t work when the team does not respect and enact a product person’s decisions. This is often a sign that the product person and team need to strengthen their relationship and build trust and respect.

The product person should make sure they have a shared understanding with the team regarding what outcome the product is intended to accomplish.

The product person could also find out why the team doesn’t have respect for their decisions.

The team may be uncertain about the product person’s qualifications to make decisions. If that’s the case, the product person can seek information from the team and other subject matter experts to build up their expertise.

If that does not work, you may need to find a different product person.

Product People Dabbles in the How

These models won’t work if the product person falls in love with their their chosen solution rather than being an advocate for delivering the desired outcome and leaving the solution creation to the team.

Hopefully, the product person and the team to have a good enough relationship that the team can say “Thanks for that suggestion. What are the key characteristics of your idea that we need to make sure we consider when we put a solution together.”

if that doesn’t work, the team can tell the product person to “step off”.

If all that doesn’t work, find a new product person.

Product Person Writes Checks the Team Can’t Cash

These models won’t work if the product person makes promises or commitments to customers on behalf of the team – without checking with the team first.

The product person may learn their lesson through experience, as it’s fairly likely that the team will not deliver on those promises. Learning from experience in this fashion will work as long as the product person and team have a discussion about why those commitments aren’t being met.

Of course the team could avoid the pain and disappointment that comes with unmet commitments by having the discussion to begin with the product person shouldn’t make commitments for the team.

If the team and product person have that conversation and the product person doesn’t learn their lesson, get another product person.

There are no Product People

I presented Examining the Product Owner Role at a conference recently and one of the attendees came up to me afterward and indicated that they had a new model – what if there were no product people.

Intrigued, I asked him to explain. He indicated that he worked on a development team that was charged with delivering a bit of work for their organization, and they had no one explicitly charged with being a product manager, product owner, or business analyst.

I suggested he was probably in the Only Child model, and that the development manager was that only child. The attendee started nodding his head and a wry smile slowly crawled onto his face. “Yeah, you’re right. And I’m the only child.”

There will always be someone doing the the things that product people should do, they just may not have been explicitly told to do them, and as a consequence may not do them very well. When a development team lacks an explicit product person, someone on the team, or more likely their manager will adopt that responsibility.

If a team is in that situation, determine if the person currently acting as the product person is the right person to be doing so. (They usually aren’t). And if not, find someone to do product ownership (and expect that you’ll experience several of the other issues as that person gets up to speed). If that doesn’t work, ask the appropriate people whether the work is truly that important if you can’t even identify someone to identify the outcome and make even the broadest decisions.

Only Child: Product Manager Is the Product Owner

This is actually the model preferred both by the founders of several agile frameworks and many in the product management community. This model fits the idea of a single product owner that is suggested in Scrum.

Most of the issues with this model come as a result of the behaviors or capabilities of the single product person, or when the product starts to grow to the point where one person can no longer effectively handle all the product person responsibilities.

Product Manager Can’t Balance

The model does not work when the product person is unable to properly balance the focus on customers and time spent with the team.

If you find yourself in this situation, determine if there are non product things that are vying for the product person’s time and attention. Make sure the time spent on different areas of focus is not due to the product person’s preferences (they are more comfortable spending all their time with the team rather than talking to customers.)

If they aren’t able to recognize the split and reorganize how much time they spend, you may find a different product person who can, or it may be a sign that you need to move to one of the other models.

Unavailable Product Manager

The model does not work when the product person cannot devote the appropriate amount of time to the product. If this is the case, take steps to clear the product person of their other responsibilities so that they can focus on the product and its customers, stakeholders, and users.

If that does not work, find a product person who can.

Product Manager Can’t Decide

The model does not work when the product person does not make timely decisions because they always look for more information.

If this is the case, introduce them to the idea of real options. Suggest that when they know they face a decision, first determine when they need to make that decision so that they don’t start losing options. They can then use the intervening time to collect additional information, but they then need to make the decision when that pre arranged time comes, regardless of how much information they’ve gathered.

If that does not work, find a different product person.

Identical Twins: Product Manager and Product Owner

Depending on your perspective, this model and the next two all represent a dysfunction of some sort because you are getting away from the idea of a single product owner.

These models represent a way of reorganizing the main interactions that each of the product people have and which decisions each is responsible for.

Product manager/product owner relationship

This model does not work when the product manager and product owner do not have a good relationship. If these two product people can’t stand working with each other… well, they’re not going to work well together and the state of the product will reflect that.

If this is the case, the product manager and product owner need to have a heart to heart talk to see if they can find a way to work together. Having a shared purpose is always a good start. Being upfront and honest about the issues they have working together doesn’t hurt either. This is a place where a coach (or scrum master) can be helpful as a facilitator to the discussion.

If that doesn’t work, you may consider whether you could switch to the only child model, or you may have to find a different product manager, product owner, or both.

Product Manager slacks off

This model does not work when the product manager slacks off on their responsibility because they figure the product owner has it covered. The split in responsibility usually happens because there is too much to do for one person. That doesn’t mean that the two separate people can just slack off and think the other person has it covered.

The product manager and product owner should have an upfront, honest discussion about what each person’s responsibilities are. Using a RACI chart to aid this conversation is very helpful. These two should agree to regularly (it’s best to do this on a regular cadence) revisit the RACI and discuss whether each of them are living up to the agreement and whether it needs to change.

If clear expectation setting and regular check ins do not work, consider moving back to the Only Child model with the person filling the product owner role being the only child. If that would overload that product person, find a different product manager.

Product manager overrides product owner

This model does not work when the product manager overrides product owner decisions, especially when those decisions were the responsibility of the product owner.

This is only a concern when the overriden decisions happen frequently and cause churn for the team. If an override only occurs once or twice it’s probably not anything to worry about.

All the same, when an override does occur it’s best for the product manager and product owner to discuss the situation and determine why the product manager felt the need to override.

Is the product owner aware of all the information that they need in order to make informed decisions?

Was there a subtle nuance about the decision that the product manager was not aware of that if they were, they would have supported the product owners decisions?

Are there clear decision filters that the product owner can use to make decisions within their area of responsibility that align with the product manager’s vision?

The best thing to do here is for the product people to have an open, honest working relationship so that they can talk through these issues.

If that does not work, you may need to find a different product manager and/or product owner.

Stepping on toes and expectations

This model does not work if the product people filling the product manager and product owner roles come to an agreement about which each is going to do, and then one or both of them ignores that agreement. This is a particularly problematic if the product people shared their agreement with the rest of the team(s) (which they should).

It becomes an issue when the team sees what it thought were working agreements being ignored.

The product manager should not be precluded from interacting with the team, and the product owner should not be prevented from talking to customers. It’s when the product manager interacts with the team in a way that undermines the product owner’s relationship is when it becomes a problem.

If both product people are acting in that fashion, the simplest thing that might work is for the two to switch places. You may just have a case that each person was in the wrong role.

When the toe stepping starts to happen, get the product people together to have a discussion and reset expectations. Having an agreed upon split of responsibilities and decisions for which they are responsible is helpful.

It’s good during this discussion to talk about why one or both of them are toe stepping. Is it because they prefer to do the other activity, or is it because they see deficiencies in how the other person is doing it. Use those reasons as an entry to figuring out a different approach going forward.

And if that doesn’t work, you guessed it, find different product people.

Fraternal Twins: Product Manager and Business Analyst

Most of the issues with this model match that of the the Identical Twins. Just change “product owner” to “business analyst”.

There are some additional issues that come about because the person playing the product owner role happens to be a business analyst sitting in the technology part of the organization.

Business Analyst is not given (or does not take) any decision making authority

A key assumption underlying my view of effective product ownership is that decision making responsibility is distributed. An equally important assumption of this model is that prioritization decisions end up the responsibility of the business analyst, who is, in effect, acting as the product owner.

Business analysts often face a legacy where someone in that role is perceived as not a decision maker. Sometimes people other than the business analyst holds that idea, sometimes it’s the business analyst themselves. Either way, if the business analyst is asked to act like a product owner and they aren’t in a position to make decisions then they will not be effective in that role, and this model will not work.

I should note that I generally characterize the decision making habit as “make sure decisions get made” so it is possible that that the business analyst is responsible for herding cats (otherwise known as a group of stakeholders) in order to make sure that a set of key decisions get made. In that case if the business analyst doesn’t feel as if they are in a position to make that happen, the model is equally unsuccessful.

The first step with this issue is to take steps to prevent it in the first place. Have a discussion with the product people about the importance of decision making and how it’s important for the business analyst to be able to make decisions, especially those that are in the realm of immediate interest to the team. That conversation should also include anyone who the product people interact with that may attempt to preempt their decision making capabilities. You may find that a RACI chart can be a good tool to help guide that discussion.

It’s never too late to have that discussion, but it certainly is more useful the earlier you have it. If the business analyst does try to make decisions, but those decisions aren’t respected, you may find that some external validation – from leadership – may be needed to provide credibility and perhaps air cover for the business analyst.

If the business analyst doesn’t seem to be interested in taking on decision making responsibilities, then – you may have noticed a pattern – find a different business analyst.

Business Analyst serves competing interests

There’s a distinct possibility that the person filing the product owner circle in the Identical Twins model could be a titled business analyst, and equally likely that person filing the business analyst circle in the fraternal twins model is labeled a product owner.

Those titles aren’t particularly important – it’s the fact that the business analyst in this model reports up through a different part of the organization. That may not seem like a big deal, but it has a huge impact on how that person in the business analyst circle acts. (Although in an ideal world it shouldn’t).

The business analysts’ focus should be on the outcomes that the product is intended to accomplish, building and maintaining a shared understanding of that outcome and the output required to bring it about, and making sure decisions get made to keep progress moving toward that outcome.

The business analyst who reports up through IT ends up having influence from IT leadership to keep up appearances and to protect the reputation of the IT organization. Sometimes this is subtle, sometimes this is overt. The more adversarial the relationship between IT and business units, the more likely the business analyst will feel pressure to behave in a way that shines a good light on IT. In its most nefarious form, that means that when problems happen, the BA is looked on to deflect responsibility from the development team.

It often looks like “They (people in the business units) don’t know what they want”. Or “They (again those devious business folk) “keep changing their mind.”

These statements may in fact be true, but they should not be stated as excuses. They are conditions that you need to address in the approach you use to deliver your product. One of the main reasons agile approaches are structured the way they are.

The best way to address this issue is for people in leadership positions to provide air cover for the business analyst. They need to make it possible for the BA to focus solely on the product and it’s desired outcome. For this truly to be effective, the Business Unit and IT need to improve their relationship so that IT doesn’t feel the need to protect their reputation. The best place to start – openness, honesty, and transparency.

Another way to address this issue is for the business analyst to resist the pressure to behave in a way that does not result in the desired outcome for the product. The tricky bit here is that the business analyst needs to be willing to take some actions that may go counter to the wishes of their direct boss. The business analyst can mitigate some of those challenges by building a support network in the organization as a whole that can counteract the detrimental leanings of their boss.

I’ll admit those things are easy for me to say because I’d usually be a consultant in that situation, so I have a bit more flexibility to go counter to my direct reporting relationship when it’s in the best interest of the product that I was brought on to support.

And if you’re the business analyst, can’t get air cover, the business unit and IT organization can’t get along, and you’re not comfortable with running counter to your boss, you may want to look for a new gig.

In other words – if you can’t change your organization, change your organization.

Product Manager slacks

This often happens in an internal product situation where the person filling the product manager role isn’t used to working on a product fashion. Their main responsibilities are usually some operationally focused role, and they have the additional responsibility of delivering a product that will help the processes for which they are responsible.

If they see that they have someone working with the development team and has their backs so to speak, they may feel inclined to slack off their responsibilities and become disengaged with the development team and the product all together – potentially even not paying attention to the external facing responsibilities they should have.

This is another case where having a clear understanding of responsibilities among all the product people is extremely important. If your product manager is in fact someone that does not have a great deal of experience with product work, you’ll need to do a bit of education to familiarize the product manager with what they need to do. It’s another occasion where you need to stress the importance of providing a vision and decision making.

The upside to this issue is that the business analyst will most likely get a chance to drive work on the product forward and make several decisions.

If you find that your product manager is slacking off and interventions do not change that behavior, you may have the wrong product manager and you’ll need to switch product managers – or factor that into your decision whether you work on that product at all.

Business Analysts (and/or Team) thinks BA’s role is merely to document

This is another case of breaking out of legacy perspectives on the role of the business analyst. The issue here is the perception that the only responsibility of the business analyst is to explicitly write user stories and the corresponding artifacts that go along with them (I prefer to use models, acceptance criteria, and examples).

Business analysts still may do that, but it is not their only, or even their prime, responsibility. Rather, use the documentation as a means to focus the team on output, build shared and understanding, and make sure decisions get made.

The way to address this is to clearly discuss expectations, and this is probably a discussion you can have when you’re talking about the decision making. You want the business analyst to view documentation as a means rather than an end, and you want to make sure the entire team is aware of that.

If your business analyst can’t get past viewing documentation as their deliverable you know the answer by now.

Triplets: Product Manager, Product Owner, and Business Analyst

You can take all the issues from the Identical Twins and Fraternal Twins models and add them together for this model.

If any issues do arise, the first thing to consider is whether you really need triplets and whether you should adopt either the Identical Twins or Fraternal Twins models.

In addition to the issues common with Identical Twins or Fraternal Twins, there are a couple of additional issues.

Product Owner Acts solely as a SME

Just like the product manager might slack in the Fraternal Twins model, the Product Owner may end up slacking in the triplet model and only act as a subject model expert and not perform any of the expected decision making.

The way to address this issue is, you guessed it, establish expectations about their responsibilities. Meaningful training about the role of a product owner can be helpful as well.

If you can’t convince the product owner they need to take responsibility, you can also determine if you can get by with a Fraternal Twins model, and just use the person who was the product owner to provide subject matter expertise.

Product Manager Focuses Externally, Business Analyst Focuses on the Team, where does the Product Owner Focus?

A related issue with this model is the product owner may feel as if there isn’t a role for them or ends up duplicating the responsibilities of either the product manager (focus primarily externally) or the business analyst.

This isn’t necessarily an issue assuming the product manager or business analyst reacts accordingly.

If the product owner spends a lot of time focusing externally, talking to customers and trying to figure out where the product should be headed, then the product manager might want to think about coaching that product owner in how to take over that responsibility. There also may be a need for the current product manager to provide the product owner with the appropriate decision making responsibility. The end result is that the model may go from the Triplet model to the Fraternal Twin model.

If the product owner ends up spending most of their time with the team, then the business analyst should start coaching the product owner on the proper business analysis techniques to build a shared understanding with the team with the goal being to convert from the Triplet model to the Identical Twin model. This also frees the business analyst to exercise their other skills on the team, or rotate to another team that is lacking some business analysis skill sets.

If the product owner does not seem to be trying to take on any responsibilities other than providing subject matter expertise, it may be best to switch to the Fraternal Twins model and just look to that product owner to answer questions when needed.

What issues have I missed?

Length of the post aside, this was not intended to be a comprehensive list. I’d be curious to hear what issues you have run into, or if you have run into any of these issues how you’ve resolved them. Leave your thoughts in the comments.