RSVP FOR FREE | How Carpe Data Supercharges Roadmap Planning to Deliver Outcomes | Oct 3 @ 9 AM PT


5 Product Roadmap Formats for Every Stakeholder and Occasion

One of the most important skills a great product manager should have is the ability to communicate the story behind their product roadmap. Even more important, they should be able to know when and how to shift the perspective of the story depending on which stakeholders they share it with. For example, customers want to know the progress of the features they request, while c-suite execs want to know how the features you’re building help achieve the business goals.  

Depending on how the roadmap is visualized, and what information is shared, you can tell your story in a variety of different ways that will have varying appeal to different stakeholders. So, how can you be sure to choose the right roadmap format for the right audience?

In this post, we’ll share five different product roadmap formats you can create on-demand in Dragonboat to update your various stakeholders. And don’t feel like you have to pick just one! You might find you like to add work in one format and visualize it for stakeholders in another. That’s the beauty of having a 3-D roadmap!

5 Product Roadmap Formats and When to Use Them

1. Kanban Board Product Roadmap

We recommend starting out by creating a kanban or Trello board-style roadmap for your day-to-day roadmapping activities. 

Ideal Audience 

While this is a great format for sharing your roadmap with anyone, you may find it best for personal use and to manage your roadmap. 


When you create this type of product roadmap format in Dragonboat, you can easily: 

  • Plan with drag and drop editing
  • Display data by various groupings (e.g. group by timeframe/quarter or goal), then add, drag and drop, and prioritize ideas or initiatives within each column
  • Roll up effort to see the estimated allocation for your selected grouping
  • Apply filters to only show relevant values

How to Set It Up 

You can create your kanban board in Dragonboat in 3 simple steps:

  1. Define your strategic drivers/portfolio dimensions – Consider the different product areas, goals, themes, timeframes, etc. that you should keep in mind as you plan your roadmap. These represent your strategic drivers or portfolio dimensions, as they’re called in Dragonboat. 
  2. Add epics and initiatives to plan for a longer horizon – While brainstorming, add your ideas/ epics and initiatives (this is the term we use for big ideas, programs, or in SAFe, EPICs). Group or align each initiative to its related goals and other strategic drivers. 
  3. Assess and prioritize at the idea and/or initiative level in various dimensions such as by objective, category, theme, focus, etc.

Now, you have a wonderful kanban board roadmap that easily presents your plan:

2. Slide Deck/Executive Summary Product Roadmap

Does it ever feel like 50% of your time is devoted to building PowerPoint presentations? It doesn’t have to be! In Dragonboat, you can automatically visualize your roadmap as a slide or executive summary.

Ideal Audience

A versatile format, you can use it in edit mode for your own planning purposes as a product manager or for presenting ever-green slide decks to any stakeholder.


  • Choose any information you want to share, it’s 100% customizable
  • No need to build and update slide decks manually
  • Save views that tailor your roadmap story for your audience so you can easily come back to them later

How to Set It Up

Choose the data you want to have in the columns and rows, select the portfolio level, and group within each cell to communicate information concisely and tweak the information for stakeholders with different needs. 

The summary format includes an edit mode for planning as well as a share mode which is what your stakeholders will see. Saved views can be shared via email, Slack, Confluence or direct links to read-only users.

Editing is as easy as simply dragging and dropping between areas. 

Let’s look at some more examples of product roadmaps in the slide deck summary format:

Product Roadmap Slide for Customer-Facing Teams

Show customers in the rows and quarters in the columns to indicate when you plan to build features requested by various customers.

This is a great product roadmap format to share with your sales and CSM team so they always have a real-time snapshot of the roadmap and can update customers as needed.

Product Roadmap Slide for an All-Hands Meeting 

Let’s say you’re a Head of Product and want to show what all of your teams are doing to help the company reach its goals. Use the slide deck roadmap format to show teams (in the rows) by goal (in the columns) and display all of the corresponding items at the initiative level. 

If you’re looking at it just with the product team, you can choose to display epics/features instead.  

Product Roadmap Slide for Executive Updates 

To keep everyone aligned and to provide visibility, a Quarter by Teams summary is helpful like the one below: 

