Suppose that you’ve just joined a company or launched your minimum lovable product to market. You’re beginning to receive fantastic feedback and validation from your clients. Congratulations!

You are now being bombarded with feature requests your customers, partners and suppliers. They are all asking you when you can deliver their requested features, yet some of these features seem less priority than others— so, what do you do?

Perhaps its time to communicate through a product roadmap. Sounds simple enough, but the process is much more nuanced than you first think!

Provided below is a guide to creating your first product roadmap, which you’ll see is art mixed with science.

Why creating roadmaps is so challenging

Even the most experienced product managers can often find it difficult to consistently articulate a roadmap to their internal and external audiences. Reasons include:

1. Competitive and market landscape constantly changing — this results in changes in what you build in the short to medium term. Take, for example, COVID-19 and the immediate shift to remote-first tasks.
2. Clients or partners depend heavily on what you are building—e.g., they’ve requested a feature, and you’ve set some expectation that it will be due ‘soon’ but haven’t delivered it yet.
3. Feature ideas come from all over the place— for example, your sales team may push your product and engineering teams to change your priorities due to an impending sales opportunity that cannot be won without a specific feature released.
4. Your management team or board demand concrete timeframes — but you are unable to commit to any because your development team cannot provide appropriate estimates on deliverables due to complexity or scope.
5. Its purpose differs between internal and external audiences —internally, a roadmap is used to build consensus and gain alignment on priorities and goals. Externally, it is often perceived as a release plan containing dates for when certain features will be released.

Whatever the case may be, it can often be overwhelming for a new product manager to come up with a roadmap that appeases multiple stakeholders and priorities.

What isn’t a roadmap…

There are many opinions on what a roadmap should and shouldn’t be, but many would agree that a roadmap is not:

• A wish list of functionality requested by your partners or clients
• A list of features to close ‘urgent’ deals in the sales pipeline.
• A way to force commitment on timelines in a delivery plan
• An exercise conducted in sole isolation of the product team
• Something you throw together last minute, the day before a workshop

Perhaps Teresa Torres says this best:

We need to let go of the idea that we can enumerate a list of features that represents what we’ll do in the future. This idea is absurd. Rather than sharing feature lists with the rest of the company, we should be communicating how we will make decisions. — Teresa Torres

Instead, roadmaps should be considered very carefully in strategic alignment with your organisational objectives, business strategy, and overall product vision defined per product within your overall portfolio of one or many products.

What is a roadmap…

Here’s a handful of definitions from fellow product leaders and companies that specialise in enabling Product functions to create roadmaps from scratch:

• “A high-level, visual summary that maps out the vision and direction of the product offering over time, communicating what you are building and why — ProductPlan.”
• “A statement of intent — it communicates both the short and long term initiatives that the team will work on and tells you the how and the why behind the product organisation strategy — Roadmunk.”
• “A high-level strategic overview of a significant business initiative... used to manage the development of a new product or the execution of a company-wide project — Airtable.”
• “…it describes the path from where you are now, to realizing the vision you have spelt out in your product strategy.” — Roman Pilcher.
• “…they are guides that describe the steps you need to take to move from your current location to your desired destination” — Clement Kao.

You should see some recurring themes in the quotes above. These are the following:

1. A Strategic artefact or statement of intent.
2. A depiction of short vs long term goals.
3. A description of the desired set of steps to achieve both short and long-term goals.

But how does one actually go about creating a roadmap from scratch? Well, let’s consider asking some more basic questions first before we dive into actually writing up your first roadmap. After all, a roadmap without alignment in strategy or shared goals is simply a wish list that is not worth the paper it's written on.

Step 1 — Confirm business strategy and objectives.

The first step in creating a roadmap is the realisation that you don’t simply rush into creating a list of features. All roadmaps should stem from a sound product strategy, which stems from a cohesive business strategy set by your leadership team (CEO, GMs, division heads or similar).

