When it comes to creating product roadmaps, product managers are spoiled for choice. There are fantastic tools that do lots of heavy lifting when it comes to formatting. And there are also fundamentally different approaches to presenting roadmap-level data to audiences. This article will get into the specifics of why one might select a timeline vs. kanban roadmap. This choice represents a significant fork in the road for the roadmapping process. Product managers should understand the benefits and drawbacks of each to help them pick the right one.
List view or Kanban-style roadmaps are an extension of the Kanban board. This roadmap is a method for organizing tasks or other items into different categories. You’ve probably seen Kanban boards in products like Trello and Asana and Wrike. They’re quite popular in the Agile world.
Kanban itself is an outcrop of Toyota’s automobile manufacturing process. It strived for just-in-time manufacturing by eliminating as much waste as possible from the system. They did this by managing inventory levels based on actual need and demand.
Each part can pull a corresponding “Kanban” card when it’s been used. This way, they were only ordering replacements for used parts, minimizing excess inventory.
A Kanban-style roadmap provides multiple data points about each item at a single glance. The reader can tell what phase of product development it’s in (i.e., Current, Near Term, Future, Wishlist). But with color-coding, they can also see what theme or goal is associated with the item.
A timeline-based roadmap is a listing of what will be delivered when. It answers the question: “What are you working on and how long until it’s ready?” It also provides a snapshot of each initiative, where it’s slotted, how long it will take, and a rough delivery date.
Timeline vs. Kanban Roadmap Options
Both Kanban-style and timeline-based roadmaps are viable, appropriate options. The tricky part of deciding which one is the best fit for the job at hand. So let’s take a deeper dive into each.
Kanban-style roadmaps
Kanban is all about knowing exactly what state things are in. You can glance at a Kanban board to see whether something is done, in process, in the queue, or idling in the backlog.
Depending on its uses, you might also be able to see who is working on things or assigned to different items. Alternatively, some organizations allow people to pick and choose from the “to do” column when they’re ready for their next task.
When transposed into a roadmap setting, Kanban-style roadmaps provide a unique merger of what’s being worked on and scheduled with long-term strategic or aspirational items. When tasks sit in the “Wishlist” column, there isn’t a commitment associated with it. Therefore, no one can assert that since it’s “on the roadmap,” it will be built at a particular time.
This holistic view minimizes stakeholders asking “what about that feature” because they can see where it’s currently slotted. It’s comprehensive and inclusive of both scheduled and unscheduled items. A timeline roadmap indicates what is and isn’t a priority.
The main downside to a Kanban-style roadmap is how easy it is to keep changing things. Some organizations value a relatively set-in-stone roadmap for planning purposes.
The other shortcoming of this style is that it’s not great for mapping out a long-term strategy. Everything on the to-do list is clumped together. There’s not an easy way to know Item A is coming in six months while Item B won’t be ready for a year or so.
Timeline-based roadmaps
Timeline-based roadmaps are great for visualizing product schedules for the different tasks at hand. They’re a quick and easy way to digest what everyone’s working on and resource allocation.
However, a common pitfall for timeline-based roadmaps is focusing on deadlines rather than emphasizing strategic priorities. They don’t provide any context for why things are on the roadmap. Nor do they include any clues as to why they’ve been prioritized and how they’ve been slotted.
There’s a reason people hail the merits of excluding dates and timelines from roadmaps altogether. Timeline-based roadmaps open a Pandora’s box when presented to stakeholders.
They’ll spark lots of questions about scheduling and execution. They create an opening for plenty of less-than-helpful suggestions about how to reorganize things. But when there’s a widespread understanding of the goals and strategy, they provide an excellent overview of the product.
The devil is in the details of these types of roadmaps. The more information you provide, the more precise the expectations you’re setting with the audience. If there are specific features or dates on there, the team will now be expected to deliver exactly those items on those exact dates. If not, now, the project is being considered “behind schedule.”
This accountability is particularly precarious if a timeline-based roadmap is presented externally or used by the sales team to make promises to prospects and customers.
Any specificity provided in a timeline-based roadmap should come with a matching level of certainty. Otherwise, you’re setting the team up to fail.
Using the Right Roadmap Style
If you’re new to the roadmapping game, it’s easy to think they should pick a timeline vs. a list-view roadmap. At face value, it’s a logical approach. But one must step back and consider why they’re creating a roadmap, to begin with.
The intent of a roadmap isn’t to replace project plans and Gantt charts, which are all about resources, dates, and details. Their real purpose is creating alignment around the goals, objectives, and priorities of the organization. There are other approaches to roadmaps that better speak to the “why” rather than the “when.”
Which style roadmap you select shouldn’t be based on your personal preferences or what you’re most comfortable with. Instead, drive your roadmap choices by your objectives and the hurdles you must clear to achieve them.
First, consider your audience. What does your audience care about? What are their expectations from a roadmap?
You don’t have to keep using a particular format because that’s what they’ve historically always received. But if you’re going to change things up, there should be a good reason for it.
Next, it’s time to consider the goal of the roadmap and why you’re creating one in the first place. Consider the scope, the level of detail, and the timeframe it captures.
Finally, you should consider the maintenance aspect of the roadmap. How often are you planning to update it? How often will it be referred to by the audience?
Suggested Use Cases for Kanban-Style
Kanban-style roadmaps make the most sense when you’re trying to accomplish one of the following:
- Capturing and communicating initiatives the team is working on currently, as well as those a bit more aspirational or longer-term.
- You are communicating a snapshot of the product’s high-level project management view to crucial audiences—such as development and support teams.
- You’re showing relevant audiences where things are in the development process without having to dig into dates and deadlines.
Best organizational fits
Kanban-style is best for small and mid-sized companies—or any organization that adopts the Agile methodology and whose product teams move quickly.
They’re also great for organizations trying to avoid committing themselves to an inflexible, yearlong roadmap. They’re best suited for scenarios where quickly shuffling and re-prioritizing initiatives are common— in conjunction with a broader strategy of continuous market research, data analysis, and customer discovery.
Suggested Use Cases for Timeline-Based Roadmaps
Timeline-based roadmaps fit the bill for product teams trying to accomplish one of the following objectives:
- Visually communicating how long specific initiatives will take to complete.
- You are providing a big-picture view and context to stakeholders about when and what’s happening in product development.
- Offering a tactical focus with an emphasis on deadlines and timeframes.
Best organizational fits
Timeline-based roadmaps work for any size organization that needs a high-level view of its strategy. They are appropriate for communicating specifics on the estimated time and effort to complete initiatives.
They particularly fit for situations where organizations must manage expectations on chronology and deliverables—communication to executives, investors, board members, and strategic partners and customers.
Takeaways
Which roadmap format a product manager chooses sets off a chain reaction of consequences. Go the Kanban route, and people will hound them for dates. Opt for timelines, and promise implied delivery dates for every item.
But you should not use one single roadmap format for the lifespan of a product. Starting with a Kanban-style and then migrating to a timeline-based roadmap as a product matures could be the best play. Or maybe it’s beginning with timelines to get the MVP out the door, then switching to a Kanban-style once the backlog items and feature requests start piling up.
The right answer depends on the current needs of the organization and the goals of the roadmapper. Having both styles in your toolbox makes it easier to provide the best roadmap for the moment.
Want to make your roadmap? Start your 14 day trial with ProductPlan. Organize your initiatives in timeline or Kanban-style format – and interchange between the two.