3. Swimlane Product Roadmap

A swimlane roadmap is essentially your roadmap presented as a timeline. Similar to the rest of the formats in Dragonboat, you can group your roadmaps in any of the portfolio dimensions to tell the right stories for the right audiences.  

Ideal Audience

Executives will be pleased to see your roadmap in this compact timeline. You might also want to use it for your own planning purposes because it’s easy to move things around and see how different items line up without needing to have the exact dates in mind.


  • Visualize and manage dependencies
  • Easily plan things without needing to know the exact timeframe/dates 
  • Show a lot of detail in a compact timeline

How to Set It Up

Choose how portfolio dimensions are grouped into lanes, customize colors to tell the right story, and drag and drop between lanes to edit/adjust your timeline.

Let’s take a look at some common swimlane roadmap views that product managers put together in Dragonboat:

Initiatives Each Product Team is Working On To Achieve Goals

Initiatives and Epics an Individual Product Team Is Working On To Achieve Goals 

4. Gantt Chart Product Roadmap

Gantt charts are often used for showing activities displayed against time and are a part of every program manager’s toolbelt. This product roadmap format in Dragonboat has a story mode that makes tracking progress and roll-up easier, along with real-time updates.

Ideal Audience

This product roadmap format is ideal for sharing with program managers (PMOs) who can help with the planning, execution, and reporting side of things. It also makes it a breeze to manage dependencies, which is even more helpful for them.


  • Display multiple levels and groupings
  • Edit in a cell just like you would in a spreadsheet 
  • Enjoy real-time updates with Jira/ Agile tools for the mapped fields

Dragonboat automatically pulls stories and tasks from Agile tools (Jira, Clubhouse, Github):

5. Spreadsheet List-Style Product Roadmap

Creating your product roadmap as a list is a highly flexible option. If you’ve used spreadsheets to manage your product roadmap, you can think of this as the new and improved version! 

In Dragonboat, this is the ideal format for organizing your product with a combination of multiple perspectives:

  • By scope (aka hierarchy): Epics may be part of an initiative (bigger, multi-epic/ team endeavor), which may be part of a bet (if your company has multi-year items)
  • By dimensions (OKR, roadmap, timeframe/quarter)
  • By planning stage

Ideal audience

This product roadmap format is especially ideal for sharing with your product operations colleagues, as they’ll likely prefer to have a lot of data on one page. Since this roadmap format displays many fields, it could be used for going through all of your initiatives in a status meeting.


  • Flexible and customizable for your unique needs
  • Can be used for both planning and sharing with various audiences
  • Back up your decisions in ‘score view’ where you can add comments for each score field to provide context on scores

Let’s look at some examples of what you can make in list view:

Roadmap Status Report in List View

Prioritization View

Dragonboat has multiple product prioritization frameworks baked in to best suit your needs.

A great product manager is a masterful storyteller. It’s important to have the right information and tools to stay organized so you can present it in a clear and compelling way, without all the hassle.

What is your favorite product roadmap format? Let us know on Twitter!

how to make the switch from feature roadmapping cta

Effective Feature Prioritization with Product Portfolio Management

A product manager recently posted on a community group that she is looking to change her career as she feels exhausted from constant fire fighting in managing competing priorities and stakeholder demands. When I recommended Dragonboat, she was puzzled: “But we only have one product. Isn’t portfolio management only for large companies with many product lines?”

Not necessarily! According to Investopedia portfolio management boils down to three things:

  1. Determining strengths, weaknesses, opportunities, and threats in the current market
  2. Selecting investments and allocate appropriately to a set of parameters
  3. Rebalancing periodically

You can see that it is not so much about managing the size of your portfolio, but managing your choices. This is not too different from what a product manager does — you are constantly thinking about the product investment mix to maximize your desired outcomes.

This is exactly what responsive portfolio management is. Applying portfolio management principles, allows us to reframe how we think about product roadmaps. Every product, even if it is the only one in the company, is essentially a multi-dimensional portfolio of priorities and demands.

A Product Manager’s Portfolio

Like the finance industry, we often use SWOT analysis (strengths, weaknesses, opportunities, and threats) to chart our market and product plans. 

