In Part 1, I said that product roadmaps are not like car roadmaps. But even car roadmaps showed places of interest—options—for the driver and passengers. If I stretch that analogy a little, managers need to see where we are predictable for the next bit of time, and the options we see for the future. We need to update those options as we learn more.
Too often, I see very predictable roadmaps for managers. But managers also need to see options so they can discuss the product strategy and refine the corporate strategy (two different conversations).
Predictability vs. Option Discussion for Roadmaps
Most teams use agile approaches because they want some feedback, internal and external, to guide the future product development. If we don't need feedback, we don't need an agile approach. (More on that later in this post.)
That feedback means we need product roadmaps to show options. We select from those options as we understand more about the problems we want to solve for customers.
As the team delivers and discovers, they can update the product strategy and then the product roadmap. As a benefit, the organization can update the corporate strategy as the product strategy changes.
Options allow us several paths to accomplish the product outcomes—or to change the product outcomes.
However, many managers want predictability in the form of 18-month roadmaps to see where the team is going with the product. Or to know when the team will finish the product development. Those roadmaps can work if we do not plan to change the product direction. (Even then, I don't recommend those kinds of roadmaps.)
First, let me talk about innovation and what that means for the roadmap possibilities.
Innovation Needs Can Drive Your Roadmap Choices
Not every product has the same need for innovation.
This image shows how I think about the innovation continuum. At the very left, the product path is clear because the problem is totally deterministic. Those products have these characteristics:
- The product development team knows the product path. They know the risks and when to deliver which solutions for the customers. They do not need to integrate discovery into their feedback loops.
- Because the team needs no discovery, the team can easily generate an 18-month roadmap (probably in the form of 6 quarters).
- The team might encounter in-the-team risks, such as people getting sick, but their cycle time is relatively constant. They can deliver to the plan.
In my experience, very few software products are on the Totally Deterministic side of the Innovation continuum. Even porting a product from one hardware platform to another, or changing the underlying software platform often requires some discovery. If you do have a totally deterministic product, you do not need an agile approach. See the lifecycle series and choose something else.
Let's talk about the range where most of us are, the messy middle, where we have trouble predicting how much discovery we need.
How Much Discovery Does Your Product Need?
The more discovery your product needs, the more your roadmap needs to include options. We will change our minds even with a little discovery. That means we need options. How can we manage the need for options with a manager's desire for predictability?
By showing the options in the roadmap.
This typical roadmap has at least two problems:
- Everything lines up on a quarter. Real life does not do that.
- Releases are only fast enough for the left side of the messy middle.
- There are no options in this roadmap, based on previous information.
We use agile (or incremental) approaches because we want to decide based on previous information.
But this kind of predictability is what managers appear to want. (These roadmaps look like Gantt charts to me.)
What if we offered managers the idea that we will finish features at a certain time, but we don't yet know which features they are? We might offer a different kind of roadmap then.
Roadmaps With Options Based on Cycle Time
We can offer managers roadmaps with options. We can do this with cycle time if we are in the messy middle of the innovation continuum.
Let's imagine we know about half the problems we want to solve with this product and we will use customer feedback for the other half. In that case, we can use a variation of the scope-based roadmap from before.
For each quarter, this roadmap first shows the expected MVPs above the lines. (I'm assuming these MVPs describe the customer outcome or problem.) Because we're using cycle time, we have a pretty good idea we can do everything above the black line in a given quarter. (We don't have a perfect idea, but a pretty good idea.)
Below the black lines are the options we might solve in that quarter. Those options depend on what we discover as we proceed.
I could live with a scope-based roadmap like this. And I bet your managers would be thrilled to know what you suspect you can predict (the upper MVPs in blue) and what you hope to do (the lower MVPs in that pink color).
Would all managers be willing to live with this? Probably not.
Many managers want to fill in “all” the boxes on a time-based roadmap. If that's what your manager wants, cut off the image from the black line down. Then specify the MVPs by quarter—and don't fill the quarter all the way. Literally, generate about a third or a half of the MVPs, create those blue boxes and don't tell the managers about the rest.
What if you don't know the cycle time because you're on a new product, have a new team, or you're in constant discovery?
Start with a minimum roadmap and update once you know more.
A Minimum Roadmap for Full Innovation
When we recursively discover what the product is, consider a minimum roadmap like this one. And, use a roadmap like this one if you have a new team or you have no idea what the cycle time might be for the team for this product.
Here's the problem with “newness” for a team or a product:
- The team does not yet know how to create stories of relatively the same size, or to right-size their stories.
- Too often, the team does not know how to collaborate effectively to pair, swarm, or mob on stories.
- That means their cycle time will range from “small” to “large” so they cannot predict when they can release an MMF or MVP to the customers.
Newness means you need experience doing the work before you can predict something for the managers. When teams minimize their WIP and create small-enough stories, they can release often and get feedback. As they learn, they can choose to create a different product roadmap, or stick with this one for a while.
The more innovation your product needs, the less predictability you can offer. And the less the managers should expect. That's why instead of asking, “How much will this cost” or “When will it be done,” the team needs to ask, “How much money or time will you invest in this effort?”
Choose the Roadmap for Your Innovation Needs
For most products in that messy middle, I much prefer roadmaps based on cycle time with options. If you're experimenting with outcomes and customers, choose the Minimum Roadmap without options, and limit it to no more than three months.
I do not find the typical roadmap useful, even though tools offer those kinds of roadmaps. But a roadmap is just like a team's board—you'll probably need to experiment before you can choose the “right” roadmap for your product. Start the roadmap on a board, in a drawing program, even in a spreadsheet before you start it in a tool. Then you'll learn what you need. (Yes, experiment with the roadmap and use double-loop learning to update it.)
Managers are not wrong for wanting predictability from their roadmaps. However, they more often need options. Give your managers what they need, not just what they asked for. And remember to give your assumptions with your roadmap.
The Series:
- Why Car Roadmaps Are Not the Same as Product Roadmaps, Part 1
- Choose How to Visualize Your Product Roadmap for a Team's Product Focus, Part 2
- Help Your Customers React the Way You Want with These Roadmap Options, Part 3
- What Senior Managers Want & Need from Roadmaps: Predictability and Options, Part 4
- Consider Innovation and Personas When You Create Roadmaps, Part 5