3. Introduction to Lean Roadmapping

The purpose of a roadmap is to provide guidance on what problems could be solved in order to work toward the product vision. It’s not meant to be an exact outline of what’s going to be delivered and when, as that’s absolutely impossible to plan without giving up on precious time or quality. It is, however, incredibly helpful to be used as a way to lay out assumptions about what’s on the horizon (now-next-later), and check those assumptions with others to make sure the team has a full picture of what problems, opportunities, and challenges lie ahead. 

Product is uncharted territory

One fundamental thing to remember is that product is a big unknown. You’re building into uncharted territory.

There’s no blueprint to follow, no ‘right way’ to do this. It’s not like building a pre-fab house, which is really just about gathering the materials and putting it all together in a series of precise steps. 

It’s more like landing on a new, unknown shore, and knowing that you want to get to a big gold-topped mountain in the distance, and having to pick out the best path along the way. 

You’ve got certain resources with you now, and you’ll pick up more resources and knowledge along the way. It’s up to you and your team to survey your surroundings, and decide what you have, and what problems you need to solve as you go. 

Every product is a unique journey.

Time horizons, not timelines

This is where the concept of horizons come in. 

A great format for a lean roadmap is what we call the Now-Next-Later format of the roadmap. It does away with the timelines of the Gantt chart that end up trapping product people into committing false dates for their work, and instead groups initiatives into three buckets: Now, Next, and Later. It allows the product team to express different levels of granularity and certainty for each bucket. 

You’re standing here, at the present time, or what we’d call Now. You can see what’s keeping your team busy right now and what problems are right in front of you. 

It’s like if you landed on a new shore and immediately saw there was a bear in front of you. That’s your first problem to solve! It’s crystal clear, and unless someone sees a different, bigger problem, you better start thinking of ways to solve that problem.

You can also see way off into the distance. That mountain top you aspire to conquer later on. There are probably problems to solve there. Maybe something to do with keeping warm or ice climbing gear, but that’s too specific, and you can figure that out when you’re closer. You’re a long way off and there are a lot of things you can do before you get there to gather resources and knowledge, but if there are known, chunky problems, like, “Get up the mountain” it’s worth noting them down so you and your team can keep an eye out for ways to break them down and solve them over the course of the months and years of the journey ahead. 

You can also see into the middle distance (next), in various directions, to various levels of degrees. How well depends on how well equipped and what your starting position is now. You might spot opportunities to take advantage of that’ll help you along the way to reach your ultimate goals or problems that you’ll need to overcome or avoid. Maybe there’s a glistening city full of money and resources you could reach or there’s a bog you’ll need to get over. 

There are probably multiple paths you could take through this journey, and from where you’re standing, you don’t really know which is the best one. After all, the further things are in the distance, the less certain you are about them. It might be faster to build the bridge, but it means you miss the uplift in resources you get from visiting the city – but from here, maybe it’s a mirage in the desert anyways.

Unfortunately, you can’t just whip out your phone and pull up Google maps. Again, this is uncharted territory. There is no right answer. But some answers will be better than others. 

And the best answers will come from teams who lay out what they see on the road ahead, and regularly regroup to make sure they are still on the best path.

These horizons translate to a product roadmap.

Instead of a timeline, which is a single, date-driven line marching forward, think in terms of these three buckets – now-next-later.  

Now

Things that are in the Now column are the initiatives that are right in front of you. These are pretty crystal clear in terms of scope and other details.

Your design and development teams are likely busy working on these initiatives right now. You can even go into showing progress on individual experiments that are being tested to solve the problem expressed for each. 

Next

Initiatives in the Next column are getting close in terms of priority, and you’re pretty confident you need to learn about those initiatives and get them ready for your team to work on. Maybe you’re doing discovery on those problems and determining how you might solve those problems.

Later

Initiatives in the Later column are much further off, as if they are on the horizon, and you’re straining to see. These are often expressed as problems that you bet probably exist based on what you know today, but you don’t have enough information at hand to start breaking them down into more details. 

Stack up initiatives in your roadmap to show the order you think you might tackle them, and adjust as new things are learned about your market.

Focus on solving problems now, next, and later

The really key thing about this way of roadmapping is that it takes the focus off setting delivery dates for a bunch of features, and instead helps the team focus on which problems need to be solved, and in which order.

That way, no resources are wasted trying to plan a long way out. Everything that’s worked on can be tied back to a solid reason why it should be done – the business objective it’ll help you reach. There’s no waste of effort, and no need to revisit plans which become out of date.

Lay out assumptions on your roadmap

It helps the product team radiate information about the assumptions they are making, so they can check and change plans if they spot something that means they need to iterate. They’re not trapped into a format that shows false information or slowed down by dubious plans which don’t come to fruition.

It changes the conversation around roadmapping, from being one of presenting a bunch of features and implied promises of when things will be done into an opportunity to learn and iterate at the strategic level. 