However, that is where the comparison ends. While financial advisors work with clear monetary values — such as profit, revenue, or market share — product managers have a wider set of variables and a broader definition of “the best outcome”.

That means we can derive multiple types of portfolios depending on how we view the roadmap. For some broad examples:

  • Objectives
    These can be long- or short-term objectives such as acquiring or retaining customers, reducing operational costs, or expanding into new markets.
  • Customer Segments
    New, existing, enterprise, or partners.
  • Investment Categories
    Such as deciding between product innovation and tech platform refactoring.
  • Stakeholder Needs
    Both internal and external such as customer feature requests, realigning the product for the market, or addressing tech upgrades and debts.

Why Would You Want a Multi-Dimensional View?

A multi-dimensional view lets you:

  1. Address multiple elements of “product success”; and
  2. Make the right allocation decisions faster (i.e. focus vs. support).

Imagine you have a new product. The sign-up numbers look good but, after a week, these users stop coming back. As a result, the team must shift their focus on how to improve retention. Once that is under control, you can shift back to user acquisition, efficiency improvements, and so on.

Many conventional prioritization frameworks are based on a fixed formula such as scores or ROI, and do not reflect the changing needs of the customer or market.  Over time, it may lead you into a “peanut butter” situation where the product simply fails from the company’s resources being spread too thin.

By looking at it from a portfolio perspective, product managers are empowered to understand the current state of the product and market to decide on a responsive prioritization method for identifying areas that truly need your limited resources.

Think of it as trying to fight a forest fire — you look at it from the ground and the top, analyze the situation, and then prioritize, allocate, and deploy. That is what it takes to be a forward-thinking product leader. 

Responsive PPM CTA

We Need A Portfolio Program Manager Not Just Scrum Masters

A dedicated scrum master is essential for new Agile teams. They are the glue that holds everyone together, ensuring that members adhere to best practices and agreed processes. Much like glue, it will take some time to set. Once everyone understands the makings of a good scrum – from planning to tracking – they are on their way to becoming a well-oiled, self-organizing team.

At this point, the scrum master will no longer require a full-time role because everything works for the most part. So now what? Now, is the time for an up-leveling because

Enabling an Agile engineering team is just the start of an Agile company.

Agile execution via scrum helps build quickly and iteratively. However, it does not automatically enable higher-level alignment of our strategies towards our goals (OKRs). Additionally, it does not enable cross-team cross roadmap collaboration to build synergies or iron out dependencies.

To unlock greater agility, companies need to also practice responsive portfolio program management. Responsive PPM dynamically connects objectives, initiatives, and resources with Agile execution. It also calls for people with the right skills to help move the organization forward.

The Responsive Version of Program and Portfolio Management

Traditional program management focuses on large, cross-functional, and complex programs with many projects. Moreover, the traditional portfolio management focuses on planning, budgeting, and tracking a suite of programs. Both are mostly practiced in large organizations with complex structures.

In small to mid-sized companies, your entire product roadmap is a portfolio.

Many fast-moving companies today may have only a few, if any, large programs. However, they usually have many smaller moving pieces carried out by one or more agile teams. As the agile teams are continuously iterating on product enhancements, there is a missing “glue” to connect them together. This is a recipe for chaos. Promised features go undelivered, support teams are left in the dark, and everyone is sending urgent feature requests filling up the roadmap pipeline.

Solving this takes portfolio management skills.

What Portfolio Program Managers Do

In a nutshell, portfolio program managers ensure the best-desired outcome for an organization over a relevant time period, within the constraints of resources. Scrum master leads scrum cadences while portfolio program managers lead quarterly (or month/ bi-monthly) portfolio roadmap cadence. Their duties can be summed into three key areas:

  1. Quarterly Strategic Planning for Portfolio Allocation
  2. Roadmap Delivery and Trade-Off
  3. Progress Communication

A portfolio program manager works with key stakeholders to create a clear and holistic process for defining priorities responsive to the time-frame. They also lead trade-off discussions between the product areas or teams using portfolio principles to allocate the right resources towards various objectives and initiatives.

Lastly, after deciding the product features and initiatives to undertake, they transition delivery to the agile teams knowing the key-elements of the plan are in place for the team to execute.

