Consider Innovation and Personas When You Create Roadmaps, Part 5

We use product roadmaps to see where we want to go and the options we might take to get there. Yet, so many of our roadmaps offer only a single and certain destination. If we don't see options, we reduce our innovation decision points—and possibly disappoint our customers. Worse, we create products that don't fulfill our strategy, why the organization exists.

Instead of certainty, let's consider options in our roadmap—at least for certain personas.

Understand Your Personas

In this series, I've offered several kinds of roadmaps because each persona needs different information:

• Product teams need to focus on the now with some look-ahead to the future.
• Some kinds of customers might need more future information, but you can carefully limit what they see.
• And managers need some future assurance—and some options.

As a product person, you already know different users need different information.

Consider your need for innovation as part of where your product is in its lifecycle.

Clarify Your Need for Product Innovation

As I said, most of us live in the messy middle of problem challenges and the need for innovation. Let's use different roadmaps to show people where we are.

Here are the roadmaps I prefer to use and why:

If the team uses iterations, this roadmap works well, especially if the team uses rolling-wave planning. (See Consider Rolling Wave Roadmap and Backlog Planning for one post.)

The team can plan for the first two weeks, have a proposed plan for the next two weeks, and then a candidate/option-based plan for further out. As the team finishes stories, the product leader can update the planning. Yes, a little more backlog planning as often as the team completes a story.

When the product leader changes the candidates/options for the next wave, the team can see the effects of their actions.

I prefer a flow-based roadmap, so we “commit” to the work above the line. Then, as the team completes stories, the product leader can change what's below that line. Once the team finishes all the work above the line, the team can pull from the first story below the line—assuming there is time in this month or quarter.

Even better is when the team stops using months or quarters altogether and uses the idea of “next.”

If you have a need for high innovation, consider the possibility-oriented roadmap. Teams can use this too, because the idea of “candidate problems” and “Up Next” remove the certainty around the roadmap.

If you think you need more certainty, the future-oriented roadmap might work.

While these roadmaps might work for teams and customers, managers need different information.

Cycle Time Offers Forecasting in a Roadmap

If you have tried to use estimation with story points to create a roadmap, you've encountered the problem where the team “fails” to deliver in the expected time. That's because story points do not take delays into account.

However, your managers still need to have an idea of when they can expect the team to solve various problems. That's where cycle time allows you to forecast some problems into a roadmap.

Rather than a predefined roadmap, this six-quarter roadmap with options works for me. It offers me enough prediction closer in time, and more options farther out in time.

I hope that managers don't believe all the details in this roadmap, especially anything at least a quarter out. However, managers can see what the team(s) expect to finish.

I use the minimum roadmap when we need to use discovery for several weeks or months.

One important note: You must measure your cycle time to “commit” to anything on any roadmap—especially for managers. If you don't measure your cycle time, you don't know when you might finish an MVP or start something new. You can't know.

Summary

Roadmaps are one kind of information radiator. And each persona needs their own information. How much innovation does your product need now? Who needs to know what—and when? Yes, I suggest you consider your roadmap a “product” and treat it that way.

I prefer to commit to fewer specifics, but you might need to.

And, the more you can show options or possibilities, the more you might use a roadmap the way we used them for car trips all those years ago. We might know which problems we want to solve, but we don't always know how we will solve them—or when. Give everyone the chance to discover as you deliver, and use continual and rolling wave planning as you do.

The Series: