The 4 Product Owners you meet in Hell, (and the 1 you meet in Heaven)

There are several traits that are essential to good Product Ownership, but, like many aspects of an Agile organization, there has to be a balance. Out of balance, pretty much everything goes to hell.

I hinted at this topic recently in a series of podcast interviews with Vasco Duarte on the Scrum Master Tool Box. I’ve been noodling on this for a long time as a potential workshop or even book, but instead of waiting that long to share the idea, I decided to put the premise out here in the hopes that you would think about it too and perhaps compare these “archetypes” to Product Owners with whom you work or even to your own lives.

As you read, you might feel puzzled by the fact that some of the traits listed seem like positive attributes. That’s because they are. However, when out of balance, these same positive attributes can become counterproductive at best, but more often they corrode the team’s cohesion, belief in the product, and the Product Owner’s own credibility.

Marcia the Micromanager:

has “helpful” advice on every aspect of every step the development team might take.
is often a former developer who knows the system well
tells customers how long something will take or worse–gives them a date–without consulting the team.
gets frustrated at backlog refinement and asks questions like: ”Why can’t I just tell the team what I want them to do?”
sees every request as a puzzle to be solved
so focused on “Can we?” that she forgets to consider “Should We?”
wants to cover every edge case
gets so far down into the weeds that she either forgets about a product vision or her product vision becomes so muddy that no one can see it–even herself
Sprint themes include “various cleanup work”

Douglas the Doormat

derives tremendous satisfaction in delighting the customer–by saying yes to everything.
often forgets to ask the team about technical feasibility, scalability, or supportability
is possibly addicted to the look in the customer’s eye when he says “Absolutely!”
forgets that the short-term relief of saying “absolutely” is offset with the guilt of not delivering
lacks actual negotiation skills or even the ability to talk to the customer about her or his goals
lacks a product Vision or has said “yes” to so many things, the vision is confusing or obscured
often appears frazzled to the team, but smooth and cool at product demos/ Sprint reviews
often lets the team come up with the solution–” just as long as we are going to get it done“
customers get increasingly frustrated with missed dates or lack of a coherent plan
when the team can’t deliver on his promises, he will throw them under the bus
frequently burns out quickly because customers and the team lose trust in him
sprint themes include customer names. e.g. “Karen’s feature update.”

Big Bang Bob

has a vision and it will be delivered all at once, . . . next year
says the team should prioritize the backlog but is frustrated if the backlog does not align with his vision
believes that the customers complain so much because they don’t have clear goals, . . .like he does
focuses on promoting the “big thing” to customers and stakeholders with non-functional graphics, slide decks, and web pages
doesn’t have a plan for how to support the new big thing once deployed
frequently responds that “Fixing Technical Debt will have to wait until after we deploy”
promises delivery dates without consulting the team
prefers ad-hoc assembly of project teams (“Tiger Team”) to working with established Agile teams–“Handpicked the team myself!”
doesn’t understand that a newly assembled team won’t have the same throughput or predictability as the team(s) its members were pulled from.
teams get frustrated with him, but customers and stakeholders like Bob’s initiative. . . for a while. . . until he doesn’t deliver
sprint themes are almost always “project name.x” to make it seem like the work has been broken down into small, regular releases

Vicky the Visionary:

has a vision, but it’s all in her head. (i.e Vicky seems to know something about the product’s direction that nobody else knows)
is confident in the mechanics of Agile and team cohesion, (but secretly lacks confidence about her product vision)
attends every standup and has answers for all work in-flight
enthusiastically engages the team in backlog refinement
has very clear acceptance criteria for every story
accepts work after review and stays engaged at all times
negotiates with the team over technical debt stories in a sprint, but gets nervous about its impact
gets along well with the team, but customers and stakeholders develop frustration or distrust
over time, customers and team members alike begin to ask–“Where are we going with this product?”
sprint themes have cool but abstract names that are part of an extended metaphor

Product Owners can have a deep impact on your team, your product, or even your entire company. It is always surprising to me why companies do not put more emphasis on training Product Owners and Product Managers in leadership itself–to hold a healthy connection–and balance–between customer goals, their own product vision, and the team that is building their product.

So what does balance look like? Allow me to introduce,

Balanced Beatriz

pays attention to detail when necessary and has a clear sense of what “necessary” means
listens to the team and has full conversations with them
always has an articulated vision, which she may revise occasionally–but only after clarifying with team and customer
is always earning revenue with her small releases
knows her customer’s goals better than they know them themselves
understands that technical debt can grind the system and team to a halt and negotiates sprint content accordingly
shines at sprint reviews/demos because she can tie the work that the team has completed into how it is delivering on the product vision
owns problems the way she owns the product– with humble confidence, a clear sense of direction, and an eagerness to get on track
welcomes reviewing throughput and predictability trends of successfully deployed work with the scrum master and the team
uses confidence interval data to provide estimated delivery ranges of work to customers and stakeholders
sprint themes are clearly tied to the delivery of the product vision

To wrap up, I ask you to consider the following:

Do any of these Product Owner types sound familiar?
What other types would you add?
Do you see any of your own struggles in these descriptions?
What are some techniques you would use to help the four product owners be more like “Balanced Beatriz?”