Roadmapping Frameworks: Break the Goals into Tasks

A product roadmap is a holistic visual document that outlines your product’s growth path. A stellar roadmap includes the release of new features, key dates, product updates, and the product vision – giving context to the product lifecycle. 

Product roadmaps are a good way for developers, designers, managers, and the whole team to prepare for the future. Also, if there’s a new product down the line, the tasks and timeframes around that will also be clear to everyone. You can create your own, or use tools like Roadmunk, Productboard, ProductPlan, and others to make product roadmaps with more ease.

Let’s take a look at what types of roadmapping frameworks exist so that you can choose the right one for your team.

If you’re working on a new product release, and you have it tied with a specific date-based event in the future, the best strategic move will be to use a timeline roadmap. This will outline every single task and step your team members need to take to achieve the final goal.

The timeline roadmap is a visual representation of a strictly time-constrained workflow. That said, this type of roadmap would suit a Scrum workflow within sprints. 

To make it comprehensible, include the upcoming tasks that need to be completed and attach key dates and other relevant information. Share the roadmap across the teams in your organization to ensure everyone is on the same page when it comes to the schedule.

Here’s an example of a how a timeline roadmap looks like: 

On the other hand, if your product or feature release is not explicitly connected to a specific date, you can exclude the dates from your roadmap. Instead, you could make it quarterly-based with an overview of the planned product lifecycle development. 

The swimlane roadmap is also a good choice if you want to emphasize what is planned to do, what’s in progress right now, and what has already been completed. 

The example of a swimlane roadmap will look like this:

As you can see, the Swimlane approach resembles a Kanban board, so if your team is already using Kanban or similar methodologies, Swimlane might be the best choice for you. 

Flexible roadmaps are another way of working on the roadmapping for your next product or feature release. This can be a release-based, an outcome-based roadmap, a roadmap based on customer requests, or any other type that suits your needs that aren’t strictly related to a specific timeframe.

Besides that, in our guide to flexible roadmaps, we also talk about the value that lean, feedback-oriented roadmaps can bring to your team – and your customers. 

You can use in-app surveys to evaluate customer satisfaction, include them in feature rating or request voting, and collect feedback to make better-informed decisions. Use the insights you gain for validating your feature ideas and further iterating your roadmap.

A product landscape gives a broader picture of the product’s context. If a roadmap answers the questions of “what” and “when” to build, a landscape answers the question “why”. 

It includes the product mission, go-to-market strategy, and the overall position of the product in the market, along with the desired vision of where the product is going. 

As Kevin Capel, Director of Product Management at Bullhorn, explains in his article Ditch your roadmap for a product landscape, “product landscape is a 'map' of where the product is going and what it could be, with a focus on the less tangible concept of product identity."

He also adds:

"Roadmaps are valuable when you need a window into development progress or you want to promote excitement about new offerings or components. But they can be less effective when you’re trying to craft a product vision and create momentum, you're deciding what not to do, or when you’re defining the problem space for your product."

– Kevin Capel, Director of Product Management at Bullhorn

In the scenarios where roadmaps are not so effective, you can use a product landscape to make strategic decisions, set long-term goals, identify the ways to achieve them, and, as Kevin Capel mentioned, define a problem space. 

A problem space is where your customer needs are. To be able to build a product that solves the right problems for your users, you need to first understand the problems they have.

To get the best results, you need to spend the majority of your time in the problem space. 

This is also what the first principle of Product Manifesto, created by a group of product professionals led by Mayank Yadav, who has built products at Facebook, eBay, and Uber, points out:

"Principle #1: Ask 'why' before 'what', use data and research to reveal the opportunity."