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?”
- featured image: alessio-zaccaria-po1ffK4lLMw-unsplash.jpg
- header image:jr-korpa-AsMlld5e2I-unsplash.jpg
- all other images fall under Google Creative Commons license