One does not create a product strategy and roadmap without a strong baseline of what the overall business strategy — Me

Strategic plans of each division in your company should align with and be derived from your overall business strategy and strategic outcomes. See our nifty diagram below:

In the scenario where you haven’t been oriented with the overall business strategy from your direct manager or leadership team, it’s best to work with your Head of Product to find out as much as possible about why your product exists, what problem it is trying to solve.

Should your business strategy or objectives not been well documented by your Head of Product or leadership team, there is a fantastic opportunity to request some workshop time to drive the creation of these and to flex your leadership muscle.

For me, my favourite strategy framework is the Strategic Choice Cascade model, which you can apply at both the overall business level as well as the individual division or functional level. We can apply this to business strategy first, then product strategy after.

A comprehensive guide to the Strategic Choices Cascade model can be found in Roger Martin’s blog, the Harvard Business Review, or directly from his book “Playing to Win, How Strategy Really Works”, but there are 5 key questions to ask:

1. What is your winning aspiration? The purpose of your business, its motivating aspiration.
2. Where will you play? A playing field where you can achieve that aspiration.
3. How will you win? The way you will win on the chosen playing field.
4. What capabilities must be in place? The set and configuration of capabilities required to win in the chosen way.
5. What management systems are required? The systems and measures that enable the capabilities and support the choices.

Some other frameworks that you can work on together with your executive stakeholders include:

1. A SWOT to assess your competitive landscape relative to your own capability
2. Porter’s 5 Forces Analysis to analyse competition and suppliers and/ or Value Chain Analysis
3. Ishikawa (Fishbone) analysis to ask the “5 Whys” to find out the root problems you are trying to solve

Whatever framework you use, you should aim to understand your business’ strategic agenda and priorities, where your business has decided to play (and more importantly, where NOT to play) and sustainable competitive advantages. These will drive your product strategy, vision and ultimately, the roadmap in the next 12 to 24 months.

The outcomes of Step 1 are:

• A high-level understanding of how your executive perceives your product, how it’s positioned, how it compares relative to substitutes or alternatives, and areas that you need to focus on today vs the future.
• A high-level understanding of the goals/objectives (e.g., Company-level Objectives and Key Results / OKRs) that your product should adhere to
• An articulation of the overall business strategy and priorities, ideally using the Strategic Choices Framework. We will revisit this framework later for product strategy!

Step 2 — Articulate your Customer Value Proposition

The next step is to take your base level understanding of what the product is trying to achieve and to articulate your value proposition formally so that immediate internal stakeholders have the same alignment on the “What and Why”, before creating an overarching vision and direction for your product, let alone the roadmap.

You may be tempted to jump straight into developing your Vision Statement. Still, I actually recommend creating a light customer value proposition of what you currently have today, made in conjunction with your leadership team and Product stakeholders.

There are several reasons why we need a strong proposition statement:

• Sales and Product Marketing can understand the target audience and how we intend to solve their problems.
• Product and Customer Success teams become subject matter experts for the rest of the business on all this related to the Product.
• Engineering can easily understand the “Why” so that they can form an informed view of “How” to create a solution that meets all needs.
• Customers can understand whether you’ve understood their needs correctly.

Some templates you can leverage from when creating your proposition statement, are the Lean Business Model Canvas, the Value Proposition Canvas, or Elevator Pitch mad-libs that cover the points above.

Whatever you use, ensure that you articulate the following:

• The Problem or Task being solved
• Target Audience or User Persona
• What value delivered by the solution
• Your unique selling points or competitive advantages (why it is better than alternatives)

The outcomes of Step 2 are:

• A customer value proposition defined with a high-level of your feature set and product functionality, which you will need later on
• A base-level understanding of what the product is trying to achieve across your immediate internal stakeholders

Step 3 — Define your product vision and strategy.

Product Vision

Defining a Product Vision could very well be a completely separate article due to many nuances that should be taking into consideration when constructing it. I’ll write that one up eventually, but here are some articles that I would recommend in the interim from some fellow product and design leaders on Medium:

