Part 1 was about how the PO needs to see the big picture and develop the ranked backlog. Part 2 was about the learning that arises from small stories. Part 3 was about ranking. In this part, I’ll discuss the product owner value team and how to make time to do “everything,” and especially how to change stories.
Let’s imagine you started developing your product before you started using agile. Your product owners (who might have been a combination of product managers and business analysts) gave you a list of features, problems, and who knows what else for a release. They almost never discussed your technical debt with you. In my experience, they rarely discussed defects unless a Very Important Customer needed something fixed. Now, they’re supposed to provide you a ranked backlog of everything. It’s quite a challenge.
Let’s discuss the difference between a product manager and a product owner.
A product manager faces outward, seeing customers, asking them what they want, discussing dates and possibly even revenue. The product manager’s job is to shepherd the customer wishes into the product to increase the value of the product. In my world, the product manager has the responsibility for the product roadmap.
A product owner faces inward, working with the team. The PO’s job is to increase the value of the product. In my world, the PO works with the product manager (and the BAs if you have them) to create and update the product roadmap.
A business analyst might interview people (internal and external) to see what they want in the product. The BA might write stories with the PO or even the product manager.
The product manager and the product owners and any BAs are part of the Product Owner value team. The product owner value team works together to create and update the product roadmap. In a large organization, I’ve seen one product manager, several product owners and some number of BAs who work on one product throughout its lifetime. (I’ve also seen the BAs move around from product to product to help wherever they can be of use.)
What about you folks who work in IT and don’t release outside the company? You also need a product manager, except, with any luck, the product manager can walk down the hall to discuss what the customers need.
If you work in a small organization, yes, you may well have one person who does all of this work. Note: a product manager who is also a product owner is an overloaded operator. Overloaded people have trouble doing “all” the work. Why? Because product management is more strategic. Product ownership is more tactical. You can’t work at different levels on an ongoing basis. Something wins—either the tactical work or the strategic work. (See Hiring Geeks That Fit for a larger discussion of this problem.)
When one person tries to do all the work, it’s possible that many other things suffer: feedback to the team, story breakdown, and ranking.
The Product Owner Value team takes the outside-learned information from customers/sponsors, the inside-learned information from the product development team (the people who write and test the product), and develop the roadmap to define the product direction.
In agile, you have many choices for release: continuous delivery, delivery at certain points (such as at the end of the iteration or every month or whenever “enough” features are done), or monthly/quarterly/some other time period.
Here’s the key for POs and change: the smaller the stories are or the more often the team can release stories, the more learning everyone gains. That learning informs the PO’s options for change.
In this example roadmap, you can see parts of feature sets in in the first and second iterations. (I’m using iterations because they are easy to show in a picture and because people often want a cadence for releasing unless you do continuous delivery.)
If the Product Development team completes parts of feature sets, such as Admin, Part 1, the PO can decide if Admin, Part 2 or Diagnostics, Part 1 is next up for the team. In fact, if the PO has created quite small stories, it’s really easy to say, “Please do this story from Admin and that story from Diagnostics.” The question for the PO is what is most valuable right now: breadth or depth?
The PO can make that decision, if the PO has external information from the Product Manager and internal information from the BA and the team. The PO might not know about breadth or depth or some combination unless there is a Product Owner Value team.
Here are some questions when your PO wants everything:
- What is more valuable to our customers: breadth across which parts of the product, or depth?
- What is more valuable for our learning: breadth or depth?
- Does anyone need to learn something from any breadth or depth?
- What cadence of delivery do we need for us, our customers, anyone else?
- What is the first small step that helps us learn and make progress?
These questions help the conversation. The roadmaps help everyone see where the Product Owner Value team wants the product to go. I’ll do a summary post next. (If you have questions I haven’t answered, let me know.)
Someone needs to learn about what the customers want. That person is outward-facing and I call that person a Product Manager. Someone needs to create small stories and learn from what the team delivers. I call that person a Product Owner. Those people, along with BAs compose the Product Owner Value team, and guide the business value of the product over time. The business value is not just features—it is also when to fix defects for a better customer experience and when to address technical debt so the product development team has a better experience delivering value.
I’ll do a summary post next. (If you have questions I haven’t answered, let me know.)
If you want to learn how to deliver what your customers want using agile and lean, join me in the next Product Owner workshop.
| Reference: | Product Owners and Learning, Part 4 from our JCG partner Johanna Rothman at the Managing Product Development blog. |
