Last year I saw the term ‘Kanban roadmap’ emerge subtly in some product circles. At first I thought it was a bit of a faux pas, perhaps something that would die off naturally as some things do.
But as life will have it, the term seems to have grown in popularity lately.
A quick search on Google actually returned a worrying amount of articles that ‘defined’ what a Kanban roadmap was. At first I was actually kinda hoping it was an SEO click-bait juice and they would explain that the term was incorrect — but alas, I was wrong, again.
So let’s tackle this once and for all. If you are out there reading this, let’s establish one thing straight away:
There is no such thing as a Kanban roadmap.
So where did this term come from, anyway?
Let’s start with the basics.
What is Kanban, anyway?
Kanban is a methodology first invented by the Toyota company. It consists of a board (a “Kanban” board) that shows the progression of work through a set of workflows.
This board allows teams to understand a few things:
The current capacity of work by each team member/team
The progression of the work across teams
This allows everyone in the team to understand where things are at, how things are coming along, and improves overall communication and collaboration.
While it was originally used for hardware and with a waterfall-style approach, it is a system that easily adapts to an Agile environment, and is often used in SaaS product development due to its simplicity and efficacy.
What is a product roadmap?
A product roadmap is a dynamic document that helps teams align with each other.
It focuses on and communicates the following:
What you are doing
Why you are doing those things
Who you are doing things for
How these things tie back to your objectives
Now I’m not talking about a timeline.
I am referring to a document that is easy to understand, and helps the organization understand its overall direction and intention for growth and development.
In other words, we are not talking about a list of features or tasks, but a list of questions or outcomes.
What does this document look like?
You may be familiar with the terms ‘outcome-based roadmap’ or ‘Now/Next/Later roadmap,’ and they look a little like this:
This type of document focuses on three main columns that show initiatives, sometimes posed as outcome statements or questions (ie, How might we achieve x?)
The three core columns are :
Now (current, commited work)
Next (things going into discovery)
Later (things within potential scope)
There are sometimes two added columns, one of which you see above:
Done (to communicate solved problems and implemented features)
Problems to solve (to communicate things that are not within the current scope of direction, but carry potential at some point)
The difference between Kanban and the Now/Next/Later Roadmap
So I’m sure at this point you’re wondering — but are they not the same?
They both have columns, they both have cards on those columns, why can’t I just use the term ‘kanban roadmap?’
Both documents have lanes, but they do not move in the same direction.
Kanban boards move from left to right. There is a system or progression that has to be followed.
No item in a Kanban board can skip steps from the beginning to the end. That is, it starts on the first step, then moves through the rest of the steps as work progresses and moves forward. You wouldn’t move an item from “New” to “QA” to then “Done.” Items have to follow a very specific set of workflows, even if at some point within that progress you decide to discard an item (which could indeed happen.)
The important thing here is — you grab an item from your ‘New’ column and move it through your Kanban board step by step until it is either discarded or done.
A roadmap moves from right to left. However, there is no set “workflow” as a roadmap is at all times dynamic.
Where as on your Kanban workflow the next item you move through the system will always start at the ‘New’ column, in a roadmap, the next item you grab could be from the Next column or the Later column. It could even be from the ‘problems to solve’ column.
It is an unpredictable process, as it relies on context that sits outside of the board you are looking at (consider things like feedback, market research, competitor analysis, cost of delay analysis, etc.)
There is no “set progress” — and that is because the roadmap doesn’t outline a list of tasks to be done, but a set of intentions for your team to discover.
Each document has a different focus: Outcomes vs Output
The most important thing to remember about each document is its main focus. You are at the end of the day communicating different levels of information.
A roadmap focuses on outcomes. Again: what you are doing, why you are doing it, who you are doing it for — and how you will measure success of your decisions.
A Kanban board focuses on output. It is there primarily for you to see how your tasks are moving forward, understand capacity, and progress of each item. Those tasks may start as opportunities to look into, and then break down into specific experiments, solutions, and further details as you build the output of the final feature you are looking to build (this is where you can apply a dual-track agile approach.)
Do roadmaps and Kanban boards overlap?
Yes, of course they do.
Think of the roadmap as zooming out, or taking a step back from your Kanban board.
Each card on your roadmap groups together a set of items on your Kanban workflow and answers the question — why did we choose to work on these items?
With the Kanban board, you then assess those items on your discovery track, which as you move along then allows you to distill those items further into specific epics, stories, and tasks for your development track to tackle as those items are approved for work.
In other words — all roadmaps break down into Kanban boards, and all Kanban boards roll up to roadmaps, but they are not one single document. They outline different levels of work, intention of work, and progression of work.
Thanks for reading!
Andrea Saez
Read also
Experience the new way of doing product management
Experience the new way of doing product management