{"id":9412,"date":"2021-03-05T20:31:58","date_gmt":"2021-03-05T20:31:58","guid":{"rendered":"https:\/\/www.prodpad.com\/?post_type=pp_resource&p=9412"},"modified":"2023-01-11T17:07:10","modified_gmt":"2023-01-11T17:07:10","slug":"intro-to-lean-roadmapping","status":"publish","type":"pp_resource","link":"https:\/\/www.prodpad.com\/resources\/guides\/ditch-the-timeline-roadmap\/intro-to-lean-roadmapping\/","title":{"rendered":"Introduction to Lean Roadmapping"},"content":{"rendered":"\n
\n
\n
\n
\n
\n
\"Building<\/figure>\n<\/div>\n<\/div>\n\n\n\n
\n

3. Introduction to Lean Roadmapping<\/h1>\n\n\n\n

The purpose of a roadmap is to provide guidance on what problems could be solved in order to work toward the product vision. It\u2019s not meant to be an exact outline of what\u2019s going to be delivered and when, as that\u2019s absolutely impossible to plan without giving up on precious time or quality<\/a>. It is, however, incredibly helpful to be used as a way to lay out assumptions about what\u2019s 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.\u00a0<\/p>\n\n\n

\n
\"Our<\/figure>\n<\/div>\n\n\n

Product is uncharted territory<\/h2>\n\n\n\n

One fundamental thing to remember is that product is a big unknown. You\u2019re building into uncharted territory.<\/p>\n\n\n\n

There\u2019s no blueprint to follow, no \u2018right way\u2019 to do this. It\u2019s 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. <\/p>\n\n\n\n

It\u2019s 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. <\/p>\n\n\n\n

You\u2019ve got certain resources with you now, and you\u2019ll pick up more resources and knowledge along the way. It\u2019s 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. <\/p>\n\n\n\n

Every product is a unique journey.<\/p>\n\n\n\n

Time horizons, not timelines<\/h2>\n\n\n\n

This is where the concept of horizons come in. <\/p>\n\n\n\n

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.\u00a0<\/p>\n\n\n\n

You\u2019re standing here, at the present time, or what we\u2019d call Now. You can see what\u2019s keeping your team busy right now and what problems are right in front of you. <\/p>\n\n\n

\n
\"The<\/figure>\n<\/div>\n\n\n

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

\n
\"Right<\/figure>\n<\/div>\n\n\n

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\u2019s too specific, and you can figure that out when you\u2019re closer. You\u2019re 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, \u201cGet up the mountain\u201d it\u2019s 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.\u00a0<\/p>\n\n\n\n

\"Off<\/figure>\n\n\n\n

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\u2019ll help you along the way to reach your ultimate goals or problems that you\u2019ll need to overcome or avoid. Maybe there\u2019s a glistening city full of money and resources you could reach or there\u2019s a bog you\u2019ll need to get over.\u00a0<\/p>\n\n\n\n

\"There<\/figure>\n\n\n\n

There are probably multiple paths you could take through this journey, and from where you\u2019re standing, you don\u2019t 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\u2019s a mirage in the desert anyways.<\/p>\n\n\n\n

\"Lots<\/figure>\n\n\n\n

Unfortunately, you can\u2019t 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. <\/p>\n\n\n\n

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.<\/p>\n\n\n\n

\"Now-Next-Later
The Now-Next-Later roadmap allows initiatives to be shared at different levels of granularity<\/figcaption><\/figure>\n\n\n\n

These horizons translate to a product roadmap.<\/p>\n\n\n\n

Instead of a timeline, which is a single, date-driven line marching forward, think in terms of these three buckets – now-next-later.\u00a0\u00a0<\/p>\n\n\n\n

Now<\/h3>\n\n\n\n

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. <\/p>\n\n\n\n

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. <\/p>\n\n\n\n

Next<\/h3>\n\n\n\n

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

Later<\/h3>\n\n\n\n

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

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.<\/p>\n\n\n\n

Focus on solving problems now, next, and later<\/h2>\n\n\n\n

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. <\/p>\n\n\n\n

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

Lay out assumptions on your roadmap<\/h3>\n\n\n\n

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\u2019re not trapped into a format that shows false information or slowed down by dubious plans which don\u2019t come to fruition.<\/p>\n\n\n\n

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. <\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Objectives on a lean roadmap<\/h3>\n\n\n\n

Now, if you\u2019re setting off on a journey like this, you can imagine a team might immediately start bickering. <\/p>\n\n\n\n

This is because they haven\u2019t yet agreed on what they\u2019re trying to achieve.  <\/p>\n\n\n\n

They all know they want to reach the summit, but they have no framework for measuring their success, and therefore knowing whether they\u2019re working on the right things.\u00a0<\/p>\n\n\n\n

After all, if you\u2019ve got no way of saying whether you\u2019re working on the right things, who\u2019s to say you\u2019re working on the wrong thing? <\/p>\n\n\n\n

Roadmapping without objectives can be chaos<\/h3>\n\n\n\n

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\u2019s helpful to ask the question \u201chow do we know we\u2019re successful?\u201d What things should we see moving, if we\u2019re doing a good job?<\/p>\n\n\n\n

You probably want a maximum of 3-5 objectives, per product team. Any more than that, and you\u2019re not really giving instruction on what\u2019s successful because basically everything is.\u00a0<\/p>\n\n\n\n

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\u2019ll have the chance to set new objectives.<\/p>\n\n\n\n

Objectives are essential to clear alignment<\/h3>\n\n\n\n

Objectives are essential to a solid roadmapping process. If you\u2019re in a position to set objectives, make sure you\u2019re making time to set and communicate objectives. <\/p>\n\n\n\n

If you\u2019re in a company that lacks clear objectives, call this out! <\/p>\n\n\n\n

Point out that you can\u2019t effectively help the business hit its goals if you don\u2019t know what they are.\u00a0<\/p>\n\n\n\n

Product vision and your lean roadmap<\/h2>\n\n\n\n

Your product vision is essential too. <\/p>\n\n\n\n

Your team needs to understand which hill in the distance they are aiming for, so they can aim in the right direction. <\/p>\n\n\n\n

What\u2019s your gold summit in the distance? <\/p>\n\n\n\n

If you don\u2019t have a clear product or company vision, stop here, and make sure you get that sorted first.<\/p>\n\n\n\n

This template works well (and you can experiment with a live version<\/a> here)<\/p>\n\n\n\n

\"Product<\/figure>\n\n\n\n

Putting together a lean roadmap<\/h3>\n\n\n\n

What do you have so far?<\/p>\n\n\n\n

\"So<\/figure>\n\n\n\n

You\u2019ve got a vision. You\u2019ve got some objectives. <\/p>\n\n\n\n

You\u2019ve got a starting point, and some visibility into now, next and later using our time horizons. <\/p>\n\n\n\n

Put those three things together, your vision, your objectives, and your time horizons, and you get a lean roadmap. <\/p>\n\n\n\n

Each of these blocks is problems to be solved.\u00a0<\/p>\n\n\n\n

Each is linked to a specific objective. <\/p>\n\n\n\n

Here\u2019s one popular configuration:<\/p>\n\n\n\n

\"Now
A basic Now\/Next\/Later roadmap<\/figcaption><\/figure>\n\n\n\n

And another layout that encompasses the same elements, but groups initiatives by objective:<\/p>\n\n\n\n

\"Lean
View your product roadmap in objective streams rather than priority stacks<\/figcaption><\/figure>\n\n\n\n

Experimenting on a lean roadmap<\/h2>\n\n\n\n

Your roadmap can be used to help guide you with experimentation and validating that you\u2019re actually solving problems.\u00a0<\/p>\n\n\n\n

Your lean roadmap can help you show experiments in progress.  <\/p>\n\n\n\n

Each card is a problem to be solved, or an initiative, and is tied to an objective. <\/p>\n\n\n\n

Each card is then connected to a list of experiments that could be run in order to solve that problem and impact that objective.\u00a0<\/p>\n\n\n\n

\"Lean
Show the progress of experiments on your product roadmap<\/figcaption><\/figure>\n\n\n\n

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.<\/p>\n\n\n\n

Experiments are more than just features<\/h3>\n\n\n\n

After all, an experiment could <\/em>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 <\/em>a feature. Killing features can be a great way to improve usability, after all! <\/p>\n\n\n\n

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. <\/p>\n\n\n\n

These are things that could solve problems and impact your objectives and are often cheaper and faster to pull off than building new features. <\/p>\n\n\n\n

Track the progress of experiments on your roadmap<\/h3>\n\n\n\n

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. <\/p>\n\n\n\n

When you finish a list of experiments, you don\u2019t necessarily move on to the next initiative on the roadmap. You reflect and measure whether you\u2019ve 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. <\/p>\n\n\n\n

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

Validating on a lean roadmap<\/h2>\n\n\n\n

Once a project is done in development, don\u2019t just throw out these results or tuck them away somewhere you\u2019ll never find them again.<\/p>\n\n\n\n

A bad habit that\u2019s seen all the time in teams:<\/p>\n\n\n\n

You\u2019ve 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. <\/p>\n\n\n\n

This might seem good for keeping up your \u201cagile cadence\u201d, but it\u2019s bad for ensuring that you\u2019re actually making an impact. <\/p>\n\n\n\n

After all, just because something was launched, doesn\u2019t mean it\u2019s solved the problem you wanted it to!<\/p>\n\n\n\n

Don\u2019t just trash your roadmap! Use it to validate you\u2019re solving problems.<\/em><\/p>\n\n\n\n

Create the time and space for validation<\/h3>\n\n\n\n

It\u2019s not that people in the team don\u2019t understand that it\u2019s important to move the right metrics, it\u2019s that they often don\u2019t have the permission and time to stop building, and actually do the measurements.<\/p>\n\n\n\n

You need to create the time and the space to validate the work that\u2019s being done.  <\/p>\n\n\n\n

\"\"
Validate outcomes in the completed section of your roadmap<\/figcaption><\/figure>\n\n\n\n

Instead, move them to a list of completed initiatives, some sort of validation roadmap. <\/p>\n\n\n\n

The purpose is to give you a space to track what was released and when, and then outline the results. <\/p>\n\n\n\n

Did it solve the problem and move the metric you were hoping it would?<\/p>\n\n\n\n

By building this validation into your roadmap, you create a space to show the value of the work done.<\/p>\n\n\n\n

<\/div><\/div>\n\n\n\n
\nNext: Using OKRs with a Lean Roadmap<\/a>\n<\/div>\n\n\n\n
<\/div><\/div>\n\n\n\n
\n
\n

In this Ditch your Timeline Roadmap<\/a> guide:<\/strong><\/h4>\n<\/div><\/div>\n\n\n\n
  1. What is a Product Roadmap<\/a><\/strong>