• How-To Guide for Crafting Your First Product Vision by Ant Murphy
• The Product Vision Board by Roman Pilcher
• What is Product Vision by Maarten Dalmijn
• Visions 2020 by Paavan Budd

In my view, the Product Vision could be defined as the following:

A compelling, visual and motivational narrative that describes:

…the overarching product objective and outcome,

…the reasons for solving the problem,

…the end-state customer value proposition,

Let’s break down each part:

• A compelling, visual and motivational narrative should resonate and inspire your teams to do anything they can to achieve their unwavering purpose.
• The overarching objective is required to describe the “positive change” the Product should bring about, and act as a “true north” for your team to aspire to achieve.
• The reasons for solving the problem is required to state the ultimate “why” for your teams to solve for, ideally in alignment with the positive change described above.
• Finally, the end-state customer value proposition is included, either implied through the visual narrative or explicitly through text.

Visions should be kept concise; people won’t be so scared at going back to the vision at all times when executing strategy. To keep it compelling, concise, and inspiring, treat your vision as a collaborative story writing exercise with your product team and key stakeholders.

Your Product Strategy

Once you have your Product Vision statement defined, start working on your Product Strategy. In Step 1, we looked into the Strategic Choice Cascade (i.e., what is our winning aspiration, where will we win? how will we win, and what do we need to do so?). This same cascade can be used, but specifically for a Product vertical, rather than the entire business.

That is:

• What is our winning aspiration? — this can be the Product Vision statement or the value proposition statement of your product in-scope.
• Where we will play ?— a list of product areas that are in focus, a list of product areas you won’t play in. For example, at Littlepay, our product is purely cloud-based payment processing software; we do not produce nor develop software applications inside payment terminals or hardware.
• How we win — a list of unique selling points for your Product for which you have a sustainable competitive advantage relative to competitors — features that are near impossible to replicate due to the capabilities and ‘secret sauce’ of your product and team.
• What capabilities are required? — a list of capabilities that only your product and implementation teams have to create the propositions that make you win. This may be personnel, team culture, an approach to work, the quality of customer service or dedication to quality, among others.
• What management systems are needed? — a list of management systems underlying each of the capabilities listed above. Think about a process (e.g., testing procedure, QA process) or actual tool or system (e.g., neural network fraud tool based on some proprietary algorithm nobody has).

To illustrate how the Strategic Choices Cascade can be used in a Product Strategy context, I’ve supplied a sample based on a rapid analysis of Stripe, a global payments gateway, for the ‘Payments’ product line.

The outputs of Step 3 are:

• A Product Vision Statement defined with key stakeholders.
• A Product Strategy documented (if not a workshop conducted) with your product team, key stakeholders and executive teams.

Step 4 — Create “strategic themes” to provide better focus on what you’re building and why

By this point, most of the strategic work is done — you could spend more time fine-tuning and analysing your strategy, but you do need to start executing and delivering value to customers at some point. At this step, your strategic choices start to merge with your Product Roadmap planning.

A set of ‘strategic themes’ is needed — these are objectives that roll-up to your overall business strategy. For example, say your business is Stripe, shown above. The strategic themes for your Payments product line could be related to:

• Worldwide acceptance network —e.g., developing acquiring bank connections around the world so that the business can serve every business on the planet.
• New customer acquisition — e.g., faster new user signup forms or products focussed on new businesses to Stripe
• Improve revenue on existing customers —e.g., product enhancements to reduce costs or transaction processing expenses, thereby improving profit margin on existing transactions
• Reduce customer churn—e.g., product fixes or experiments on the features that are seeing most customer drop-off or complaints
• Merchant user experience — e.g., improving the user experience on the Stripe dashboard to allow existing customers to make richer financial reports

It’s important to pick themes that are distinct and not overlapping with another, ideally using the MECE (mutually exclusive and collectively exhaustive) concept made famous by Barbara Minto and her Minto Method.

