If you wanted to communicate to people inside your company what problems you wanted your product to solve, how would you do that?
Did the word roadmap pop into your head?
What would you use if you wanted to keep people up to speed on what experiments you were trying to solve those problems?
Would it surprise you to read that you can use roadmaps for that also?
Well, you can use an experiment-driven roadmap for just that purpose.
What is an experiment-driven roadmap?
An experiment-driven roadmap is a communication vehicle that shows the experiments a product team (or collection of product teams) plans to try out in order to reach specific outcomes in various time horizons.
This kind of roadmap has between three to five columns that reflect time horizons and the items tracked on the roadmap are not features.
Time Horizons
The columns on a roadmap represent time horizons rather than time lines to get people to still discuss when without the false precision of a date.
These time horizons show the order in which the team is going to work on something, and the certainty surrounding whether they’ll work on it.
The time horizons you’ll typically see are now, next, and later.
Items in the Now time horizon reflect the items your product team is currently working on. You’re fairly certain you’re going to work on these items. Of all the items on the roadmap these, are the ones that are fully scoped out.
Items in the Next time horizon identify those items that you might pick up following the items in now. You may have some high-level information about the items in this column, but there is still more information you need to scope out.
Items on the Later time horizon are reminders of things you could do. It makes little sense to scope these items out because there’s an equal chance you will or won’t do something in this column.
Some product teams like to add one or two additional columns.
They may have a done column to reflect items that they have completed. The exact nature of the items (we’ll talk about that below) dictates whether that column makes sense and is helpful.
Some teams can be explicit about what they will not do, so they’ll add a never column to identify items that they just will not tackle. This column can be helpful where there’s a need to set some clear boundaries about what your product strategy includes and excludes.
Items tracked
Experiment-driven roadmaps do not track features, they instead track problems your product team is trying to solve.
Most product roadmaps identify what problems the team is tackling now and what they plan to tackle.
Experiment-driven roadmaps do that and give some insight into how your team will try to solve that problem. That’s where the experiments come in.
An experiment is a way to test if an idea or opportunity is viable, and allows your team to understand if that idea will solve your target problem.
Experiments represent initiatives that your product team tries in order to drive your target outcome. Experiments are structured as questions such as “can we do X?” or “how might we do x?”
When you identify experiments in that way, you reinforce that they are experiments and that they may lead to further actions based on what the experiments reveal.
There are a couple of different ways to structure an experiment-driven roadmap. Let’s look at both.
Track outcomes with experiments noted in Now column
If you want to maintain clear visibility about what problems you’re tackling now and what you’re planning to tackle later, you can use the approach shown above.
In this approach, outcomes are the principal item tracked on the board. Their position on the roadmap represents which problem a team is currently trying to solve.
When outcomes are in the now column, they’ll show the experiments that your team is trying to solve that problem.
There’s no point in identifying experiments for the problems you’re not trying to solve now, because you may not try to tackle those soon. It’s better to focus on the problems you’re trying to tackle today and build all of your experiments around that.
This approach may make more sense if you have several potential outcomes that you may eventually work on and you want some visibility into the experiments that your teams are currently trying.
The above example shows the activity of multiple teams. Each team focuses on a specific outcome.
If you’re using airfocus to create your roadmaps, you can create this style of experiment-driven roadmap by using a pair of Outcome-Based Roadmap workspaces tied together using the hierarchy feature. The parent workspace contains outcomes, and the child workspace contains experiments.
Track experiments in all columns
Here, experiments are the item that are tracked on the board. The swimlanes represent the distinct problems you’re trying to solve.
This form of an experiment-driven roadmap makes more sense when your organization has several product teams running experiments on a few outcomes. This view gives you a broad overview of what all experiments are going on.
If you’re using airfocus to create your roadmaps, you can create this style of experiment-driven roadmap by using an Outcome-Based Roadmap workspace and setting up the items as experiments.
Why would you create an experiment-driven roadmap?
Experiment-driven roadmaps help you keep the focus on achieving outcomes rather than defining solutions too quickly.
When you track experiments, you explicitly acknowledge that you don’t know for sure what the solution should be. You need to try various things out.
Those actions may add features, but they don’t have to. You may find you can accomplish the outcome you’re trying to hit by revising a feature that your product already has. You may also realize that the best way to hit your outcome is to remove a feature that your customers no longer need.
It’s also possible to drive an outcome without adding, changing, or removing a feature. You may find that if you change policies, how you talk about your product, or how you set your price.
Experiment-driven roadmaps also prevent you from delivering more features than you need to. Since the items on the roadmap represent problems you want to solve and ways that you might go about solving them, you can stick to trying out things that you think will drive an outcome. You’re no longer inclined to deliver everything just because it’s on the roadmap.
Experiment-driven roadmap vs Feature-driven roadmap
We’ve already mentioned that experiment-driven roadmaps explicitly do not contain features. That is the most definitive difference from feature-driven roadmaps, but there are some other differences that are worth noting.
Experiment-driven roadmaps focus on outcomes. Feature-driven roadmaps focus on solutions.
The items on an experiment-driven roadmap are more often options, whereas items on feature-driven roadmaps are viewed as things that have to be delivered.
Experiment-driven roadmaps intentionally drive you towards outcomes. Feature-driven roadmaps may accidentally get you to an outcome.
Experiment-driven roadmaps speak to objectives and not timelines. Feature-driven roadmaps are more likely to incorporate timelines and rarely speak to objectives.
Communicate about your experiments
Roadmaps communicate the problems you are trying to solve. Product experiments are an effective way to find the right solutions to the problems you’re trying to solve.
You probably have people in your company who expect to see a list of things you're doing to solve particular problems. Many of those people expect that list to be a series of features.
An experiment-driven roadmap will help you change the narrative to one about problems you’re solving and experiments you’re trying to find the right solution.
Kent McDonald
Read also
Build great roadmaps
