Plight of the Product Owner: Making sense of many competing view points in Medium Size Mayhem

In Agile software development, our goal is to build exactly what the user wants in the shortest amount of time, thus maximizing the business value of the product. We do this by iteratively building something, getting feedback, and learning from that feedback. This iterative approach allows the team to react to changes in the marketplace. So, how do we know what to build in the first place?

The Scrum Guide tells us that the Product Owner, who is a single person, is accountable for maximizing the value of the product. This implies that they know exactly what the user wants or have access to those who do.

The Scrum Guide further tells us that the Product Owner achieves this by effectively managing the Product Backlog (either directly or by delegating to someone else on the team), and that this effective management includes:

• Creating and communicating the Product Goal explicitly

• Creating the set of Product Backlog items and clearly communicating them

• Ordering the Product Backlog (to maximize its value)

• Ensuring its visibility, transparency, and understandability

For the Product Owner to be successful, they rely on the entire organization to respect their decisions.

So that's a basic outline of the Product Owners responsibilities. Seems fairly straight forward (I mean sure, some of that is bound to be tricky):

• Create a list of things the product should do/have

• Order it to maximize the product value

• Make sure everyone understands what and why

What could go wrong?

Enter Medium Size Mayhem

Well, from my experience, quite a few things. In a medium-sized company (100-500 people), employees tend to wear more than one hat. That includes the Product Owner, who might also be juggling responsibilities like marketing, stakeholder management, or even customer support. This multitasking can lead to conflicts, compromises, and sometimes chaos.

Let’s dive into some of the common challenges and how they play out.

1. The “Invisible” Product Goal

The Product Goal is supposed to act as our north star, guiding the team toward a shared vision. However, in many medium-sized companies, this goal can end up vague, overly broad, or missing altogether.

How to Fix It:

• Collaborate with stakeholders early to define a clear and actionable Product Goal.

• Regularly revisit the goal during sprint reviews or retrospectives to ensure it still aligns with market conditions.

From the Trenches:

A few years back, I took over as product owner for a project. This was truly medium-sized mayhem. At the time, it was unclear what the Product Goal was. Some stakeholders viewed the goal as "simply" replacing the current aging system, which had become difficult to maintain. Others saw it as creating a new high-performance system that was much easier to use. For the marketing and sales teams, it was crucial that the new system retained all the features of the one it would replace. This made ordering the backlog very difficult and was also demoralizing for the Scrum Team, who just wanted to build the right thing. Eventually, with buy-in from management, we were able to assign the responsibility of "customer advocate" to one of our most knowledgeable service technicians, and with their help, we reduced the ambiguity of the Product Goal significantly.

2. Competing Stakeholder Demands

With multiple departments and priorities, the Product Owner often faces competing demands from stakeholders. Marketing wants Feature A, Sales demands Feature B, and Engineering insists Feature C is crucial for scalability. Ordering the backlog becomes a political minefield.

How to Fix It:

• Use data to prioritize. Tie backlog items to measurable business outcomes, like revenue impact or customer satisfaction.

• Facilitate stakeholder alignment sessions to agree on priorities. A good Scrum Master can help mediate these discussions.

• Lean on your Product Manager. They often have the insight a Product Owner needs to effectively order and prioritize the Product Backlog.

  
  

3. Lack of Team Buy-In

Even if the Product Backlog is perfectly ordered, it doesn’t matter if the team doesn’t understand or, worse, doesn’t believe in the “why” behind it. Poorly communicating the Product Goal or reasons for a feature, can lead to half-hearted execution or outright resistance.

How to Fix It:

• Product Owners should be encouraged to regularly explain the reasoning behind the backlog order during sprint planning.

• Invite the team to provide feedback or suggest improvements to the backlog, fostering a sense of ownership.

  
  

4. Product Owner Overload

In a medium-sized company, the Product Owner might be stretched thin, leading to delays in backlog refinement or vague requirements. When the team isn’t clear on what to build, productivity grinds to a halt.

How to Fix It:

• Empower the team to take on more responsibility for backlog refinement, with the Product Owner providing oversight.

• Advocate for reducing the Product Owner’s non-Scrum responsibilities by making a case to leadership about the business value of their focus.

  
  

5. Organization-Wide Respect for the Role

The Scrum Guide says the Product Owner needs the entire organization to respect their decisions. In practice, however, especially in medium-sized companies, that respect might not always be there. Teams may ignore priorities, or executives might bypass the backlog entirely, introducing scope creep mid-sprint.

How to Fix It:

• Educate leadership and stakeholders on the Product Owner’s role. Use workshops or discussions to highlight how respect for the backlog leads to better outcomes.

• Reinforce the importance of autonomy for the Scrum Team, and educate stakeholders on the inefficiencies in having the team change their plans during a sprint.

• Shorten the sprint length to accommodate more frequent input from stakeholders and reduce the chance of scope creep during a sprint.

• Be flexible, work with your organization to create a process that works in your business.

  
  

From the trenches:

I once introduced Scrum to a product team and was met with complete consternation from product management when I told them the development team would plan out a 3-week sprint and they would not make any changes to the plan during that time. "What happens if there is a major bug that is keeping a customer's machine from working properly?" "What if there is a problem in production and we need the engineers to resolve it?" You see, the team was responsible for maintenance, production support, and new feature development. Long story short, we ultimately agreed to a 2-week sprint and that the team would plan in time for a limited number of unforeseen issues. This worked out to a win-win for all the parties involved. Over time, we were able to improve processes such that there were fewer issues that required immediate attention from the development team.

Wrapping It Up

Being a Product Owner in a medium-sized company isn’t easy. It can sometimes feel like you are an octopus wearing 3 hats, juggling, while eating your pizza. They’re juggling priorities, managing expectations, and trying to maximize value while often wearing multiple hats. However, it can be highly rewarding as well. Witnessing the product you imagined come to life and be well-received by the market is an amazing experience.

Agile thrives on continuous improvement, and with the right support, even the trickiest challenges can turn into opportunities for growth.