Once you have your strategic themes, you will ideally also gain a sense of how much of your roadmap (e.g., through % allocation of work effort) should drive which theme. Some thresholds can be set by themes to ensure that you are allocating resources to the right theme. This is a more advanced topic I explore in this post:

The outputs of Step 4 are:

• A set of strategic themes agreed with key stakeholders.
• (Advanced) An agreement across executives about the allocated budget or threshold % per theme. This is used in managing backlog velocity later on.

Step 5 — Formally map out value increments, not just features and functionality

You are now ready to start mapping out your value increments, both at the Epic Level and the Story level, rolling up to the Strategic Themes identified in Step 4, where:

• User stories — are the requirements told from an end-user perspective to capture the description of a product feature. The User Story should depict the benefits and value to the customer, rather than just the feature itself.
• Epics — are large stories that consist of potential smaller stories for implementation, with a common objective.
• Strategic Theme s— these are defined in Step 4. A single theme may be linked to multiple Epics, and the focus area of a theme is generally at an organisation-wide level.

If you have a software product with many variables and dynamics, you can use some light prioritisation frameworks I’ve written about in the past, such as:

• Story Mapping — a visual model to arrange user stories in a way that allows the team to see how functionality fits into the overall customer journey. The priority of stories are placed from top to bottom, typically based on value to users and business. Refer to Medium post by Alin Mateescu.
• Affinity Mapping or Grouping — a collaborative prioritization activity where your team brainstorms ideas and opportunities on sticky-notes. The team then works to place sticky notes into groups of similar themes, before choosing which ones work on or deliver first. See the Center for Care Innovations’ step-by-step guide here.
• Impact Mapping — a model to arrange all features and deliverables to the end goal, actor/user and the impact it has on each. Similar in format to story mapping with an emphasis on setting the ‘why’ (objective) and ‘who’ (user persona) before mapping impact and deliverables to them. Refer to Mozaic Works’ extensive guide here.

While you conduct the mapping techniques above, make sure you start also mapping your features to Epics, and these Epics to your strategic themes identified in Step 4. This will allow you to understand whether you have too many (or not enough) features that drive a specific strategic theme, which in general should roll-up to an overall business strategy.

Some other prioritisation frameworks you can consider working with your teams on are found in my extremely detailed prior post on prioritisation.

The outputs of Step 5 are:

• List of features or functionality that your product has, that solves specific customer problem points / helps your target audience with their jobs-to-be-done
• Stories ordered by priority, using one of the prioritisation methods agreed within your team.
• An association or mapping of each feature to their relevant strategic them identified in Step 4

Step 6 — Choose your roadmap layout and level of detail

Having launching your first minimum viable (or lovable) product, establishing your product strategy and vision, and mapping out the features of your overall customer value proposition, you are now ready to map out your product roadmap, based on the priorities and sequencing you identified during your mapping exercises in Step 5.

Recall that the elements we need in the roadmap are as follows:

1. A Strategic artefact or statement of intent
2. A depiction of short vs long term goals
3. A description of the desired set of steps to achieve both short and long-term goals

So to address each of these, you need to make two main decisions on your roadmap content:

Decision 1 — Time Periods

On one end of the ‘time period’ spectrum is a roadmap with no dates or timelines whatsoever; on the other end is the detailed monthly timeline view, mimicking almost something close to a release plan.

Whatever time periods you use, think about the following:

• Have you got good forecasting in place to estimate the amount of work you release to market every month?
• Have you got a good track record for delivering on time or early?
• Do you have constantly changing priorities or competitive pressures to change features mid-iteration or sprint?
• Do you constantly have resource constraints in delivering the work you have committed to?

If the answer to the above questions is “no” more than “yes”, then you will probably be better off using much more ‘vague’ timeframes, such as “Now vs Next vs Later”. Conversely, if you have a level of precision and efficiency to forecast in a monthly view, you could simply use a monthly timeline.

