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.
Want to receive these posts by e-mail? – join the newsletter today and receive a free eBook: Xanpan: Team Centric Agile Software Development
Pingback: Scrumbanarchy links of a complete afternoon of reading | ipes-ent.com
Nice article! Three points that I would add to this. First, for medium to large companies, this huge variation of items is why it is common to see Product Managers and Product Owners to help manage the load. I know that many only see POs as a “role”, but the skillset to do it well starts to diverge from the skillset to do Product Management well and when you introduce the time out of office to be “in the market” (customer visits, industry events, trade shows, etc.), it is very difficult to leave the teams without that pivotal voice.
Second, in terms of UXD, this is an area that is very dangerous. Product Owners need to focus on the “what”, “why”, “who” and “when” of the market need and allow the team flexibility to uncover the best “how”. If they are leveraging a UX Designer, then they can delegate the “how” to them easily. However, if they are not, the onus should fall to the team (with PO contribution) and not back to the PO. If the Product Owner starts out with a fleshed out UX Design (Design by its very nature is a “how”), it will be very difficult for the team to unsee that input and brainstorm new/better ideas. Even worse, team dynamics (and psychological safety) can quickly devolve into a “just do what I say” approach which will drive down the team engagement, fundamentally losing the cross-role collaboration and brainstorming that is key to a successful team.
Third, and related to the second, the most important job that a Product Owner can play is to be the “chief evangelist” of the Solution. They need to ensure the teams know the importance of their work in the market, how what the teams are doing are addressing market problems and what are the long-term plans of the business (6-12+ months out). These two points (along with the previously mentioned psychological safety) are a majority of the factors that Google found when researching the characteristics of highly successful team.