Companies that use lean roadmapping have more robust strategies and less stressed product teams. You can focus your attention on achieving the most valuable outcomes, and spend your resources on the things that matter. You reduce your risk of failure and, overall, your product teams provide better value.

Objectives on a lean roadmap

Now, if you’re setting off on a journey like this, you can imagine a team might immediately start bickering. 

This is because they haven’t yet agreed on what they’re trying to achieve.  

They all know they want to reach the summit, but they have no framework for measuring their success, and therefore knowing whether they’re working on the right things. 

After all, if you’ve got no way of saying whether you’re working on the right things, who’s to say you’re working on the wrong thing? 

Roadmapping without objectives can be chaos

Objectives are high-level, and qualitative. Think of an objective as a goal you want to achieve in the future. They set clear direction and should provide motivation. It’s helpful to ask the question “how do we know we’re successful?” What things should we see moving, if we’re doing a good job?

You probably want a maximum of 3-5 objectives, per product team. Any more than that, and you’re not really giving instruction on what’s successful because basically everything is. 

Objectives usually have a time-based element to them too, so look for the top 3 things that should move you in the right direction that would indicate success in the short term. Later on, you’ll have the chance to set new objectives.

Objectives are essential to clear alignment

Objectives are essential to a solid roadmapping process. If you’re in a position to set objectives, make sure you’re making time to set and communicate objectives. 

If you’re in a company that lacks clear objectives, call this out! 

Point out that you can’t effectively help the business hit its goals if you don’t know what they are. 

Product vision and your lean roadmap

Your product vision is essential too. 

Your team needs to understand which hill in the distance they are aiming for, so they can aim in the right direction. 

What’s your gold summit in the distance? 

If you don’t have a clear product or company vision, stop here, and make sure you get that sorted first.

This template works well (and you can experiment with a live version here)

Putting together a lean roadmap

What do you have so far?

You’ve got a vision. You’ve got some objectives. 

You’ve got a starting point, and some visibility into now, next and later using our time horizons. 

Put those three things together, your vision, your objectives, and your time horizons, and you get a lean roadmap. 

Each of these blocks is problems to be solved. 

Each is linked to a specific objective. 

Here’s one popular configuration:

And another layout that encompasses the same elements, but groups initiatives by objective:

Experimenting on a lean roadmap

Your roadmap can be used to help guide you with experimentation and validating that you’re actually solving problems. 

Your lean roadmap can help you show experiments in progress.  

Each card is a problem to be solved, or an initiative, and is tied to an objective. 

Each card is then connected to a list of experiments that could be run in order to solve that problem and impact that objective. 

Thinking in terms of experiments helps your team think outside the box. The timeline roadmap format typically gets people thinking about which features need to be delivered and when. Thinking in experiments often turns up novel ways of breaking down problems.

Experiments are more than just features

After all, an experiment could be to add a new feature, as adding a new feature might just be the thing to solve a problem and impact an objective. But it might also be to improve a feature or remove a feature. Killing features can be a great way to improve usability, after all!

But an experiment could be entirely unrelated to features. Perhaps the experiment is to change the pricing or packaging or proposition of your product – maybe you want to run an experiment where you change the way you talk about your product on your homepage.

These are things that could solve problems and impact your objectives and are often cheaper and faster to pull off than building new features. 

Track the progress of experiments on your roadmap

You can use your roadmap to give you an overview of progress on ongoing experiments and reflect back on which ones are working or not.

When you finish a list of experiments, you don’t necessarily move on to the next initiative on the roadmap. You reflect and measure whether you’ve solved the problem that the initiative outlined. If so, your team can move on to solve the next problem, but if the problem persists, you might use the roadmap space as a prompt to brainstorm new experiments that might solve the problem in light of what you now know. 

Lean roadmapping bakes in an experimentation-driven way of working, and ensures your team is actually solving problems, not just shipping features.

Validating on a lean roadmap

Once a project is done in development, don’t just throw out these results or tuck them away somewhere you’ll never find them again.

A bad habit that’s seen all the time in teams:

You’ve released something, so you close all the tickets in JIRA, crumple up all the sticky notes on the wall, and start moving on to the next thing. 

This might seem good for keeping up your “agile cadence”, but it’s bad for ensuring that you’re actually making an impact. 

After all, just because something was launched, doesn’t mean it’s solved the problem you wanted it to!

Don’t just trash your roadmap! Use it to validate you’re solving problems.

Create the time and space for validation

It’s not that people in the team don’t understand that it’s important to move the right metrics, it’s that they often don’t have the permission and time to stop building, and actually do the measurements.

You need to create the time and the space to validate the work that’s being done.  

Instead, move them to a list of completed initiatives, some sort of validation roadmap. 

The purpose is to give you a space to track what was released and when, and then outline the results. 

Did it solve the problem and move the metric you were hoping it would?

By building this validation into your roadmap, you create a space to show the value of the work done.