As a product manager, your roadmap is your biggest ally - it’s where art and science (and a whole lot of feedback) come together to direct where your team will be putting their efforts now, later, and in the future.
However, roadmaps are often thought of in silos, broken down in ways that actually make things more vs. less complicated for your team, and can create unnecessary churn that slows or can even prevent you from reaching your desired outcomes.
Often it’s not just about the thinking that went into them, but also the way in which roadmaps are presented.
Here is a breakdown of critical considerations when preparing a product roadmap presentation:
Roadmaps should take into account:
The main problem your product is trying to solve as a whole and how big of a problem this is
Who, specifically, is impacted by this problem, and how
Problem constraints (i.e. regulatory or legal guardrails in the given domain)
Your company’s North Star purpose (i.e. Google’s is: “To organize the world's information and make it universally accessible and useful”)
What success looks like for your business (i.e. what are your top-level OKRs, V2MOMs, KPIs, or just plain “most important metrics”?)
Product Vision (i.e. Apple iPod: “1000 songs in your pocket”)
Product Strategy (How you will accomplish that vision, i.e. Gibson Biddle on Netflix’s Product Strategy)
Product Principles (i.e. Slack’s are: “1. Don’t make me think; 2. Be a great host; 3. Prototype the path; 4. Don’t reinvent the wheel; 5. Make bigger, bolder bets”)
Feedback from stakeholders
Technological constraints and opportunities
Team topology and skills (i.e. who is on the team and what skills and expertise do they bring, what is the team capable of, and what is their bandwidth?)
Resources (i.e. Money)
How much time you have (i.e. months vs. years)
Unknowns and blind spots
The risk involved, and an understanding of your company’s risk tolerance
Key Takeaway: The roadmap should not be built by a single product manager working in a vacuum - it should be a collaborative process with the PM working as a stitcher to connect all of these inputs to the ultimate business objectives within your constraints in a coherent and easy-to-understand way. You shouldn’t be presenting your roadmap to your company if you’ve built it entirely on your own and it’s the first time you’re gathering any feedback on it.
Pull together all of the items to consider adding to your roadmap (diverging on scattering) before you preemptively start to filter and prioritize (converging or gathering) what actually goes into your roadmap. Think of it as the block of stone you start with before beginning to carve a sculpture. If you start with a small misshapen rock, it will influence your end result significantly.
There are many ways to approach ideation, i.e. running collaborative workshops and brainstorming sessions, using tools like Miro or Asana to capture ideas, and meeting 1:1 with key stakeholders to gather their feedback.
As a product manager, your role is to seek out valuable ideas and stitch these ideas together.
Ask Questions Like:
What friction points currently exist for our customers (or potential customers)?
What friction points currently exist within the team (i.e. engineering frustrations)?
What friction points currently exist within the business (i.e. conversion rate is not very high)?
What would give us a competitive advantage?
What are the main areas we want to learn in?
What opportunities exist? (In the market? Amid competitors? That customers or prospective customers have identified?)
Vote as a team to prioritize the best ones so they rise to the top. (Sprint outlines a great, objective voting method involving folded paper and stickers).
Key Takeaway: Gather ideas. Put them on the table. Vote on the best ones.
Rather than start with an empty spreadsheet and start outlining important dates your CEO has given you, I’m a big fan of Janna Bastow’s Now | Next | Later Roadmap and how Andrea Saez describes it in practical terms here: How to Build a Product Roadmap That Everyone Understands.
Break this down further into themes based on problems you need to solve vs. “product features”. I.e. “Improve conversion” vs. “Change ‘I want this’ checkout button shape”. I.e. Shreyas Doshi’s 7 themes of problems to solve.
Don’t forget to consider essential tech debt and “keep the lights on” work and capture this in your roadmap so you have a bird’s eye view of everything that’s on the table.
Key Takeaway: Organize your work into categories so that it’s easier for your team to understand and visualize the key focus areas for your product development.
Having a clear prioritization framework helps greatly, not only in organizing which work to do, when, and why, but also in communicating this more broadly within your team (and in some cases, externally as well).
There is no “right framework” as this depends on your unique context and constraints. My preference is to glean from models like RICE, KANO, Story Mapping, MoSCoW (must have, should have, could have, won't have), Opportunity Scoring, the Eisenhower Matrix, Buy a Feature, Product Tree, Cost of Delay, and more and pick the prioritization criteria that best fit your unique circumstances.
Key Takeaway: No matter which prioritization framework you use, it needs to break down into value vs. effort.
As you’re working through the elements above, a crucial question arises - what’s the best way to present your roadmap?
How should it be structured and what tools should you use? What depth of information should you provide?
There are many product roadmap presentation examples and templates teams have used, from basic spreadsheets to shared word documents, PowerPoint Presentations, to tools like Notion.
What has been severely lacking in the product space are flexible, holistic, and inclusive tools that teams can use to present roadmaps and the ideas they capture with clarity, that connect both the macro to the micro of what you’re doing so you can easily zoom out and zoom in. Your roadmap is the critical link - connecting the overall business objectives, product vision, and strategy to execution.
With more flexible roadmapping tools cropping up, like Asana, Trello, and Coda, airfocus is one tool that does a great job of offering a high degree of customization, the ability for multiple team members to be connected to and view the raw version of the roadmap, connect feedback to insights, provide transparent prioritization, and link to other tools like JIRA and Slack.
Communicating your roadmap isn’t just about sharing the “final product”. It’s a constant work in progress that as a product manager leading a product area, you will constantly be needing to adapt and refine as you learn more about your problem space, receive feedback from customers, as the market changes, as competitors make moves, and as technology advances.
As these adaptations happen, it’s crucial to:
1. Keep it simple. Don’t make your roadmap overly complicated. Anyone on any team should be able to look at it and understand it.
2. Know your audience. Give relevant context as needed based on the people who you are sharing the roadmap with. Developing your initial roadmap and gathering input from your engineering team? Make it technical. Presenting your roadmap to the company? Keep it in plain English and use terms anyone on any team will understand.
3. Communicate the why. Use it to ignite a shared belief. Everyone in the organization should be able to explain why you are working on the things that you are and how their individual work ties into this.
4. Set and manage expectations. What kinds of feedback are you looking for when presenting the roadmap to leadership? To marketing? To engineering? To other stakeholders? Set the agenda upfront and manage expectations throughout. Capture open questions publicly. Let stakeholders know what’s happening with their feedback.
5. Make it easy to find. Share where people in the organization can find it if they want to take a look (i.e. Pinned to Slack, linked on an internal Confluence or Notion page, or offering a publicly visible version). Use your roadmap to provide transparency.
Key Takeaway: Try to keep your roadmap simple, use it to create transparency in your organization, and use flexible and holistic tools that connect it to the micro and macro inputs that feed into it, in addition to the outputs (how it will be executed on) and desired outcomes.
Roadmaps should never be a static thing that you present once and only once. They should be at the epicenter of a series of iterative feedback loops to help keep what you are working on current and make sure that work results in the best ROI.
Make product discovery continuous so that you’ve got a steady stream of ideas to feed into your prioritization process.
If you launch a solution to a problem, test how well the solution actually solved the problem quantitatively, and use that information to make updates to the next version of your roadmap.
Articulate how and where your roadmap will be updated as you learn. What does the updating process look like? How frequently will you go through this cycle? (i.e. quarterly?).
Have continuous touchpoints with your team, key stakeholders, and the larger organization. Involve them in the process. Incorporate their thoughts and feedback. Ask experts in different domains and functional areas in your organization to poke holes to help make it better. Make it collaborative.
Key Takeaway: Your roadmap presentation isn’t “one and done”. It’s a constant, ever-evolving point of reference. Use this to your advantage.
While product roadmap presentations can feel overwhelming, keeping these six concepts in mind can help you create clarity amidst the ambiguity - both for yourself as a product lead and for your entire team and organization.
Use your roadmap to set the trajectory, align, and inspire. You’re in a unique quarterback position to lay the groundwork and light the way!
Ready to prepare your roadmap presentation? Check out some roadmap presentation templates that airfocus offers. If you don’t know which one to choose or where to start, check out our Ultimate Guide to Roadmaps to help you get started.