Decision 2 — Level of Detail

In each of your themes, you will be highlighting the features and value increments you are planning to deliver. You have to decide how much detail you want on your “Card” — which is a value increment or story identified in the previous step.

Depending on your industry and audience, you may want to keep your stories very high level, rather than a detailed account of what, why, and how per roadmap item. Take, for example, three levels of detail for a single feature, where (1) is high level, and (3) is extremely detailed, including problem and reasoning:

1. Feature: “Transaction filters.”
2. Feature: “Improved transaction filtering.”
   Why: unable to find customers quickly
3. Feature: “Wider range transaction filter options and reports.”
   Problem: unable to find customers quickly when phoned by customers
   Why: allowing merchants to refund erroneously charged customers.

The 3 Main Roadmap Types

Having investigated many product roadmap tools and having interviewed fellow product leaders, I generally see three types of roadmaps as the most popular:

1. The “No-Dates, Just Sequencing” Roadmap

This roadmap type usually contains two axes:

• Strategic Themes on the vertical Y-axis, as swimlanes to your roadmap
• The Version Number or Sequence on the horizontal X-axis

Each story should be written in an outcome focussed manner, to allow the viewer to not only understand “what” is planned to be delivered but also the reasoning (“why”) and some mention of the secret sauce or differentiation (“how”). See below an example No-Dates roadmap may look like this.

• Pros — Provides more time for your team to investigate solutions without specific time pressure. A clear indication of what value is being delivered per strategic theme and how it drives your overall business goals.
• Cons — Customers waiting for the specific release of a story have no indication of when to expect the feature to be launched. Changes to scope in versions 1.2 onwards will require this roadmap to be constantly updated. Forecasting value release in later phases may change dramatically in a fast-changing environment, making any timeframe from 1.3 onwards extremely inaccurate.

2. The “Time Horizon” Roadmap

A “Time Horizon” is my favourite roadmap layout. It typically breaks your roadmap into three distinct time horizons, arranged by theme and ordered by priority of each story:

• Now — what you deliver in the next few iterations or sprints (say, the next 2 to 3 months, or the next 3–4 sprints)
• Next — the value increments you can see in line to be brought into the “Now” time horizon.
• Later — the “target end-state” value increments that you strive to achieve with after all Now and Next items have been delivered. Usually aspirational and may not be delivered.

A sample time horizon based roadmap can be found here:

• Pros — Good balance of detail and time commitments without needing to listing specific release dates. Themes can be tagged to each feature with some visual legend. Shows order of priority per time horizon. Clearly shows the future direction of the product: the aspirational target in future.
• Cons — If you are working on many things at once (say, 20 features in the “Now” bucket) it may be harder to read in a single column. If none of your Future (Later) items are ever delivered, then the audience may think this entire column is useless.

3. The “Timeline” Roadmap“

NOTE: Major warning!

Note: I usually don’t recommend these kinds of roadmaps, as they are over prescriptive and are almost always out of date the moment you publish the roadmap to stakeholders or clients. Instead, I would recommend you use the ‘Time Horizon’ or at least the ‘ No-dates Sequencing’ roadmap.

If stakeholders really need more precision on dates of when specific features will be ready, you may have a bigger problem to solve around stakeholder alignment and focussing on specific strategic choices. Instead, you might want to ask yourself how to align and create a review cadence with your stakeholders to ensure you are solving the highest priority problems for today.

That said, I’ll still give you a snapshot of what these timeline roadmaps typically look like and other disadvantages to consider.

A “Timelines Roadmap” is the most precise in timeframes, usually planned across distinct time periods such as quarters if not by months. Dependencies from one feature to the next can also be shown almost in Gantt project planning style.

Some timeline options are included below:

• Monthly — spanning every month for the next 12 months
• Quarterly — spanning calendar quarters (Months 1,2,3 = 1 quarter)
• 2 Quarters 2 Halves — spanning two sequential quarters, then two halves of a year. Out of the three above, my preference is this option allowing you the flexibility to change the scope of future items that have less certainty on scope today. This might be a good way to negotiate with stakeholders before you introduce the Time Horizon style roadmap later!

