If you hadn’t noticed I’m building a blog mini-series on the Product Owner role. Its a role I’ve long felt didn’t get the attention it should have. Frankly, in a Scrum setting, I think the Scrum Master gets too much attention and the Product Owner not enough.
One aspect in particular of the Product Owner role really annoys me: they have so much work to do.
Or rather, a Product Owners who is doing their job properly – as opposed to simply administering the backlog – has so many things they should potentially be doing.
So a few days ago I started to make a list…
Backlog administration: writing stories, reviewing and discussing suggested stories, splitting stories, weeding the backlog (throwing stories away), improving stories, putting value on stories, writing acceptance criteria
Working with the team: talking to the stories, reviewing work in progress, reviewing “completed” work, potentially signing-off or formally accepting stories, participating in 3-Amigos meetings with testers and developers, helping to improve the development processes
UXD: working even more closely with an UXD specialists because the two roles overlap, and possibly substituting for UXD specialists where they are absent.
Meetings: prioritisation pre-planning meeting, planning meeting themselves, stand-up meetings, retrospectives, show & tell demonstrations (potentially delivering them the show & tell themselves)
Interfacing to the wider organization: reporting and listening to internal stakeholders in authority, attending Governance and/or Portfolio review meetings, aligning product strategy and plans with company strategy and plans, plus feeding back to company strategy about their own product strategy and plans.
Planning: participating in Sprint planning with the team, planning for upcoming iterations (the rolling quarter plan as I like to call it), longer term planning which might take the form of a roadmap, a capacity plan, a scenario plan or all three
Customers 1: identifying customers and potential customer, segmenting the customer base, creating customer profiles and personas.
Customers 2: visiting customers, observing customers, talking to customers about stories and potential future work, reflecting on customer comments and feeding back to the team and other stakeholders.
Customers 3: similar activities to #2 for people and organizations who are not currently customer but who are potential customers (because potential customers who have unmet needs represent growth.)
I’m sure some of you are saying: “But we don’t have external customers, we have internal (captive) users”. And your right, if you have such “customers” then you have a subset of these activities. But then again, shouldn’t you be thinking about how our product is used by internal users to service the needs of external customers? And how you could improve that experience (for the customers) and improve the process (for the users?)
Marketing: inbound marketing the items just mentioned under customers plus market scanning (checking out the competitors) and potentially outbound marketing (advertising, PR, trade shows, etc.)
Sharing expert knowledge: providing knowledge about the domain and subject of development to the development team, supporting sales calls, demonstrating the product at shows. (And when the company is small helping the training and support teams.)
The offering: using the information gained in all these activities to refine the product/service offering to satisfy customers or improve business processes; Is it the right offering? Are you targeting the right customer segment? Should you be offering something else?
Close the loop: evaluating the effect on customers and/or process: Are the features bing used? Are non-feature improvements making a difference? What shouldn’t have been done? What arises form the changes that have been made? More software changes? Process changes?
Money: is all this making money? if the continued existence of the team positive to ROI?
Coincidentally, while I was preparing this blog Marty Cagan published a blog entitled “CEO of the Product Revisited” in which he discussed offered a list of all the discussions a Product Manager can expect to be involved with. That is no short list either. And as anyone who follows my writing already knows I see the Product Owner role as a kind-of Product Manager – more on that in a future blog.
This is not to say that all Product Owners should be doing all of these things. Asking one person to take all this on is probably setting them up to fail. Every product owner should recognise every item on this list. If they aren’t doing any of these items themselves then I expect they can either cross it off (doesn’t need doing where they work), or name the person who is doing it.
And I also expect every product owner can add some things to this list which I have overlooked.
In future blog posts I intend to discuss (again) the Product Owner as a Product Manager and how Product Owners can reduce their work load.
| Published on Java Code Geeks with permission by Allan Kelly, partner at our JCG program. See the original article here: Busy busy busy: What Product Owners do Opinions expressed by Java Code Geeks contributors are their own. |