Then they track the progress and outcomes, and keep the stakeholders informed.

When changes inevitably happen – for example, when a new high priority feature request comes to the team – portfolio program managers lead roadmap trade-off discussions to minimize the impact on in-flight features while still accommodating new requests in a way that best achieves the company’s desired goals.

In Responsive PPM, We Believe All Factors Are Dynamic

This is precisely where a portfolio program manager comes in to connect the moving pieces in a holistic and dynamic way.

This transition from being a scrum master to a portfolio program manager represents both professional growth for the individual and also a strategically impactful role to every organization.

Responsive PPM

How the Struggle to Connect Strategy and Execution Led to the Start of Dragonboat

In May 2017, I joined a Fintech startup, Feedzai,  to build its first product organization and create the product management best practices that connect strategy and execution: customer needs, business goals (OKRs), and long-term product strategies responsively.

Challenges From Rapid Growth

When I joined Feedzai, it was in super growth mode, from ~100 people to 300+ in about a year.

As the customer base expanded, it created a much wider roadmap intake funnel influenced by current customers, prospects, internal teams, and market insights. As a result, the engineering team grew, which formed more scrum teams. Before long, most features started to require multiple scrum teams. Dependencies started to slow everyone down.

Planning and executing on the same 2 week cadence no longer works in growing companies.

– CTO, Feedzai

Teams were busy, while business units didn’t get what they want. There were scrum and sprint metrics but no big picture visibility. No one could answer these 3 basic questions without some effort of digging:

  • What features will we launch next month? Why?
  • What does it take to add this critical feature in the coming release? 
  • Which team and skills do we need to hire next? How do we decide?

We also had gaps and misunderstandings between various departments, e.g. Product, Marketing, Sales, and Support as there wasn’t an end-to-end view of bringing the product to the hands of customers.

The Basics

During my first 2 months, I built an end-to-end PDLC process (Product Development Life Cycle) from idea intake and alignment to strategic prioritization, agile development, and go-to-market. 

To support these processes, I reconfigured Jira, instituted quarterly and rolling roadmap planning and tracking cadences, and built 4 spreadsheets to manage ideas, product planning, resourcing scenarios, team assignment, and rolling planning (current period execution and next period discovery in parallel).

I made these changes quite quickly, as Feedzai was the 4th growth company I went through this type of transformation with. There were some slight tweaks partnering with product and engineering teams, of course.

The framework, Jira optimization, and a suite of spreadsheets enabled us to plan strategically, flow through to execution, and adjust our plan when new things come to our roadmap. We could now connect strategy and execution but with a lot of effort and meticulous record-keeping and syncing by product managers, engineering managers, and Project managers/ scrum masters. On average, each spent 2 or more days per week on updating spreadsheets, syncing data in different tools, and writing various status updates.

While this sounds challenging, it is not quite unique.

We Needed a Better Tool

A growing company needs to adjust focus frequently – both on the product front as well as the team and resource front. This requires overall visibility, and the ability to re-align initiatives and resources quickly to respond to changes.

However, planning is painful. It takes a lot of time to iterate through various roadmap options within the constraint of resources, timeline, and dependencies (see Build A Better Execution Roadmap). This gets exponentially more complex when the company gets bigger. If a feature requires 2–3 teams or skills, and there are 10+ teams, the permutation combination can get out of control very quickly. At most, we do 2–3 iterations of roadmap options and quit then. We simply run out of energy and time to find the best combination. And even if we’ve “locked down” the upcoming roadmap (next month or quarter), things change… and the pain will start all over again.

While many companies practice big picture planning (connect strategy and execution) to complement agile execution, the way we manage this process has not changed for 20 years.

Spreadsheet + meetings + presentation is still how most teams connect the dots between strategy and execution.

The Lightbulb Moment

In the preceding 3 years, I’ve been on several tool hunts, tried and used dozens of roadmap and project portfolio tools, including Aha!, Portfolio for Jira, Roadmunk, Product Plan, Airtable, Trello (on steroids), Smartsheet, Asana, Monday (back then it was called Dapulse) and even “old school” tools like Planview and Clarity (CA PPM). I also did many interviews with many Product, PMO, and engineering leaders. There was no modern tool to connect strategy and execution and enable cross-functional collaboration.