A sample “2 Quarters 2 Halves” Timeline Roadmap is shown below, including some sample dependencies, milestones, and release timeframes, by strategic theme.

• Pros — Easily identify goals and milestones per time period and dependencies between stories. Level of precision, when delivered on time, provides more transparency on upcoming iterations and tends to relax stakeholders (but only in the short term; see cons below).
• Cons — So many! Creates a false sense of control for stakeholders who see specific features they wanted, represented on the roadmap. May begin spiralling your team down a rabbit hole of ‘feature factory’. Features that are being planned for far further in the future may never get worked on (due to changes in scope or priorities of today), making your stakeholders trust the roadmap less and less whenever variances occur.

Step 7 — Gather feedback, continually review

Now that you have established a roadmap worth sharing, you need to identify how best to share it with external and internal stakeholders, and a cadence for both updating the roadmap and communicating it.

Your external product roadmap may remove all dates and detail of the “why” and “how” so that the customer or partner only really knows about the value delivered. Your internal product roadmap may contain as much content as possible to ensure a shared common understanding of what, why, and when.

Whether or not everyone in your technical teams (product owners, designers, engineers and the like) actually read it isn’t the question here: you need to ensure you over-communicate and adjust your roadmap whenever you receive consistent feedback suggesting a change in scope or priorities. Overcommunicating your roadmap priorities is far better than not communicating at all.

To gather feedback from your stakeholders, both internal and external, you could do many things, such as:

• A dedicated email address for customers and partners to send enquiries or requests to
• A quick feedback widget that collates ideas and feedback directly from customers and partners
• An idea portal (e.g., Confluence space, JIRA Idea board, or a paid Product Roadmap tool) that customers and partners can vote on and evaluate a community of ideas

Whatever you choose, make sure you have frequent idea reviews and often communicate to the idea submitters about any ideas you have accepted into, or rejected from, your backlog and roadmap. For me, a quarterly update of the roadmap seems to work the best, but you’ll have to negotiate with your stakeholders to see what works best for you.

Bonus Step: Product Roadmap Tools

There are many tools that you can use across your product team that allow you to create and maintain your roadmap over time, such as:

• Productplan
• Productboard
• Aha!
• Prodpad
• Atlassian Jira Roadmaps
• Roadmunk
• Trello

I’ll write up another post one day comparing each of these tools and their merits, but for now, try to simply focus on aligning strategic objectives and product vision with a set of strategic themes of intent, before going into more detail on the Epics or Features that you’d like to describe for your stakeholders.

If you don’t have time to invest in looking at tools at this stage, don’t worry. Your first focus is to communicate priorities — even if it is simply a brief discussion — rather than setting up tools in detail.

Final Thoughts

Provided above is a detailed write-up of the 7 steps to creating your roadmap. The steps are:

• Step 1 — Confirm business strategy and objectives.
• Step 2 — Articulate your customer value proposition.
• Step 3 — Define your product vision and strategy.
• Step 4 — Create “strategic themes” to provide better focus on what you’re building and why
• Step 5 — Formally map out value increments, not just features and functionality
• Step 6 — Choose your roadmap layout and level of detail
• Step 7 — Gather feedback, and continually review

As you would have seen, creating a roadmap isn’t as simple as making a feature shopping list, nor should it be treated that way either. It requires a lot of upfront work with frequent maintenance and updates. As a result, you will have more confidence from your leadership team, your immediate technical teams, and your customers and partners alike.

I acknowledge that there’s a lot of detail not listed in this article, but do hope that the resources shown above will help you address any gaps I’ve made here.

That said, if you struggle at all with your roadmap or simply need advice, please reach out to me! You can simply respond to this Medium post, and I’ll get back to you ASAP. Good luck!