Alternatives for Agile and Lean Roadmapping, Part 5: The Product Value Team

If you need to plan more often than once a quarter, how do you know how to re-plan? Instead of incurring the time and cost when you bring everyone together, consider the Product Value Team. (In past writing and presentations, I’ve called this the Product Owner Value Team. I am trying to change my term to the Product Value Team.)

The product value team is a different kind of a team. It’s related to a community of practice, but for one product. And, since the people on this team are already on feature teams (the POs) or on a program (the product manager), you might not have considered how these folks collaborate.

POs on one product who have different areas of a product need to work together to create a coherent roadmap for that product. And, since the POs work with their teams, they still need someone—a product manager—to elicit information from customers. They might need help from a BA to articulate what the customers want in ways the team can understand.

The PVT is a different kind of a team.

This is my first draft of an image of a Product Value Team (I am sure I will refine it. I welcome your suggestions for refinement!). Start at the bottom of the image. The POs are roughly the same color as the teams they represent.

I’m showing three feature teams here because I am not yet a good enough image creator to add more teams.

Because the product depends on all three of these feature sets, the POs coordinate in a PVT, product value team, along with the product manager. As the teams complete features, each PO updates their roadmap and the next backlog in whatever form they desire. And, when things change or when it’s time to re-plan the roadmap, the PVT gets together to plan.

The larger the effort, the more we can expect to re-plan. Why not re-plan with people who understand the backlogs?

This works reasonably well for independent features. That means the teams are feature teams and the features are straight-through, not curlicue features. If you have a ton of interdependencies between feature teams, you might not have feature teams or you might not be planning the smallest possible features. The PVT has a much more difficult time planning when the features are large and interdependent (the teams have trouble, too).

Should POs and teams never see customers? Of course not. They should see customers as often as they need to. But the PO is inward-facing, not outward-facing.

Should the product manager never work with a team? Of course not. Product managers should work with teams as often as possible, so the product manager can bridge the gap—with the POs—about what the customers need and what the organization wants to provide.

So, should the product value team (PVT) plan all by itself all the time? I’m not a fan of that either. However, for rolling wave planning inside a quarter (or whatever time period you like for replanning everything as a cadence), I like the PVT to plan together. If the PVT doesn’t understand the risks, maybe the PVT shouldn’t plan alone. Maybe the teams need to participate to expose risks and dependencies.

But I more often see POs who do understand the dependencies for the next small chunk of time, and who want to get through this quarter with an accurate plan. And, they’re not afraid to re-plan. They want to build a resilient program.

When the POs get together as a team, they can address the needs I see for resilience in a program (or a product) as in Part 4. The PVT doesn’t work as an Agile feature team with the same kind of backlog and ceremonies. They might decide to meet on a cadence, or they might meet as exception handling. Maybe they only meet when the organization has a need for nailing down a particular scope at a necessary time. I have a suggestion for the agenda for this meeting in my workshops and the book in development.

A Product Value Team can help a project/program increase its resilience to change, obtain feedback, and manage the prediction problem.

Now, one of the big problems with the entire road mapping issue is when managers want predictions or commitments. That will be part 6.

Here’s a summary of the parts to now:

• Part 1: Think in Feature Sets
• Part 2: Rolling Wave Planning
• Part 3: Flow-Based Roadmapping
• Part 4: Resilience, Prediction, and Feedback
• Part 5 (this one): Product Value Team
• Part 6: Managers Want Commitments