The Ultimate Guide to Roadmaps
CHAPTER 1
Why We Wrote This Ultimate Guide on Roadmaps
If you work within a company, tech or not, it’s likely that you’ve come across a roadmap before.
The first time you saw one, as many do, maybe you assumed that it was a project plan, or you didn’t know what it was and waited for an explanation.
Do all businesses have roadmaps, and if so why? Are all roadmaps uniform? And if there are differences, what are they? What are the differences between roadmaps and project plans, and how do they relate?
This guide will cover the A-Z of product roadmaps. Many topics including but not limited to:
What is a roadmap and the various types?
How to create a roadmap?
What are the key ingredients for an impactful roadmap?
How to effectively communicate roadmaps?
What tools are available for managing roadmaps?
… and more
From our latest report surveying 300 product managers, we have noticed two big challenges in the PM community regarding roadmaps. The 2nd greatest challenge for product managers is communicating roadmap decisions and aligning the product roadmap with company goals
Creating clear roadmaps that are clear and easy to understand is usually 2nd most rated feature when selecting a PM platform
CHAPTER 2
Product Roadmaps 101
What is a product roadmap?
Notice that the word “roadmap” is made up of the words “road” and “map”.
A map helps you understand where you are currently and the route to take to reach a destination, and a road takes you there.
This is the same with product roadmaps; they are a representation of where a company’s products are currently, outlining where they want the product to go, and the planned initiatives to reach set goals.
A product roadmap is a tool that outlines the strategic objectives of a business and how they plan to evolve their product to reach these goals.
What are the benefits of product roadmaps?
There are many benefits that product roadmaps provide to teams and companies as a whole.
Align your team
Roadmaps are created with inputs from multiple stakeholders, both internal and external.
The output of these inputs is a well crafted roadmap.
Once the product roadmap has been created every member of your team will be aligned on the mission, goals, and key deliverables for the year.
This is because they shared feedback that was necessary to put the roadmap together and also took part in prioritization discussions.
Position the product
A product roadmap clarifies how your company plans to evolve the product in the short-term or long-term future.
Product positioning is all about clarifying how your product competes in the market and differentiates itself from competitors.
Whether it’s a new strategic direction that you are taking the product or features to enhance the product and make it stand out, or both, this will be reflected in your roadmap.
Learn more about positioning and having a Unique Selling Proposition (USP) in the airfocus glossary.
Obtain stakeholder buy-in
Stakeholder buy-in means getting support from stakeholders on a planned initiative.
Having a discussion with a customer who is thinking about churning because they feel that your product is not meeting their needs?
Jump on a call with them to present the roadmap and the items that they requested to give them some confidence that your product is evolving with their feedback.
Roadmaps can also be used to gain buy-in from internal stakeholders as well.
Use your product roadmap as a tool to give managers an understanding of how the product will improve and the roadmap items that will assist various department managers with reaching their respective goals.
This is one way to get their support.
Setting the vision for the future
While your website may be filled with a feature list of what your product can do today, the product roadmap gives a glimpse into what the product capabilities will be in the future.
Plan resources
Product managers need to ensure that they scope their strategic initiatives with their team so that they do not overpromise.
Once roadmap initiatives are defined then the roadmap can assist with this.
If another initiative is suggested during the quarter the discussion won’t be centered around immediate implementation, but rather how to modify resources if the team decides to move forward with implementation.
Having a roadmap can help steer these discussions
Internal communication
Roadmaps are great tools for internal communication because, when using tools like airfocus, they can easily be shared with stakeholders.
Rather than jumping on a call with each member of your customer success team to walk them through the roadmap, simply share the link to the roadmap with the entire team.
If you decide to share your roadmap externally, customers can access it and understand the direction of the product and company.
With airfocus you can seamlessly share custom roadmap views and export roadmaps via secure URLs and exports.
Why do people dislike roadmaps?
With their many benefits, why would some dislike roadmaps?
Well, for a couple of reasons.
Roadmaps can set incorrect expectations
Roadmaps are never set in stone and product managers need to continuously communicate the changing nature of roadmaps to their stakeholders.
Though a new feature, for example, is listed in the roadmap today, for many reasons it may be removed or swapped out in the near future.
While this is common, and the decision for product managers to make, one issue with this is that stakeholders who have seen this new expected feature on the roadmap may have started communicating its arrival and making business plans as a result.
Always ensure that customers purchase your product for what it can do today and not what they expect it to do in the future.
Roadmaps get interpreted as delivery plans
One issue with roadmaps, especially those that are laid out in a timeline format, is that they are often interpreted as delivery plans.
The problem with timeline formats is that they imply a start and end date to the delivery of an item, when the reality is that this should be open to change.
Promising a delivery date, particularly before any discovery has been done and with a set of unknowns that may derail that end date, will inevitably result in disappointment and lost trust from the viewer.
Again, it’s vital when sharing roadmaps with stakeholders to set the right expectations and clarify what the purpose of the roadmap is.
Product roadmaps are not delivery plans.
Updating roadmaps is time consuming
This is more so for those who are responsible for crafting, publishing, and regularly communicating the roadmap.
Crafting a roadmap takes time. From gathering inputs from multiple stakeholders, weighing the various initiatives, understanding value vs. effort for each initiative, and then making the roadmap and sharing it.
And once complete, the constant work required to keep it up to date and communicate these changes while level setting expectations with stakeholders can get tiring.
Who said that being a good product manager was easy?
However, constantly updating your roadmap(s) is a lot easier when you have the right product tool.
Who is responsible for the product roadmap?
Though team members can and should have input on roadmap items, creating, publishing, sharing, and modifying the product roadmap all fall under the responsibilities of the product team.
Product managers frequently interact with customers to understand their problems, and then work with their team to define, build, and support the solutions to solve these problems. These solutions are then prioritized on the product roadmap.
As for which specific product manager manages the roadmap, this depends on the number of products, seniority, and size of the company.
It may be the case that each product manager that manages a product is responsible for crafting the roadmap for their specific product, or some for the features which then gets approved by a senior level product manager.
Either way, the head of the product team will ensure that the roadmaps are completed on time, consolidated, and relate to company goals.
We put together a guide on all product management roles and their varying responsibilities. Check it out.
How exactly do product teams decide what makes it into a roadmap or not?
While it may differ from team to team, the process looks something like this:
Gather requests from all of their stakeholders (this is done throughout the year)
Discovery calls with customers and other stakeholders to understand the reasoning behind requests
Scope requests to understand the business value, customer and user value, and associated effort (design, development, launch tactics, and more)
Prioritize these requests for the roadmap based on the ones that:
Align with the company goals
Bring the most value to customers, users, and the business
Fit with the resource constraints for the quarter/year
Confirm the prioritized initiatives with their team prior to publishing and communicating the roadmap to the entire company
How to understand roadmaps if you are not part of the product team
Members of the product team know exactly what roadmaps are and the purpose they serve. However, if you’re not a member of the product team these are the main things that you should understand about roadmaps.
Roadmap presentations
In many companies, on a quarterly and annual basis, there are company-wide meetings where progress to date, goals, and the roadmap is shared and discussed. Along with dedicated meetings throughout the year to specifically discuss roadmap updates.
And these aren’t limited to the roadmaps for the software products, but can include the business roadmap, marketing roadmap, etc.
When you’re invited to these meetings, attend and pay attention. You’ll get the information that’s pertinent to your work.
Key information to understand from roadmaps
You will notice different pieces of information on roadmaps, and this may change depending on the type that you’re viewing.
Irrespective of the roadmap, the items listed on the roadmap will display the strategic initiatives that the respective team is working on. Assuming your team is using a dedicated tool, clicking on the item may give you a more detailed description of the initiative along with further supporting information.
Based on the roadmap name, the team presenting, and/or names attached or tagged to the initiatives, you'll know which team created, manages, and is responsible for seeing the initiative to completion.
If it’s a timeline roadmap, the associated time periods (quarterly for example) outlines when these initiatives will be worked on and potentially released.
One thing you may also notice on roadmaps are colors, and sometimes labels as well, associated with some of the initiatives. This is used to communicate themes (initiatives that relate to one another) or goals (initiatives that accomplish particular goals);
Roadmap guidelines
When team’s share their roadmaps there are guidelines that are sometimes associated with it.
For example how to go about sharing feedback, who to share the roadmap with, how to present the roadmap, etc.
It’s beneficial to have these guidelines documented somewhere on the roadmap, whether directly listed within it or as a precursor to view it.
Check out the guidelines for Microsoft 365’s roadmap for example.
Product teams, make sure these guidelines are clear and that they are understood. Especially regarding what to communicate, how, to whom, and when.
The same applies for external roadmaps as well, but more about this soon.
Four other things to keep in mind
Here are some other key things to keep in mind about roadmaps:
The closer the time period the more accurate the roadmap will be. If you’re in Q1 for example then expect the roadmap for Q1 to be 90% accurate, with decreasing accuracy for future quarters
Roadmaps are not set in stone. Though items are currently listed on the roadmap, for many reasons they may be removed or swapped for more important initiatives
Adding to the above, roadmaps are updated regularly. If your team uses a tool like airfocus and you have access to the roadmap link then these changes will be automatic
Last piece of advice before you move onto the next section: if there is ever something on the roadmap that you are unclear about, or you have any questions about a particular initiative, then simply ask the product manager (or the main roadmap owner) to explain it to you.
3 steps to create an effective roadmap with airfocus
1. Use airfocus Insights to gather feedback from stakeholders
Stakeholder feedback is vital information because it gives you an indication of where you are excelling and areas of improvement. This is for both internal and external stakeholders.
Collecting stakeholder feedback in a central repository which you can later refer to help inform your roadmap is an ongoing process. This is where airfocus Insights comes in, to make the process easier.
With airfocus Insights you can:
Keep all product feedback organized
Connect insights to product discovery and strategy
Keep your team and customers up to date and close the feedback loop
With more than 7,000 global customers, Lemonway, a payment solution with the mission to help marketplaces make payment flows organized and seamless, relies on airfocus to accommodate the needs of its large and growing global user base.
Hear directly from their product team how they use airfocus to accomplish this.
2. Use Priority Poker to prioritize opportunities with your team
Prioritization is one of the tricky parts of product management. How do you take multiple requests from various channels and stakeholders (internal and external) and then determine which ones to action?
One way to do this is by leveraging the knowledge and experience of your team.
This is why we created Priority Poker for airfocus.
This feature provides a unique way to asynchronously and collaboratively prioritize features, enhancements, projects, and initiatives with your team(s). And to add, it’s a fun activity.
Read about how Flowe uses this feature to support and prioritize their product decisions here.
3. Place the prioritized initiatives on the roadmap with the right template
Prioritized initiatives should go on a roadmap that help highlight what the team is focusing on now, and what they hope to tackle next and later.
For this, a Now/Next/Later roadmap is great. However, what really matters is how the team hopes to communicate these objectives:
Will they be outcome-led?
Will they be objective-led?
Will they be experiment-led?
Will they mix and match solid features with outcome-led initiatives?
Once you’ve prioritized the initiatives with your team and are clear on the goal of the roadmap, the audience, and key collaborators, then choose the right template and start adding your initiatives.
While feature based roadmaps are popular, and timeline roadmaps can be used with other roadmaps, depending on your goals these may not be the right ones for your team.
airfocus has multiple out-of-the box product roadmap templates that you can take advantage of, check them out. They’re also fully adjustable so that you can modify it to your teams’ specific needs.
CHAPTER 3
Types of Roadmaps
There are multiple types and styles of roadmaps.
Some of them will be crafted by a product team, while others are crafted by other teams.
Let’s go through them in detail.
Outcome based roadmap
Outcome based roadmaps, as the name implies, focus on the outcomes of the user, product, or company. The key thing to understand here is that they focus on needs (outcomes and goals) as opposed to features.
This is where OKRs come in handy. Objectives and Key Results, also known as OKRs, is a goal-setting framework used in businesses to align performance with overall goals in a measurable way.
KPIs, Key Performance Indicators, are used to help you understand the progress against your OKRs.
An outcome based roadmap begins with the product vision and works its way down to the specific items that will be delivered to see this vision through.
It follows the following order: product vision > objective > measurable output of the initiative
This is one of the key roadmap templates that we offer, among many, at airfocus. Accomplish your goals with your team by getting started with this roadmap here.
A simple version of this is to list the vision at the top followed by themes, then goals which are aligned with objectives, and outcomes aligned with needs/achievements with a timeline view.
This roadmap is helpful because it clearly communicates to stakeholders how delivered items tie directly to the product and company vision, and the goals to be reached.
Our product roadmap templates come with powerful views. Use a Table, Chart, Board, or Timeline view. airfocus is a modular tool that enables you to customize roadmaps according to your team’s needs.
Business roadmap
A business roadmap outlines the long term strategic plans of a business.
A business roadmap is not a business plan.
Unlike lengthy business plans that detail the activities required to accomplish business goals, business roadmaps focus on big picture objectives and high-level strategies to achieve these.
Planning for the future, prioritizing objectives, clarifying the steps to fulfill the vision, these are just some of the benefits of a business roadmap. They also keep stakeholders aligned on specific goals and provide a track record for success.
While product managers generally focus on product roadmaps, entrepreneurs, business managers, and business managers craft business roadmaps.
Use airfocus to prioritize your business initiatives for a more effective roadmap with a smart prioritization framework.
For help on this front we also wrote a detailed guide on how to set up a business roadmap.
Experiment based roadmap
This roadmap outlines the experiments that the product team will work on to find new product opportunities.
The focus here is on questions and being open to the experimentation process of how you might achieve something, and if it’s feasible
It will list the entire workflow of the experiment. This can include a detailed description, the hypothesis, important links for reference, and more.
Internal stakeholders will be aware of the plans, kept up to date on execution, and know the results once available.
This roadmap outlines to internal stakeholders the many experiments that the product team will carry out throughout the period, and it also forces a product manager to think about the detailed steps to take, and ensure that they are working on the right initiatives.
Timeline roadmap
One of the key responsibilities of product managers is to communicate alignment around what is being done and why, what the focus is currently and what will be coming next (direction, what why, not when). Team members need this information to plan their initiatives around product goals and enhancements.
A timeline roadmap is a delivery plan. Along with listing the strategic priorities for the product, the timelines indicate the perceived start and end date of different initiatives, focusing on a release cadence rather than direction focus
This roadmap serves as the central source for team members to understand what is in progress and when items are expected. Timeline roadmaps will often display the work in quarters and months.
Timeline views are very popular because of expectations others have, and are used to communicate those expectations (regardless of whether the information is correct or not). It also has historical context from waterfall systems where cross-dependencies were listed on a timeline view.
Get started with a timeline roadmap today with our product timeline roadmap.
Use this to communicate and align your organisation on what your product will be able accomplish and when it will be ready.
Timeline views should generally be avoided in order to prevent missed expectations and letting people down.
If a timeline view is forced on the product manager, it is always suggested they supplement it with a proper roadmap that communicates goals so that the full story is presented (the what, why, and when).
By the way, if your team follows Kanban then consider a Kanban board rather than a timeline roadmap.
Check out What is a Kanban Roadmap? to learn more about this topic.
Agile roadmap
Agile development is a way to approach software development based on the values and principles expressed in the Agile Manifesto and the 12 Principles behind it.
With Agile, teams manage short iterations. As such, Agile roadmaps offer small chunks of work as opposed to initiatives that involve an all too big defined project, as things are meant to be open to change in Agile.
They also link the product strategy to the epics and features that will be released with dates. They are great tools for communicating cross-functional work.
The best piece of advice we can give when managing an Agile based roadmap is frequency of communication with your team. Changes are bound to happen so inform your team when they do.
What differentiates an Agile roadmap is the approach taken to define the initiatives and the approach to adaptation. Meaning, are you willing to adapt and communicate plans as they change?
Agile is the direct opposite to Waterfall software development. While Waterfall is a rigid sequential approach, Agile is not. So don’t be so rigid with your Agile roadmap!
Want to learn more about how to put Agile into practice? Check out Agile: Best Practices and Methodologies. This eBook offers an in-depth look into what Agile is, how it specifically benefits product managers, some popular Agile frameworks and best practices.
Short and long term roadmaps
While long term roadmaps outline the long term strategic plans of a product, short term roadmaps outline how a product will evolve in the short term (within the next 6 months).
It summarizes the current goals and how these goals will be met.
While long term roadmaps are more about setting the vision, short term roadmaps focus on what will be delivered soon.
For this reason they contain items that the product team is highly confident will be released.
These roadmaps must be reviewed often and updated when plans change. Multiple cross-functional team members rely on this information to work on and finalize their own plans.
Short term roadmaps will contain dates, individual features and/or a list of themes, epics, and milestones. While a product manager can choose how much information to share, the more detailed it is the better.
Visual roadmap
A visual roadmap is simply a roadmap, any roadmap.
Can you create a roadmap in Microsoft Word? Yes, you can. If it contains the key information and is structured as a roadmap then it is a roadmap.
However, would you present a plain looking word document to stakeholders? We don’t advise this.
When sharing important information with stakeholders it helps to remove any barriers to effective communication.
Presenting a visually appealing roadmap with the key information that is organized in one view will make your roadmap presentations more powerful and meaningful.
Check out airfocus, it comes with ready to use templates to make visually appealing roadmaps in minutes.
OKR roadmap
Objectives and Key Results (OKRs) is a goal-setting framework used by businesses to align individual performance with overall goals in a measurable way.
An OKR roadmap is a roadmap that contains initiatives that link back to OKRs.
It does not have to be limited to the OKR for one product or department, but can also list the OKRs of multiple products or departments.
When gathered in one view it acts as a central source for teammates to understand and track the OKRs for various products, team members, or departments.
Product launch roadmap
A product launch roadmap focuses on the strategy behind launching a product, including things like how a team will strategically announce initiatives, in what channels, to what partners, and what they hope to achieve from this.
Think past the work of the development team, but which key activities does the product marketing team need to do, the marketing team, the sales team, etc. need to complete to prepare for general availability?
Product managers are not the only ones who have access to this roadmap. Members of other departments need access to this roadmap to update their tasks and stay informed.
Use airfocus to prioritize your product, marketing, and sales related tasks for your next product launch via our product launch roadmap template.
Technology roadmap / IT roadmap
Also known as the IT Roadmap, the technology roadmap outlines a business's strategy for their software.
Along with communicating to your internal team how the technology will change, it also assists the internal team with making the right decisions and tradeoffs related to their technology infrastructure.
They’re also useful for supporting market-facing product & strategic objectives of the business, especially as your IT team works closely with business departments to support their efficiency and maximize business value
This roadmap is not for everyone’s view, it’s mainly shared with users, not customers. Users are those who are engaged with your product on a regular basis while customers are those that pay for it (they are not always the same stakeholder).
There are various kinds of technology roadmaps including architecture roadmap, DevOps roadmap, infrastructure roadmap, and more.
Technology roadmaps align stakeholders on a specific course of action to either maintain and improve existing technology or adopt new ones.
As Agile increases in popularity so does the importance of technology roadmaps. This is due to the increasing need for technology teams to be Agile as they manage their internal IT landscape as a product, not solely as an internal service for example.
In fact, Gartner predicts that “by 2023, approximately 40% of large enterprises will manage internal business capabilities as products to drive continuous innovation and competitive advantage.”
Feature based roadmap
A feature based roadmap lists the features that will be released for a product.
It focuses on features that are planned to be delivered to improve a product, as opposed to driving innovation like an outcome based or experiment based roadmap.
On this roadmap you may see the items organized by theme, color coded to show the similarity among them, brief details on the feature, and perhaps a visual representation of progress (shaded bar to show how much work has been done).
Feature based roadmaps will also differ based on whether the audience is internal or external, with internal having more details.
A long list of different types of roadmaps were covered in this section. Are product managers responsible for each one throughout their career? No.
Product managers focus on the ones that are the most relevant to their product, stakeholders, and company.
How to choose the right roadmap template?
With the many of roadmap types and templates that are available, how do you go about choosing the one that is right for you and your team?
There are two key things that you should keep in mind to choose the right roadmap template.
1. Who is your audience and who are the roadmap collaborators
Is this roadmap for internal use, external use, the management team, or the cross-functional teams whom you work with?
Also, will it be managed by one product manager, the product team, or other internal stakeholders will have input and update the roadmap regularly?
This will help determine what type of information will be shared on the roadmap, the quantity, and ties into the next point.
2. What is the goal of the roadmap?
When determining the goal of the roadmap consider the following: to outline the following:
What are you doing?
Why are you doing it?
For whom are you doing it for?
How you express these items, be they outcomes, experiments, or even features, is up to you. The level of detail shared will also vary based on the audience.
You may choose to show objectives, you may choose to go all the way down to the key results. You may even choose to also show all epics/ideas linked to the different initiatives, it depends on who is seeing it and what level of info they may need
If the purpose of the roadmap is to show when items will be released then consider a product timeline template.
If the purpose is to plan product launches with cross-functional teams then consider a product launch roadmap template.
If the goal is to prioritize the various initiatives and projects for your startup then a startup roadmap template is the way to go.
Check out our full list of roadmap templates. They’re fully adjustable and built on proven product management and roadmapping methods.
Before we move forward there are two additional types of roadmaps that we should discuss, internal and external roadmaps.
CHAPTER 4
Internal vs. External Roadmaps
What is the difference between internal vs. external roadmaps? It depends on the audience.
Depending on the audience there are certain details that may or may not be shared.
Let’s dive deeper into this.
Internal roadmaps
Internal roadmaps are for your internal team, those inside your company. They are used for both market facing products as well as internal roadmaps for IT product management.
This roadmap contains more sensitive data (hence why it’s internal), and may include certain experimental initiatives the team is not ready to talk about.
It may even contain initiatives like trying to raise money and building features or focus on initiatives that may assist with this.
In addition, it may include detailed information like opportunities and stories so that everyone in the team is aware of what is happening, why, and be more transparent.
There are specific types of roadmaps that are meant only for internal use.
They include the following:
Cybersecurity roadmap
This roadmap outlines a business’s plan to develop a stronger state of security for its systems, networks, and solutions from digital attacks.
Cybersecurity relates to a business’s internal processes and vulnerabilities as well as the strategy and outcomes that users have when needing cybersecurity.
API roadmap
An Application Programming Interface (API) enables software applications to talk to one another.
Businesses create APIs for their products so that others can utilize them to help expand their reach and platform. Remember that time you logged into a website with your Facebook account? You were using Facebook’s API.
Businesses also create APIs as products for customers to take advantage of. These customers are often developers who use these APIs to build products on top of.
An API roadmap outlines the improvements that a business will make to their API for the benefit of their customers and users.
Read more about this topic in our detailed glossary.
UX/UI roadmap
This roadmap outlines the product design team’s plans for future work and problems to solve that have been uncovered from customer discovery.
Why would this be kept internal?
For one, customers aren’t as concerned about this. Designing something does not guarantee that a new capability will be released for their benefit.
Secondly, this is private information that you do not want your competitors to be aware of.
Don’t make your competitors aware of the problems that your team is working on solving. This may be a competitive advantage for your product and company.
Content roadmap
A content roadmap, also known as a content marketing roadmap, outlines the strategy for a content marketing team within a specific time period.
This roadmap does not simply list all of the articles, blogs, and guides that the team will publish, it in fact focuses on the key projects of the team, ownership, and deadlines.
Businesses use content marketing to position their product, acquire more customers, and more market share. It only makes sense that these sensitive plans remain private so as not to alert competitors of your plans.
External product roadmaps
External product roadmaps are roadmaps that are shared with those outside of your company.
In many cases these are mainly designed for customers to outline expected product improvements. Customers are often curious to know what is coming next and if you are working on their specific requests.
One of the key benefits of having an external roadmap is that it saves your team conversation time.
What this means is that rather than having multiple meetings with various customers to walk them through the product roadmap, create a public roadmap and share it with them via a link for example. This gives them easy access to the roadmap and they can see updates as they are made.
Another benefit of external roadmaps is that they are great assets for sales teams when speaking to prospective customers. Along with speaking to and demoing the current value of your product, they can also speak to confirmed planned product enhancements on the roadmap.
This can help seal deals as prospects see that your company is actively innovating on your product line to provide a better experience for customers..
Though there are some benefits of external roadmaps there are cons as well.
One perceived fear regarding pubic roadmaps is that once available your competitors may get their hands on it. If you are working on innovative solutions then you just let the cat out of the bag. One way to prevent this is by having your roadmap housed in a support portal via password protection that only registered customers can access.
Simply because your roadmap is public doesn't mean that competitors can steal from you. Keep in mind that you and your team will have your own discovery, objectives, and vision that you want to meet.
Anyone can steal stuff from you at any time, even post launch. And being first doesn’t mean that you’re doing it right.
Another con is the constant need to manage expectations.
Once the roadmap is defined and shared, no matter how many times you communicate that the roadmap is not a project plan, customers will still interpret it as such.
If a feature is listed in Q2, then they expect it to be released in Q2, happy if released early and trust eroded if released late. This is why roadmaps should not be built on quarters, but rather outcomes.
How do you set the correct expectations when sharing your external roadmap?
1. Use broad timelines
Roadmap items should be placed in broad timelines, do not add specific dates.
Now, Next and Later are the most common, not quarters. Using quarters will still put you in a position to deliver by a certain time.
2. Add a disclaimer
This is especially important for public roadmaps (also known as external roadmaps).
Public roadmaps are shared publicly with those outside of your company, whether via a url that they can access, posted on your website, or a file that is shared with them.
Having a public roadmap is beneficial because it provides your customers with easy access to the details on what your team has released and the plans for improving your product(s) in the near future.
However, a public roadmap without a discussion or a disclaimer can be problematic because it can set incorrect expectations around how initiatives are decided, release dates, priority, and more.
This is where a disclaimer comes in.
This disclaimer should clarify the purpose of the roadmap, how it should be used, where customers can ask questions or provide further feedback, and explicitly mention that the items listed are subject to change.
Unity Technologies also has a disclaimer at the bottom of their Platform Roadmap, mentioned on the page before customers begin viewing the roadmaps for their various products.
Slack also has an easy-to-read encompassing disclaimer on their Public Platform Roadmap as well.
Get the most out of airfocus’ modularity and flexibility with our ready-made roadmap templates. Create and share roadmaps with unlimited viewers today.
CHAPTER 5
How To Create a Product Roadmap
Before creating a product roadmap you need to be clear on what the business goals are for the year.
Product management is a business strategy role, this means that everything that a product team works on, whether it’s building a new product from inception, a new feature, or a minor enhancement, must relate to business goals.
Business strategy is when management defines the steps that the business will take to accomplish particular objectives.
Product strategy is how the product(s) will evolve to assist the business in accomplishing these objectives.
How does a product manager define which initiatives to work on, problems to solve, and features to build?
Again, everything should tie back to the business goals. Before thinking about what to work on, determine the “why” and how it may, or may not, drive business objectives.
If the goal is retention, then focus on initiatives that support retention. If the main focus is increasing sales, then focus on the initiatives that support this. If the goal is a successful expansion into another market for growth, then focus on the initiatives that support this.
Product roadmaps are created with input from multiple stakeholders, internal and external.
A stakeholder is anyone who has direct or indirect influence on a product.
Internal stakeholders are the individuals inside of a business. For example members of the senior management team, designers, and developers. For custom internal tools, internal stakeholders can also be the users of the product.
External stakeholders are those who can influence the product however they do not work within the business. These include customers, industry analysts, trade unions, and development agencies.
Multiple stakeholders provide feedback throughout the product lifecycle on areas of improvement. This can be via enhancement requests or feature requests.
Product managers should have one central location to store this feedback. Keeping this feedback with details on who requested it, why, priority, and more.
Based on the main goals for the year and resources available, product managers then prioritize which initiatives to work on ensuring that they relate to the key business goals and the amount of resources available.
As the roadmap is crafted internal stakeholders should receive opportunities to share their thoughts. This is important because product managers do not work in silos.
The design and development team should have their input, sales also needs a chance to weigh in based on the discussions they’re having with prospects, and customer success will share their thoughts from feedback that they have received from customers.
These teams are free to share their thoughts. However with limited resources and varying opinions there must be one person to make the final decision on what goes in the roadmap, and what is taken out.
This person is not the CEO, it is the product manager.
6 steps to creating a product roadmap
Store stakeholder input throughout the year in the product backlog with detailed notes
Clarify the business goals and determine the product goals for the year
Gather a list of items from the product backlog that tie to the business goals
Prioritize product backlog items with key stakeholders (understanding value and effort)
Place these items on a roadmap template and share with your team
Revisit the roadmap throughout the year to ensure that it is updated and modifications are shared
CHAPTER 6
Prioritization and Roadmapping
Before prioritizing the initiatives that will make it onto the roadmap, you need a list of items to prioritize.
There are multiple prioritization techniques for prioritizing ideas, initiatives, and requests.
One of the prioritization techniques that can be used for prioritizing features and enhancements is the value versus effort framework.
Our team wrote a quick 5-minute guide to learn when and why to use this framework to prioritize initiatives and focus on items that will have the largest impact based on their goals and effort.
Value here refers to customer and business value.
Customer value describes the value that fulfilling the request will bring to each of your customers. This includes addressing their mentioned pain points, improving user efficiency, or assisting them with solving new problems, and more.
Business value determines how much value an opportunity will yield for your company.
Consider items such as whether the opportunity will generate new revenue, assist with reducing customer churn, assist with acquiring more users and more.
Effort generally boils down into one of the following 4:
Financial costs
Implementation hours
Length of time
Resources required
For each request you will have to estimate the value of the request against the reported effort. Estimates can be received from your team once they have an understanding of the general scope.
Your implementation team, those who will work on the idea, can give you a general estimate of what’s required to implement the desired scope. The more detail that you provide the more accurate the estimates will be.
Once you have estimated the value of the idea then you can compare it against the associated effort.
One way to prioritize requests is by using the value versus effort matrix. This is where you plot items on a 2x2 matrix based on their estimated value and effort.
The items will fall into one of 4 categories
1. High value, low effort
These initiatives provide a lot of value for your customers and your business and do not require a lot of effort. For example, a new feature that many of your customers are willing to pay for that will not take too long, require a large team, many resources, or have high financial costs to implement.
High value, low effort initiatives will definitely make it onto your roadmap because they bring a lot of value to your customers and your business and do not require much effort.
The amount of these items that you work on within a specific time frame depends on your company’s goals, available resources, and capabilities.
2. High value, high effort
These initiatives provide a lot of value for your customers and your business, however they also require a lot of effort.
For example, a new feature that many of your customers are willing to pay for, but it will require a large team, many resources, cost a lot, and take many years to implement.
When working on these items there are 2 key things that you need to do
1. Create a project plan
Since these initiatives will take a long time to implement and require many resources, as a product manager you will be required to play the role of a project manager.
You are going to be responsible for managing your team as you work on fulfilling the defined scope and also report the progress of this work to your team.
When an initiative is expected to generate a lot of value and will require many of your company’s resources, stakeholders (especially management and customers who are aware of the upcoming feature) will ask for updates.
Managers will want to know when it will be released so that they can plan their work accordingly. They will also want to know how the resources that have been allocated are being used; are things going according to plan or not.
2. Continue to keep a pulse on the market, competitors, and your customers
Initiatives that are high effort will take a considerable amount of time to implement. The term “considerable” here may differ from company to company.
Prior to working on a high value, high effort request you should perform enough research and have forecasted data to ascertain that this is an initiative that you definitely want to pursue.
Enough customers have asked for it, there is revenue potential, you can tie the request back to the strategic objectives of your business, this is something that your sales team can sell, and more.
As you work on this initiative it is important to keep your pulse on the market, your competitors, and customer sentiments (check in with customers on a frequent basis).
As this request can take a long time to implement, there is no guarantee that upon release the feature will still be valued in your market, competitor products have not been released, and your customers still desire it.
Do not forget these two key points
3. Low value, low effort
These are initiatives that provide a small amount of value for your customers and your business and only require a small amount of effort to implement.
These initiatives should be addressed; however they may not take as much of a priority as the first two we mentioned.
Businesses have limited resources and there is only so much that a product team can work on at once. The benefit of prioritizing initiatives in such a fashion is so that you and your team can decide what to focus on.
4. Low value, high effort
These initiatives only provide an incremental amount of value to your customers and your business if implemented however the effort associated with them is very high.
Do not add these items to your roadmap. Why? Because it doesn’t make business sense.
Why spend so many resources, time, and a large team on something that will not bring a considerable amount of return to your product and business?!
There are two key things to consider for items that belong in this category:
1. Discuss these requests with your team
Have full transparency with your team. Discuss the details of these initiatives with your internal stakeholders to ensure that the effort is as high as has been estimated.
Perhaps there are those who think that the effort should be lower, or know ways to reduce it.
2. Revisit these items
This is one of the benefits of having items documented in a tool like airfocus.
Though an initiative may be estimated as low value, high effort today, in the near or far future this may change.
So rather than just receiving a request from a customer, rejecting it, and then forgetting about it, maintain a list of rejected items and frequently revisit this list.
Keep in mind that all of the items on this quadrant can change.
Some other popular prioritization methods include:
For more on this topic check out our Ultimate Guide to Prioritization.
Here you can learn to structure a repeatable process to build outstanding products. Try the proven strategies in this guide to uncover insights and feedback, as well as learn to select the right prioritization framework and put it in place to make the best decisions.
Balancing customer feedback and the product roadmap
After the roadmap is published and shared with stakeholders, expect continuous product feedback from customers, users, and team members.
It is a product manager’s job to assess feedback and potential opportunities.
There are a couple of things that a product manager needs to keep in mind before deciding to take advantage of an opportunity or not.
Start by understanding the “why” of the initiative.
How important is this, how will it help accomplish company goals, and how does it rank compared to other initiatives?
If the decision is made to build something, where on the product roadmap will it fall and how many resources will it require?
Is it more important than other planned initiatives so that it can replace one, or a few, or can it be addressed later? Or, can additional resources be allocated to work on this soon?
Whether you decide to work on this initiative now and replace another item, or in a future quarter, for example, communicate with your team once the roadmap has been updated to reflect this.
Make sure that your internal stakeholders are aware, especially the product, sales, customer success, design, and development team. And consider adding this information to your external roadmap so that customers are aware.
Keep in mind that you must consult internal stakeholders when making these decisions. While you might think that something is important, validate your assumptions and research with your stakeholders before making any modifications to your roadmap.
Common prioritization struggles product teams face
Here are some of the common struggles that product teams face related to prioritizing roadmap initiatives.
Lack of time
One of the challenges that product managers will face at the end of the quarter, beginning of the quarter, and beginning of the year, are multiple inquiries from stakeholders on what is planned for the roadmap.
Product managers juggle many responsibilities. As you work to complete these responsibilities, ensure that you have a process in place for collecting feedback, assessing requests, speaking with key stakeholders, and prioritizing feedback with your team.
Ensure that you have enough time throughout the year to prioritize roadmap initiatives because delays in sharing and updating the roadmap will lead to anxiety among team members and business issues.
This can also lead to frustrated customers.
It’s near impossible for cross-functional team members to plan and prepare their tasks related to product success when they don’t know what the product priorities are.
Prioritizing initiatives
There are multiple prioritization methods that product teams rely on. We spoke in detail about this topic in our Ultimate Guide to Prioritization.
When a product manager joins a team they will use the existing prioritization method(s) of their team.
If you are the first product manager on a team then you can determine which prioritization method to follow. How do you go about this?
Well, perform some research, speak to other product managers, and experiment with various ones until you find one that works for you and your team. Not all companies use the same prioritization methods.
This advice goes for established product teams as well. Feel free to experiment with other frameworks until you find one that works for you.
Despite which prioritization method you follow there are two key things to keep in mind:
1. Include your stakeholders as part of the process
Determining value, effort, and having the right inputs to prioritize, will come from your team. Maintain a very close relationship with your team members as you work together to make the right decisions to benefit your customers and company.
This is one of the reasons that we created our Priority Poker for airfocus.
Guarantee alignment with your team as you benefit from their expertise while prioritizing features and initiatives in an effective and time efficient manner.
2. Be transparent about your prioritization method
Whether you use buy-a-feature, value vs. impact matrix, KANO, etc., make it clear to your stakeholders how you are prioritizing the initiatives you work on.
When items are prioritized and stakeholders have been included in the process, even if they don’t agree on the final decision, made by the product manager, they will appreciate being included and understand how the decision was made.
Estimating work can come in two phases:
Estimating the impact of a potential project or feature, against the objectives the team is wanting to reach
Estimating the work, which is generally led by the development team.
Do not set your team up for failure. Be confident that your team can deliver value against the goals you've set for yourself and you fully understand the problems you are solving.
Otherwise, you risk wasting time creating tech debt for yourself, and/or building features nobody ever really wanted or asked for.
How do you get ahead of this?
For one, start the estimation process early. Product managers should be organized and disciplined.
Manage your time and initiatives well so that you can complete work according to defined milestones.
Detailed estimates for work to perform can only be provided by your implementation team when they are given detailed specifications; epics, user stories, acceptance criteria, designs for reference, etc.
Once you have these details then you can draft a product launch plan.
However, sometimes product managers may not have the detailed specifications but require a general understanding of the level of effort to bring something to market.
In this situation, once you have an understanding of the initiatives you have in mind, sit with your implementation team, share the information that you do have, and get high level estimates from them.
These high level estimates can be given via scoring, T-Shirt sizing, or the pebble, rock, boulder method.
Of course these are high level non-exact estimates, but the point here is to receive high level estimates to understand exactly how much you can get done with your resources.
This will help you ensure that you are not adding too many items on your roadmap.
Competitor roadmaps
If you want to be competitive with a successful product then you must keep an eye on the activities of your competitors.
One easy way to accomplish this is by viewing their roadmaps.
This will give you insight on their strategy to improve their product(s) and what their key goals may be. Especially if they use a feature based roadmap, you will know the features that they are planning on releasing.
We are not advising that you copy their list of features.
No matter how compelling they may look, while those features may benefit their customers, they may not be the right solutions to solve your customer problems.
So if you see some compelling initiatives, make sure that you test and validate these ideas with your customer base first before implementing it for your product(s).
Keep an eye on competitor roadmaps. It’s easy access to understand how they are positioning their product in the market to remain competitive.
CHAPTER 7
Communication, Stakeholders, and Roadmapping
A product roadmap presentation is an important time for product managers to share the roadmap with their team.
The purpose of a roadmap presentation is not just to share the roadmap, there are many other benefits and objectives that it accomplishes.
Roadmap presentations should be handled and given often. The more the better.
The problem with simply giving one at the beginning of the year and never again is that it sets the expectation that everything on it will be "delivered as planned".
There are however two types of presentations to keep stakeholders up to date:
Roadmap presentations
Sprint reviews and kick-offs
These presentations provide stakeholders with the information on both outcomes and direction as well as current progress on work.
Some of the other benefits of these presentations are that they provide opportunities to:
Align your team on a common mission
Show your team how you will accomplish company goals via the product
Equip your team with the knowledge that they need to perform their work (customer success is now further equipped to speak to customers)
Motivate your team
Evangelize your product
Tips for an effective roadmap presentation
Keep the following in mind when presenting a long term roadmap:
Tailor the roadmap to your audience
Know the audience that you are speaking to. This is important to help you tailor your communication as you speak to these stakeholders.
Stakeholders don’t simply want to know how a product will evolve. They want to understand how the planned initiatives tie directly to their work and will assist them in reaching their goals.
Ensure that your content is tailored to your audience and speak to how the planned initiatives tie directly to their key needs and asks.
Tell the story
Storytelling is one of the most powerful skills that a product manager can have.
Rather than simply sharing the prioritized initiatives on the product roadmap, narrate a compelling story to your audience.
How did the quarter begin? What is currently happening in the industry? And what are the planned initiatives to improve the product? Speak on these points with a compelling story.
As you speak about improving the product orally paint the picture of where the product will be in the future.
It’s one thing to say that you will spend the quarter rebuilding the product with new technology to address bugs.
It’s even more powerful to paint the picture of how many bugs were caused due to old existing technology, feedback from customers, time spent by the development team, why retention is so important for the business, and how much happier customers will be and how much more competitive the product will be when rebuilt.
The latter approach is not only more entertaining to listen to but will motivate your team and garner their support.
Tie initiatives to business goals
When presenting your roadmap ensure that you tie planned initiatives to business goals.
Speak on these before you are asked.
There are many initiatives that product teams can address. Product managers prioritize what to work on based on feedback, value, effort, resources available, urgency, and business goals.
When presenting the roadmap also speak to how the initiatives tie into the goals of your company’s various departments.
If your customer success team is concerned about growing accounts and supporting retention, which initiatives on the roadmap will assist them with this?
Specify these initiatives and make eye contact with these team members as you speak on these items.
Here are some further communication tips to keep in mind:
Intonate your voice so that your participants don’t get bored with a monotone voice
Scan the room with your eyes and regularly make eye contact with participants
Utilize silence to give your audience a chance to register shared information
Roadmap presentations are one of the most important presentations that a product manager will give throughout the year. So if you have a product roadmap presentation coming up, keep these tips in mind and remember: Proper Preparation Prevents Poor Performance.
After the roadmap presentation
After the roadmap presentation product managers will work with their team to implement the roadmap initiatives and work with cross functional teams for a smooth and successful launch as they approach release.
Throughout the year both internal and external stakeholders will be curious to know the progress of roadmap initiatives.
Are all of the items on the roadmap on track? Have any been removed? Are there any delays? Did released initiatives reach their goals? If not, how far off are you?
Frequent communication and updates with your team is required throughout the year.
What is the best way to communicate with your team?
For internal stakeholders there may be distinct meetings with different departments for updates. For example, one with the sales team, another with customer success, another with marketing, etc.
The benefit of having frequent meetings with the various departments for roadmap updates is so that you can tailor your presentation to their specific needs and give them the opportunity to share their input and speak to any problems that they are facing that you should be aware of.
Don’t forget regular updates for the entire company as well. This is essential.
So, what is the best way to communicate with your team? Frequent meetings when needed.
In these meetings reiterate strategic priorities of the business, reiterate the initiatives on the roadmap, changes made, details on what has been released and progress, and what’s coming next.
CHAPTER 8
Key Ingredients of Successful Product Roadmaps
Want a roadmap that aligns your team members, inspires them, clarifies expectations, and can be used to help your company reach its goals?
If your answer is yes then pay close attention to the advice in this chapter on how to craft a successful product roadmap.
Do not stick to feature based roadmaps
Don’t get us wrong, feature based roadmaps are beneficial depending on the need. There is a time and a place to communicate features, and that is when you fully understand the problem that you are solving.
Unfortunately, however, many treat feature based roadmaps as to-do lists; all of the items that need to be delivered by a certain date.
And it’s only natural that they are used and interpreted as a project plan.
With each item delivered, stakeholders mentally cross it off of their list and await the next one.
Feature based roadmaps are feature-focused, not outcome focused. They often jump to the solution without fully understanding the customer's needs or outcomes
Product teams need to be objective oriented; don’t simply build features for the sake of output, but rather to align with the goals of your business and help customers achieve their ultimate goal.
How does one get away from sticking to feature based roadmaps? Start by beginning with the end in mind and then work backwards.
What specific objectives do you want to accomplish at the end of the year or quarter, and how will the product evolve as a result?
Also, focus on themes rather than simply features.
New features are always nice but customers want an overall experience that will make their lives easier.
Focus on the bigger picture. It’s not about the number of features you have but rather the quality of your features and how they benefit customers.
Keep the roadmap up to date
Product teams are successful when their cross-functional teams are successful.
A great product manager acts as a quarterback for their team, giving them the tools, information, and support that they need to be successful.
A successful product is a team activity.
While the product team, with the assistance of design and development, may build the product, the marketing team shares it with the world and the sales team sells it. And of course other teams play a part as well.
Stakeholders both internal and external rely on the roadmap so that they can know what’s coming, manage resources, and plan their work so that they can be successful.
So along with the formal roadmap presentations that you have quarterly and yearly, when changes are made to the roadmap update it at the earliest (internal and external). And if these changes are critical (initiatives swapped, dropped, added, or delayed) make sure your team is aware.
This is where having a product tool like airfocus is useful. Save yourself the hassle of constantly updating and repeatedly sharing new files with manually created roadmaps.
Have an executive friendly roadmap
Cater your content to your audience.
The customer facing roadmap should not mimic the roadmap for your internal team, and the roadmap for the executive team should not mimic the customer facing roadmap.
So when putting your roadmap together ensure that you have one that is executive friendly. They too want to know what the key product initiatives are.
Business executives are busy people. They have employees to manage, initiatives to manage, a company to run, and goals to reach among their other responsibilities.
They’re not concerned about the minute details, they’re concerned about what the key initiatives are, when they will be delivered, critical dependencies and risks, and when key milestones will be met.
These are the key pieces of information that should be presented on an executive friendly roadmap.
And when communicating with them it helps to spell out how the initiatives on the product roadmap will tie into each department's goals.
How do you ensure that the roadmap is aligned to the targets of other departments?
Start by understanding the business goals, gather inputs from team members, and involve key stakeholders in roadmap prioritization discussions.
Use a timeline roadmap
A timeline roadmap lists the initiatives in a timeline view.
Product managers need to give their team the information they need to be successful. Having a timeline roadmap lets your team know what items will be expected.
However, always set expectations by making it clear to stakeholders that the timeline roadmap should not be interpreted as a project plan.
Focus on users and customers
A product roadmap can include internal initiatives (for example tackling tech debt).
However a product roadmap should focus mainly on users and customers.
Customers pay for your product and ultimately keep the bills paid. Users and customers use products to help accomplish their goals and are happy to support products whose mission they believe in.
As the roadmap is crafted put yourself in the shoes of your customers and ask:
Does the product roadmap outline key initiatives that users and customers have requested?
Does it have the information that they need to understand what the initiatives are?
Is it grouped into themes for easy consumption?
If it is an external roadmap, how will they access it? Via a shareable link, housed in your support wiki, or do they need to reach out to a customer success coach for access?
If it is not easily accessible to your users and customers, what will your team’s response be when customers request information on your roadmap? Have a response and process defined with your team.
Tailor the roadmap to customer feedback and insights
To ensure that your roadmap speaks to customer needs and wants ensure that you’re regularly gathering customer feedback to uncover insights on how you can improve your product.
Check out our guide on How to Use Customer Feedback for Business Growth to accomplish this.
Prospect requests
A product team is not beholden to stick 100% to every item listed on the product roadmap.
Other stakeholders may expect this, but this is why it’s important to regularly level set expectations with stakeholders.
Product managers should regularly hold conversations with their stakeholders (internal and external) to understand what pains them, how they are using the product(s), further opportunities to be discovered, and more.
It should not be the case that a month before the roadmap is due a product manager starts uncovering the key issues that are paining stakeholders.
Always gather feedback, store it in a central location, and use it to uncover future opportunities for product improvement.
Also be willing to engage in discussions when team members have a request that may impact roadmap deliverables.
This does not mean that you have to say “yes” to requests, in fact you should say “no” more than “yes”. However, be willing to have these discussions. If something can’t be worked on now then maybe it can be worked on in the future.
Product managers must ruthlessly prioritize and be strategic to make the right decisions.
Use the right tools
There’s a lot to be said about this, but let’s discuss in the next chapter how to make your job easier with the right roadmapping tool.
CHAPTER 9
Roadmapping Tools
Why do product teams need product roadmapping tools?
Roadmapping tools make it easier for product teams to craft and share their roadmaps in an effective way.
Can a product manager create a roadmap in a spreadsheet, Word document, PowerPoint, or Keynote?
They certainly can.
However with all of the responsibilities that product managers hold, the constant iteration of managing roadmaps in these tools is just too cumbersome.
Roadmapping tools provide a plethora of features that make the process easier.
For example:
Ready-made templates to get started
Drag and drop interfaces
Visually appealing displays that make looking at the roadmap a pleasant experience
Multiple sharing and viewing options
Guidance on how to get the most out of a roadmap
Another benefit that roadmapping tools provide is that they integrate with many popular tools.
Product design software vs. product roadmap software?
Design tools such Sketch, inDesign, Figma, and more can be used to create roadmaps.
However, when using these tools to create roadmaps a product manager will fall into the same issues as mentioned before. It’s too cumbersome.
The only difference is that when using design software the roadmap will be more visually appealing, this is if you have the design skills or task your design team with this.
It goes without saying that we definitely recommend using a roadmapping tool to create and manage your roadmaps.
Creating the roadmap is the first step, roadmapping tools just make the process of editing, sharing, presenting them, and more, a lot easier. Do you really want to task your design team with making incremental changes to the roadmap every month, and monumental changes every year and quarter. Or would you rather use a reliable tool like airfocus to accomplish this?
I’m sure that there are more important tasks that your design team can work on.
Popular roadmapping tools
Some of the known tools for roadmapping include:
airfocus
Trello
Aha!
Monday
Wrike
Jira
Portfoleon
Roadmapping with airfocus
airfocus is not just a roadmapping tool, it’s the only modular product management platform that adapts to your team’s needs.
With airfocus, roadmaps can be created in a manner of minutes with out-of-the-box ready-to-use templates. The drag-and-drop interface makes it easy to edit roadmaps and keep them up to date.
Take advantage of one of the many available roadmap templates, including all major prioritization frameworks, or create your own.
To support cross-functional collaboration among teams, airfocus makes it easy to roll up various roadmaps into one single source of truth, and seamlessly share and export roadmaps via secure URLs and exports.
One of the capabilities that makes airfocus stand out from others is it’s flexibility.
Along with the ability to centralize feedback from various sources and stakeholders, airfocus also enables you to configure this tool to your specific needs.
This modular platform gives you the ability to add the applications that you need (building blocks) as you manage your product(s) from vision to delivery.
To add, airfocus provides two-way integrations with your favorite software development tools. Track the status of synced items in your development tool of choice right from airfocus.
Some of the development tool integrations that are available include Jira, Trello, Asana, and GitHub. Some of the feedback tool integrations include Intercom and Google Chrome. Check out the full list here.
Why are these integrations beneficial? Well, besides planning and determining your initiatives, airfocus makes it easy to see these initiatives through to completion with existing tools that you already rely on.
airfocus is the tool for product teams to utilize to execute their product strategy to reach their goals. But don’t take our word for it, hear what customers have said.
CHAPTER 10
Parting Words of Wisdom
Before you go and revise your roadmap(s) we want to leave you with just a few more tips to keep in mind.
Focus on the goals
When crafting the product roadmap, ensure that the initiatives on the roadmap align with the goals of your business. And once the initiatives are released track the results so that you can ascertain whether they were successful or not.
Be flexible
The product roadmap is not etched in stone. Product managers should be flexible and ensure that their roadmaps are flexible as well.
Always be open to receive feedback from stakeholders on roadmap items and be willing to swap items if necessary. Also be willing to stop work midway through to focus on more important items when needed.
Say “no” when needed, but also don’t be afraid of saying “yes”
Products are solutions to problems that are shared by many. Features are built into products to solve problems that users and customers are facing.
Not every feature, idea, or initiative should be worked on. This is because not all ideas that come from stakeholders will move the needle for business goals, and even if they do, there may be others that are more important.
Along with this, resources are limited, product managers do not have infinite resources to work on everything.
Product managers should be open to receiving feedback from stakeholders and always be open to new ideas. However, when these ideas are received it is the job of the product manager to determine whether they should be worked on or not.
To do this, always ask what problem they are trying to solve and engage the stakeholder in further conversation.
It's a terrible idea to jump to assumptions about what is being described, when often the problem is communication.
Even then, you might find yourself saying “no” to a lot of things, and that's ok, as long as you take the time to understand the problem and communicate why it may not pan out.
Think from the customer’s perspective
Empathy is a key skill for product leaders as they must always put themselves into the shoes of their customers to ensure that they feel their pain and put them first.
The product roadmap should outline how the product will evolve to assist a business with reaching its goals, and how customers will reach their goals as well.
Differentiate the roadmap from the release plan
A product roadmap is not a release plan.
A roadmap contains goals, epics, major user stories, broad timelines, and more.
A release plan is a project plan that outlines the details related to release(s). It contains features to be developed, milestones to reach, specific dates, statuses of items, and milestones.
While the product roadmap can be tailored to internal or external stakeholders, the main audience of a release plan is the product team and any cross-functional contributors to reach general availability.
Do not confuse these two. They have different features, objectives, and audiences.
Keep your stakeholders up to date
Changes will be made to your roadmap, items may be late, and you may decide to drop certain initiatives. Update your team when these changes are made.
This will equip your cross-functional team members with the knowledge that they need to perform their work to the best of their ability.
It also helps to build trust with team members as well, especially as items are delivered.
What next?
You made it to the end of this detailed guide! You are now equipped with the knowledge you need to build effective roadmaps that outline the vision for your products and help your business and customers accomplish their goals.
Don't forget our advice, save yourself the hassle of managing a manual roadmap.
Despite what your workflow or process may be airfocus can adapt to your team’s needs.
Use airfocus to align your team with a clear direction. Craft roadmaps in minutes with the easy to use roadmap builder, take advantage of ready made templates, share custom roadmap views with specific audiences, and more.
From vision to delivery your way, get started with a 14-day free trial, or book a demo here.
Too busy?
Download now & read later.
Get the PDF
