As team leaders, we should always assume positive intent; however, I’ve recently encountered some terrible examples of product ownership run wild. And it started me thinking about the following:
- How fundamentally important the role of product owner is not only in Scrum, but also in agile teams. I’ve seen the difference excellent product owners can make to a team, and conversely, the damage “bad ones” can do.
- How many bad product owners (organizational, group, and individuals) that I’ve seen in my own coaching travels.
So, in this piece, I want to explore some of the “you might be a bad product owner if …” patterns that I’ve encountered, all in the hopes that we might avoid them in the future.
This is a two-part post, and I’ll share a group of anti-patterns in each.
You might misunderstand the role of product owner if you …
Have a poor understanding of the entire role
Many organizations trivialize the product owner role to one of simply providing requirements (i.e., writing, delivering, confirming, etc.). While that is a significant part of the role, it’s only an isolated aspect. It’s so much broader and deeper than that.
I’ve established a model that I call “the 4 quadrants of product ownership” that illustrates both the depth and breadth of the role. You can read more about it here. The 4 quadrants identify four key areas of product owner responsibility:
- Product management
- Project management
- Business analysis
Suffice it to say, product ownership is a full-time job that requires an understanding of doing the entirety of the role and doing it well. Another way to better understand it is by reading one of the great books on the topic. No matter how you slice it, effective product ownership is a deep and broad skill set that is not so easily found, nor executed.
Are wearing multiple hats
I’ve encountered organizations that have asked managers, Scrum Masters, business analysts, product managers, and many other kinds of roles to also “wear the hat” of the product owner. It’s a “poor man’s approach” to staffing the role. And it’s also quite hopeful to think that these folks will have the time, after doing their day job, to also effectively contribute as a product owner.
You know what? It doesn’t work that well. Imagine that. It trivializes the role, and it often results in very poor operation by the team(s).
To me, this is often related to the former point. Leaders don’t fully understand the role of product owner, so they short shrift it, not really understanding the impact it has on the team’s results and delivered value. And being cheap in investing in the role undermines the value-delivery capabilities of the team, so this strategy is unsound from a business perspective as well.
Are trying to go it alone (including technical decision-making)
Sometimes when we look at our role within an organization, we have a lonely view, often considering our role as a micro-silo within other silos, all handing work to each other.
Not a pretty picture if I do say so myself.
Since the role of product owner is uniquely focused on a Scrum team, it’s easy for the PO to become a Lone Ranger of sorts: writing the backlog alone, making all the decisions, and spending a great deal of time doing so.
I like the “it takes a village” metaphor when it comes to owning the backlog. In this case, the village is the entire team, and the product owner is the mayor. Yes, they are the final arbiter of the backlog, but they do so collaboratively and collectively.
And I want product owners to partner as much as possible – partner with another PO, partner with their Scrum Master, and partner with their teams. It’s this shared ownership of the backlog and the decision-making that makes all the difference.
Prioritize outward activity over inward (team) activity
I often make the distinction between the roles of product manager and product owner in this way:
Product managers are (mostly) outwardly focused toward the stakeholders and customers. They do things like:
- Create a business case and manage ROI
- Share status with stakeholders
- Meet with customers and stakeholders and translate their needs (i.e., challenges, problems, requests) for the team
- Represent the team to other cross-functional teams
Often these activities are a full-time job. Then there is the role of the product owner, which is (mostly) inwardly focused toward the team. They do things like:
- Attend the team’s Scrum ceremonies
- Actively participate in the evolution of the backlog (writing, refining, estimating, etc.)
- Set up the sprint demo agenda and invite attendees
- Provide the mission and vision for the product to the team
- Sign off on completed work and make requisite adjustments/pivots as required
As the role of product manager gets most of the “attention,” product owners prioritize that focus over the team, which is a huge mistake.
Since the team is doing the work, and the work contains the value, and the value is what the customers and stakeholders are ultimately looking for, then the focus should always be toward the team first.
I have a saying that the prime directive of the product owner is to “feed the team well.” Make sure that you don’t lose sight of that focus.
Lack an effective understanding of nature of agile (emergent) requirements
One of the ways in which agile requirements are fundamentally different from waterfall requirements is the notion of completeness. In waterfall, requirements are inherently done first. And the focus is on 100 percent completeness before implementation begins.
Agile is the opposite. We strive to get the requirements “good enough” but want to start learning more by implementation. Everything then emerges …
- The backlog refinement process is iterative and intended to provide emergent understanding of the work planned for future sprints.
- The sprint planning process as the team gains understanding by collaborating around work orchestration.
- During sprint execution and product owner work sign-off.
- During the sprint demo as final feedback is received and any adjustments made.
In agile, the requirements evolve up to the last minute before everyone “accepts” the story.
Sure, they enter the sprint fairly complete, but things are never 100 percent complete until story sign-off. That way, we’re gaining ongoing (emergent) understanding by not simply looking at words, but also looking at working software.
Building good habits into the role of the product owner
These five habits are just that – habits. As we strive to build more agile teams, we should recognize how practices vs. culture ultimately lead to our overall success. Review the five habits above and see if your teams are approaching product ownership in this way. It’s a great starting point, but unfortunately, that’s not the comprehensive list of anti-patterns. I’ll cover those in our next blog, so look for part 2 of this series next week.