Mike Cottmeyer has been one of my longer-term colleagues in the agile community. He’s built a nice coaching business in the Atlanta area and has been contributing his ideas for quite some time. He’s someone that, when he writes something, I usually read it.
I don’t always agree with Mike. But that’s ok. He always makes me think (or rethink) differently and that’s quite valuable to me. I like to be challenged.
He recently wrote a blog post entitled: Kanban Isn’t The Answer To Bad Product Ownership. In it, he made the case the title implies. And he made it quite convincingly. But the post also made me consider a couple of things:
- How fundamentally important the Product Owner role is. Specifically, in Scrum, but generally in agile teams. I’ve seen the difference that an excellent Product Owner can make to a team. And conversely, the damage “bad ones” can do.
- And lament the number of 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 seen. In the hopes that we might be able to avoid some of them.
This is a 2-part post, where I’ll share a group of anti-patterns in each. So, let's get into it!
You might be a BAD Product Owner IF you…
Have a poor understanding of the entire role
So many trivialize the product owner role to one of simply providing (writing, delivering, confirming) requirements. 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 I call – the 4 quadrants of product ownership that attempts to illustrate this depth/breadth aspect 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
- Leadership
- 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. Mine included. No matter how you slice it, effective product ownership is a deep and broad skill that is not so easily found nor executed.
Are wearing multiple hats
I’ve encountered organizations that have asked managers, ScrumMasters, Business Analysts, Product Managers, and many other kinds of roles to also “wear the hat” of the Product Owner. It’s sort of a poor man’s view to staffing the role. And it’s also quite hopeful that these folks will have the time, after doing their day job, to also effectively contribute as a PO.
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, so they short-shrift it. Not really understanding the impact it has on the teams' results and delivered value. And being cheap in investing in the role undermines the value-delivery capabilities of the teams. 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 in 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 Product Owner role 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 of the decisions, and spending a great deal of time doing so.
I like the metaphor where it Takes a Village to own the backlog. In this case, the village is the entire team. And that the Product Owner is simply the mayor of the village. 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 ScrumMaster, and partner with their teams. It’s this shared ownership of the backlog and the decision-making that makes all the difference.
View yourself as the CEO of your product
I once was talking with Cory Bryan on his Deliver-It podcast. BTW: I highly recommend the podcast! And we got to talking about who “owned” the product. Cory made the statement that if stakeholders don’t make decision(s) or wouldn't engage with his backlog(s), then he would adopt the posture of CEO of the backlog.
I wrote about this in another podcast, but I want to emphasize my perspective here.
As a Product Owner, you represent the stakeholders and the customers. You don’t make the final decisions. Putting yourself in that role can be a huge mistake as you rarely (never) have the broad and deep view towards the product challenges that they do. You’re also NOT the final decider.
They are.
And if they are abdicating that responsibility, then you need to confront them about that. Not try to do their jobs for them.
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 towards the stakeholders and customers. They do things like:
- Create a business case and manage ROI
- Share status with stakeholders
- Meet with customers & stakeholders and translate their needs (challenges, problems, requests) for the team
- Represent the team to other x-functional teams
Often these activities are a full-time job. Then there is the role of the Product Owner which is (mostly) inwardly focused towards the team. They do things like:
- Attend the teams Scrum ceremonies
- Actively participate in the evolution of the backlog (writing, refining, estimating, etc.)
- Setup 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 Product Manager role gets most of the “attention”, Product Owners prioritize that focus over their 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 first towards the team.
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 that I think of 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% completeness before we start implementation.
Agile is the opposite. We strive to get the requirements “good enough” but want to start learning more by implementation. Everything 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 collaborating around work orchestration.
- During sprint execution and PO work sign-off.
- During the sprint demo as feedback is received and any adjustments made.
The “requirements” evolve in agile up to the last minute before everyone “accepts” the story.
Sure, they enter the sprint fairly complete. But things are never 100% 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. Here’s a blog post that helps explore the nature of agile requirements.
Wrapping Up
I hope these anti-patterns have resonated with you so far and inspired you to avoid them. But I’m not quite done yet. I’ll have another set to share in part-2 of this post.
Until then, stay agile my friends,
Bob.