Three Tips for Product Owners

As I work with more clients on their programs, I see that what might work for a product owner for a team does not work for a program. In a program, if the product owner is shortsighted, does not take advantage of agile/lean for updates, and does not have small features, the program loses momentum. Here are my three tips:

AgileRoadmap.copyright-1080x7941. Take the big picture perspective.

When the product owner (or, in this case, a program product owner) creates a several quarter rolling wave roadmap the teams can see the product direction. This helps the teams see avoid bad product decisions that might inadvertently prevent the product from taking a direction the PO would like.

There is a challenge with this. Teams can rarely, if ever, commit to an entire quarter’s worth of work. That’s okay. The roadmap is a wishlist. The roadmap informs and guides the product development. Teams need detailed backlogs.

AgileRoadmapOneQuarter.copyright-1024x7622. Use agile and lean to update the roadmap often, as in every couple of weeks.

I know of just a couple of teams who can plan for up to three iterations and not replan. Some teams can plan for two iterations, some for one. Even if you can complete features according to a one-quarter roadmap, the product owner needs the ability to change the ranking of the remaining features.

As the teams finish features, it’s the product owner’s job to accept the features, or not. And, it’s the product owner’s job to update the one-quarter roadmap—and maybe the multiple quarter roadmap.

  1. The bigger the product, the smaller the features/stories need to be.

I’m working with some programs who have only 5 or 6 teams. I’m working with some who have 20, 30, 40 teams. That’s a ton of people. How do those people stay in sync? By integrating and creating tests that test the product, end to end. If the stories are large, the teams have a ton of work in progress and lose the ability to collaborate easily. This can be a huge challenge for the product owners and teams.

For one-team projects, I like one and two-day stories. That way the product owner can see progress every day. (I’m happy if it’s even more often than that! Two days is my max story size.)

I know product owners who can barely make time for one meeting an iteration with their teams. That does not provide the product owner feedback about the story size, or what is in the stories. Stories tend to become more complex. Then, the team doesn’t finish the stories and everyone wants to know why.

When you have smaller stories, you see the value in what the team(s) do, all the time. The teams build momentum.

Making stories small requires you think about how little you can do, not how much. That’s a huge change, especially in a program.

Those are my three tips for today:

  1. Create a big picture rolling-wave roadmap.
  2. Update the roadmap often, as teams complete features.
  3. Create small stories so the team(s) can maintain momentum.

If you liked this post, you might want to join Marcus Blankenship and me for our Practical Product Ownership training. These things are tricky enough when you are inside the organization. They are more difficult when you are an agency/consultant working for the client.

Tags: , , , , ,
Previous/Next Posts
« »


  1. Andreas Ebbert-Karroum


    thanks for these useful tips. As a product owner I can onyl agree that a rolling theme overview is very useful to visualize the general direction of the product.

    I myself am using the “product menu” metaphor for that. I am curious what Your feedback would be. For us, it is working really well for us in our small (compared to the context in which You usually operate) team.

    Thanks for sharing Your thoughts and insights,


    • johanna

      Andreas, I love your metaphor. Seeing your product that way makes it much easier to select what you can do now, and what you can do later. And, how much of what you must do now vs. what you can wait for. Nice!

      • Andreas Ebbert-Karroum

        Exactly. We always have a main theme (main dish) per sprint and choose sides that make up a healthy meal. We try to choose sides, that emphasize on something differenz than the main dish: if the main dish is maybe not directly user facing, choose a side order with direct visibility so that we can do some sales and marketing with the new feature. If the main dish is more strategic, choose sides which satisfy direct customer requests, etc. You get the idea 🙂

        Thanks for Your feedback. Andreas



  1. New PM Articles for the Week of July 6 – 12 - The Practicing IT Project Manager - […] Johanna Rothman has gathered some insights for program-level product owners, and shares three of them with us. […]

Submit a Comment

Your email address will not be published. Required fields are marked *