When 2 engineering leaders from 2 different companies reached out for suggestions on a “better spreadsheet” to manage their roadmaps and resources… I realized they didn’t need a better spreadsheet, they needed an intelligent system to connect strategy and execution and support iterative planning to respond to changes quickly.

I decided to build one – This is the start of Dragonboat – the smart, complete, and Responsive Product Portfolio platform to help companies build better products and teams.

Series A CTA

6 Elements of An Execution Roadmap

An execution roadmap is the plan that brings your company’s strategy to life.

Intentionally or not, every company follows an execution roadmap, where teams allocate time, i.e. resources, to execute against a list of initiatives in a certain order.

Building an execution roadmap typically starts with setting priorities. Many product prioritization frameworks and tools are built to allow easy ranking of feature priorities. Your team works  through this list of priorities and delivers features to the market. This works quite well when most work is done exclusively within an agile team.

As the company grows, it will have multiple product managers and multiple teams. Often one product manager needs other teams and other product managers to support her features.

When this happens, a friendly negotiation may settle the request. Sometimes though, the competing demands need a mediator, often the engineering manager of the team. The inevitable question usually is, which feature/ story has a higher priority. It seems that once we get our priority straight, the roadmap will fall into place effortlessly.

That’s what I thought too, earlier in my career… Back then, our engineering team supported both our “home” product managers and product managers from other business areas. Often there were back and forth debates on which projects are higher priority. Since they came from different groups, it was harder to gauge one group’s metric (priority) against the other group’s. Out of frustration, I wondered why the CEO or the head of product can’t just define priority for the entire company, from 1 to n. Then the team can just build them out in sequence and produce the best results for the company….

Or so I thought… but this approach fails everyone!

First off, no one person can/ should define the fine-grain level list of features for the entire company, let alone prioritizing all of them. This type of micromanagement, assuming everything is known ahead of time, is dangerous. Leaders should focus on defining strategic problems (setting strategic goals), not dictating the solutions and sequences.


Factors to Consider When You Build an Execution Roadmap

Even if we can define product priority, here are still several key factors to consider when you build your execution roadmap.

Impact indicates the level of benefits towards your strategic goals.

Effort (or Opportunity Cost)
High impact and high effort initiatives may not produce better market/ customer results than a few lower impact but much smaller effort initiatives combined. Since hiring and ramping up takes a long lead time, effort indicates opportunity cost that should be evaluated thoughtfully.

Resources (Non-fungible Skillset)
There are different skill sets within a team e.g. frontend, backend, DevOps, QA, UX… demand for each skillset fluctuates and differs from the actual distribution of skills. If a company adopts resource forecasting (often on the quarterly or semi-annual frequency), a temporary skillset balance between teams may be adopted to improve portfolio output, instead of having an un-utilized skillset for one team to take on less impactful projects while another team has to take fewer projects due to skillset constraints.

Skillset limitation also creates a new dimension to the opportunity cost.

Dependencies (or Readiness)
No one likes to be blocked… one of the most common blocking factors is when there is a dependency, either unplanned or known but poorly coordinated.

For example, there is “hurry up and wait” as you are ready, but your partner is not. Or your team can’t start because they are waiting for upper stream deliverables, e.g. user research and prototype validation.

Deadlines (or Quick Wins)
Some relatively lower priority features can be desired/ demanded by customers or required by legal… launching them on time needs some planning ahead in your execution roadmap.

Time in Market
Often it’s better to iteratively build, releasing and testing parts of a feature before the final release. Allowing time in market for feedback before building the next phase is the right way to build product… Team should use the gap to work on other features or address tech debt.


Building a good execution roadmap needs to consider all these factors. However, the process does not need to be a drawn out one that requires all the “facts and figures”. There is no perfect information on any of these factors. Create a draft, try it out, iterate as you get more information.

This site uses cookies. Some of these cookies are essential, while others help us to improve your experience by providing insights into how the site is being used. For more information, please check our Privacy Policy. You can disable or remove cookies in your browser settings at any time. By clicking "Accept" or continuing to use this site, you consent to our use of cookies across the site.