In the official guides all Product Owners are equal. One size fits all.
In the world I live in some Product Owners are more equal than others and one size does not fit all.
The key variable here is the amount of Authority a Product Owner has. In my last post I said that Authority is one of the four things every product owner needs – the others being legitimacy, skills and time. However there is a class of Product Owner who largely lack authority and who I have taken to calling Backlog Administrators.
About the only thing a Backlog Administrator owns is their Jira login. They are at the beck and call of one or more people who tell them what should be in the backlog. Prioritisation is little more than an exercise in decibel management – he who shouts loudest gets what they want.
A Backlog Administrator rarely throws anything out of the backlog, they don’t feel they have the authority to do so. As a result their backlogs are constipated – lots of stories, many of little value. Fortunately Jira knows no limits, it is a bottomless pit – just don’t draw a CfD or Burn-Up chart!
If the team are lucky the Backlog Administrator can operate as a Tester, they can review work which is in progress or possibly “done.” They may be able to add acceptance criteria. If the team are unlucky the Backlog Administrator doesn’t know enough about the domain to do testing.
I would be the first to say that the Product Owner role can be vary a great deal: different individuals working with different teams in different domains for different type of company mean there that apart from backlog administration there is inherently a lot of variability in the role.
The Product Owner role should be capable of deciding what to build and/or change.
So Product Owners need to know what the most valuable thing to do it. Part of the job means finding out what is valuable. While Backlog Administration is part of the job the question one should ask is:
How does the Product Owner know what they need to know to do that?
Backlog Administrators are little more than gophers for more senior people.
True Product Owners take after full Product Managers and Senior Business Analysts – or a special version of Business Analysts sometimes called Business Partners.
Product Owners should be out meeting customers and observing users. They should be talking about technology options with the technical team and interface design options with UXD.
Product Owners should understand commercial pressures, how the product makes (or saves) money for the company. Product Owners are responsible for Product Strategy so they should both understand company strategy and input into company strategy. Product Strategy both supports company strategy and feeds into company strategy.
Product Owners may need to observe the competitor landscape and keep an eye on competitors and understand relevant technology trends. That probably means attend trade shows and even supporting sales people if asked.
Frequently Product Owners will require knowledge of the domain, i.e. the field in which your product is used. Sometimes – like in telecoms or surveying that may require actual hands on experience.
And apart from backlog administration there is a lot of work to do to deliver the things they want delivered: they need to work with the technical team to explain stories, to have the conversations behind the story, write acceptance criteria, attend planning meetings, perhaps help with interviewing new staff and sharing all the things they learn from meeting customers, analysing competitors, debating strategy, attending shows, etc. etc.
I sure there are many who would rush to call the Backlog Administrator an “anti-pattern” but since I don’t believe in anti-patterns I don’t. I just think Product Owners should be more than a Backlog Administrator.
| Published on Java Code Geeks with permission by Allan Kelly, partner at our JCG program. See the original article here: Product Owner or Backlog Administrator?
Opinions expressed by Java Code Geeks contributors are their own. |
