Choose How to Visualize Your Product Roadmap for a Team’s Product Focus, Part 2

As I said in Part 1, teams use backlogs and roadmaps to know what's now and what's next. Teams use backlogs for the day-to-day tactical decisions. And when teams can see what's next, they can keep the strategic decisions in mind.

What do teams need to know about the product now to focus their work?

  • Which users are first, for now.
  • The functionality the team wants feedback on, for now. This functionality is based on the problems to solve for now. (These problems might be about how to reduce risk, what the users need first, or an experiment the team needs to learn.)
  • Where the team thinks it's going next, even in the very short term.

Often, we think about the problems and ask the question, “When?” as in, “When can we see some progress?” That's why many people like time-based roadmaps.

I'm not a fan of time-based roadmaps, but here's how they work to focus the team.

A Time-Based Roadmap to Focus the Team's Work

If I was the product leader, I would write which feature sets and which problems they solve in each of these various minimum boxes. So Feature Set 1: MVP 1 might be Secure Login Part 1. That's the same as the feature set below in the flow-based roadmap.

I also assume that this team releases externally, to customers, at least once a month.

Notice the question marks for Month 3. Product leaders need the flexibility to replan.

My problem with time-based roadmaps is they look so certain. And the tools make them look even more certain. (This is the same problem as The Schedule Tool is Always Right schedule game.) The tools don't expect you to change your mind with rolling wave planning. Even more worse (!) is that too many people want to share this roadmap outside the team.

But this roadmap is for the team, not to share outside the team.

That's why I prefer a scope-based roadmap that's not inside a tool to focus the team's work.

A Scope-Based Alternative Roadmap to Focus the Team's Work

I like scope-based roadmaps, with the MVPs listed, because of that black line. We “must” finish everything above that black line before the end of the month. Once we do, we can pull from below that line. (For more detail, see Alternatives for Agile and Lean Roadmapping: Part 3, Flow-Based Roadmapping.)

We're not trying to cram everything possible into a given timeframe. We know our minimums, and if we use cycle time to plan, we can see which minimums might fit into a given month.

Note that the team does not attempt to “commit” to everything they can shove into a month. They “commit” to how little they can do—the work above the black line. With “how little” thinking, the product leader can change what's below the black line. And if the team didn't right-size the stories, the product leader can still be pretty sure the team will finish the must-do work before the next month.

When a client asked me about Parkinson's Law for scope-based roadmaps, I asked if the team normally let the work take more time to fill the allotted time. He didn't know. (The team did, because management insisted on pushing so much work onto the team.) I explained about right-sizing stories and cycle time. (See Measure Cycle Time, Not Velocity.) I'll discuss this more later in this series.

However, I never want to share this roadmap with people outside the team. That's because I, as a product leader, want to be able to refocus the details as the team and I learn from what the team releases.

I can avoid sharing this roadmap because it sits outside the various tools. Teams that use this roadmap can create a visualization that reflects what the team knows now and what they need to know later.  The tool does not force you to plan in too much detail too early. (See A Common Tool Trap: the Tool Will Help Your Delivery and Planning Problems.)  In addition, product leaders can replan as necessary. That's why the MVEs and MMMFs exist. The product leader might want to add more experiments and fewer minimum features to create the product's MVPs. They can replan for tactical and strategic advantage.

Replan at the Tactical Level for Strategic Advantage

Regardless of how the team manages the for-now roadmap, the team needs to finish small stories. The more small stories the team completes, the more flexibility the product leader has to replan. Replanning allows us to stop “how much” thinking and reconsider “how little” thinking.

Product leaders can replan as often as when a team finishes one small story. If you use iterations, I would not replan during the iteration—I would start to replan for the next iteration or the next month.

If you use a flow-based agile approach, you have much more choice for replanning. You might need to replan after several experiments, and then not replan until the team has released several MVPs.

Regardless of your agile approach, I prefer a cadence of planning at both the backlog and roadmap levels. If you always replan every Wednesday at 11 am, the team has a weekly cadence to both refine stories and review the roadmap. More frequent replanning, much less time to replan.

Teams Need Their Own Visualization

I see way too many teams use company-mandated roadmaps that add zero value to the team's work. However, I'm probably going to lose that argument.

In the meantime, what does your team need to know for the next few weeks? How can they have a little insight into the future? Those are the problems the team's roadmap solves. Consider how you will help your team solve those problems.

Remember, the team's roadmap cannot afford to make the same assumptions as a car roadmap: the road will change. The destination will change. If nothing else, the team will need some detours to learn. How will your team-based roadmap help solve those problems?

The next post will be about the issues of needing to share the roadmap with others.

The Series:

Leave a Comment

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

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