Product Owner Anti-Patterns

The Product Owners have been nominated, but wait …

Now there it is. This long expected new role of the Product Owner (PO) coming with our Scrum implementation. It might have taken such a long time, that somebody came on board, really taking care for our product, focusing on stakeholder needs, business value, creating real impact. Eventually somebody is here to answer all the hard the questions of the development team, providing feedback and taking decisions.

Two days of a training class, with or without certification, via Scrum Alliance, Scrum.org or whatever else, and here we go. Each Product Owner – or sometimes even Product Owner team (ups please don’t get me into this discussion from here) – whom I taught, is aware of the notion of the PO role being quite straight, but really really hard applying it in practice. And still, as it is crucial regarding WHAT we focus on with our Agile efforts, it is so important fro any organization going for Scrum (there is lots of space taking care for these duties without Scrum and a PO role, but that’s another story).

Hence it might help to list a few patterns, which you rather should look after, avoid or at least finally mitigate, in order not to mislead you whole initiative (therefore the notion of “Anti-Patterns”). Last but not least these anti-patterns are not just some possible threat to your product and your Scrum initiative. But we are observing them so often. Quite likely you know some PO being into them right now. So let’s check out the list.

We might talk about a PO anti-pattern, when we observe a PO …

• Not collaborating with team(s) and team members on why product backlog items make sense, how they fit into the bigger picture and when, where and how they could be properly validated.
• Mainly running their stuff from Jira documentation (or any other electronic tool, especially when sitting in a refinement meeting) instead of interacting via more rich media, such as whiteboards, sketching etc.
• Not getting out of the building (sometimes also doing this with the teams), talking to real customers, users about their pains & gains.
• Just pursuing functionality as-is in terms of requirements, instead of questioning the reason in front of potential customer needs and business risk
• Treating a product backlog as a (endless growing) list of requirements instead of a pool of optional ideas
• Requesting implementation of requirements without valid understanding of business needs and risks
• Rather triggering implementation of product backlog items, instead of running up-front validation based upon defined hypothesis
• Rather talking in terms of existing business jargon, instead of breaking with “we always did it this way” and questioning what is really valuable to customers
• Focusing on the “As a … I want to … so that …” pattern, instead of focusing on the actual purpose, objectives and narrative behind a story together with stakeholders and teams
• Not having clear acceptance criteria per user story, which shall be due for implementation
• Rather expressing technical user stories, instead of focusing on business related user stories (WHAT instead of HOW)
• Asking teams for more productivity instead of understanding their system’s capability and the need for slack capacity
• Not providing early feedback to teams on ongoing work during a sprint
• Not considering clarity of product backlog items from a business perspective before involving the team (considering something like “Definition of Ready”)
• Not letting team members talk directly with stakeholders regarding solution / implementation details, instead being in a “Single point of everything” position, with a tendency to micro-management around product aspects
• Relying on a Scrum Master only in order to get blockers for definition or implementation of product backlog items out of their way

Mature Organizations don’t get stuck with a PO role prescription

Finally, if after one year into Scrum, an organization still engages the initial PO role assumptions, they probably got stuck with their Scrum. And being stuck in this sense means, you are not getting enough value, no impact out of it. And you invest and pain through organizational change may have been way higher, than any measurable outcome. Nothing you would like to talks about with your business owners.

Our Scrumban book to be published in 2017. Get in touch via our newsletter and start receiving goodies earlier.

I believe it is important to understand, that a potentially “religious” start with Scrum was just a beginning and it is not about perfecting Scrum. It can only be about perfecting your own product development game, your service ecosphere, your capabilities, your own strategic position. It might be helpful considering thoughts from Bob Martin (signee of the Agile manifesto), who recognized the Scrum type of organizational concept rather as a not helpful divider between business and technology areas, opposite from what had already been achieved via the XP method for their rather closer collaboration. Scrum’s organizational separation of concerns seems to address organizational dysfunctions by people taking care of product development, just everyone for their part. But it is important not to let this turn into a new dysfunctional setup over the longer term.

Having said this, a more mature PO role will rather tend to approach product management responsibilities, while initial PO tasks would rather be spread across the organization. Finally no organization really needs product owners. But it needs product ownership.

Product Ownership does not need heroic individual efforts. It is rather an organizational capability …

Depending upon the specific industry, PO practices in the meanwhile might rather have engaged for concepts such as Design Thinking and Lean Startup. And running a mature product organization will rather mean, tasks spread collaboratively across the organization of demand and supply, engaging educated decision-making on business opportunities (instead of “requirements”) aligned with appropriate predictability in supply. So at least after one year into Scrum it is time for your Scrum litmus test! And this should definitely start around the product, whether you created impact on your markets, better managed opportunities and risk for your stakeholders, could engage for collaboration, have people taking over true responsibility in a trustful environment. There is lots to talk about, how to get there, where to look after, if you already achieved this and how to improve further.

We teach modern ways for avoiding these types of anti-patterns with our Advanced Product Owner, Scrumban, Lean Product Discovery and Lean Product Management and Lean Startup classes.

Did we miss anything? Any ideas or known complimentary resources you want to add? Want to express your experience or opinion? We are very interested in your feedback.

And if you are interested in our upcoming Scrumban book (due 2017), just join our newsletter.