Product Owners and Learning, Part 4

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.

Example.AgileRoadmapOneQuarterIn 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.

All the posts:

3 thoughts on “Product Owners and Learning, Part 4”

  1. Good posts.. i had a chance to read all your posts on the product owners & learning parts. I have couple of questions

    1. Product manger learns many things from outside world (i.e. customers, analyst, market conditions) but end of the the he is responsible for revenue and he/she has to keep the existing customers happy by addressing their enhancement requests. How to you manage or prioritize between customer enhancements, tech backlog, defects, innovation & also from competition? What’s your advise on this?

    2. Product owners biggest challenge (at least what i have seen so for) is to split the stories into smaller chunks. For example, by splitting the stories into 1 day of work, sometimes it will become more of a task then a story. What do you suggestion on this?

    1. Anand, thanks for reading. For #1, ranking among all those things, I often ask these questions:
      – What prevents us from releasing what we want, when we want? How much of a delay does that list incur? Those questions help me see the technical debt and defects. I expect the tech backlog to be partly here also.
      – What do we need to do to respond to our market? Or, what do we need to do to create innovation in our market? These questions help me see the market concerns, possibilities, etc. I would expect some tech backlog here, and the planned releases.

      For me, this is the value of a larger, 6-quarter roadmap, and the smaller 1-3 month roadmap. You need both. If your competition changes, you want to be able to change the “what will we do now” and the product future (6-quarter roadmap).

      For #2, here is the question I often ask: What is the first thing we can do to provide value? I use an example of secure login in my workshop. The first story is (I’m abbreviating) successful login for an already-existing user. That means we can use a flat file of three users with plain-text passwords. The second story might be failed login for a user who does not exist.

      Notice that neither of these requires a database nor a specific way to encrypt passwords.

      You might not like these two stories. You might prefer a paper prototype as the very first thing you can do to provide value.

      Value might be learning for the PO or the team. Value might be something you can demo. Value might be something you provide (paper prototype) to guide the next set of stories.

      If you think that by splitting the story you will end up with tasks, I highly recommend the team swarm (or mob) over the story.

      Here’s the key idea: You can’t learn or deliver from work in progress. What can you do to deliver value or show learning?

  2. Pingback: New PM Articles for the Week of June 27 – July 3 - The Practicing IT Project Manager

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: