In part one of our roadmapping blog series, C. Todd Lombardo shared insights about the common pitfalls many product managers (PMs) fall into when it comes to roadmapping, why roadmaps are not (and should not be) the same as release plans, and tactical tips to help cross-functional teams optimize their roadmapping and product development efforts.
In this post, we’ll explore the key components of a great roadmap, and take a closer look at strategies PMs and product teams can use to effectively manage and communicate the roadmap to the right stakeholders.
The five components of great roadmaps
C. Todd is no stranger to coaching product teams through the art and science of building great roadmaps. And while there’s no “one size fits all” approach for exactly how granular each product or company’s roadmap should be, there are a few core elements you should always include to make your roadmap as actionable and effective as possible.
1. Product vision
In part one of our discussion, C. Todd used the analogy of a roadtrip to describe the purpose of a product vision. “Roadmaps should indicate the direction you’re going in,” he explained. Consider your product vision as the guiding principle behind your efforts, or the ultimate end-state you’re tracking towards. Another way to think about your product vision is to imagine how the future world will benefit once your product is fully realized. Your vision can be as simple as a sentence or two (though some organizations, like GitLab, opt for more detailed vision narratives), should feel aspirational yet attainable, and should tie back to the organization’s overall vision and mission.
2. Business objectives
Business objectives ground your product goals in the greater goals of the company. The business objectives or key performance indicators (KPIs) you include in your roadmap should clearly delineate what the product will accomplish when it comes to fruition, and should ideally align with the business’ overarching goals.
3. Timeframes
Your roadmap’s timeframe denotes the priority of your efforts and indicates when stakeholders can expect to see particular initiatives in the wild. It’s important to remember that your roadmap is not your release plan. Release plans are intended to be extremely granular and project-oriented, while your roadmap should indicate the general direction of your product. C. Todd noted, “The most common timeframe we see is a quarterly roadmap, but some people do annually, semi-annually, or even monthly. Monthly can start to get a little bit granular, but there are business situations where that makes a lot of sense.” Some companies make their timeframes even broader by taking a “now, next, and later” approach. No matter which level of granularity you choose, avoid making your timeframe so specific that it blurs the line between your roadmap and your committed release plans.
4. Themes
Themes (sometimes called objectives or initiatives) articulate the problems you’re trying to solve or the challenges your product solves for. It’s important to note that themes are not a list of features. C.Todd describes themes as a combination of problems, needs, and objectives. He noted that themes emerge at the intersection of several questions, for example, “What is the sequence of things you want to solve, in what rough order?” and “What is the outcome you expect to see once you solve those things?” He also explained that the best product teams continually ask “why?”, and keep asking until they identify the root cause of the problem so they can build solutions that address the real issue at hand.
5. Disclaimer
Finally, C. Todd stressed the importance of including a disclaimer near the end of your roadmap—no matter what format it’s in. A disclaimer is a short, proactive statement that protects you from broken promises or missed milestones by acknowledging that change is possible, even inevitable. Disclaimers are also critical for managing the expectations of both internal and external audiences (more on that below).
What happens when things change?
In the world of product, as in life, it’s always best practice to expect the unexpected. Yes, your roadmap is a long-term visionary tool, but it’s unrealistic to expect that it won’t change at least slightly. External forces like market or economic trends, changes in company strategy, or resourcing and prioritization shifts can all require the roadmap to morph. C. Todd explained:
“Roadmaps do change. If you’re a really early stage company, you could have a roadmap that only goes out three weeks because things are changing so fast—you’re still in discovery mode and you’re still trying to figure out what your business model is. But if you’re a more mature company, you might have something that goes out much, much longer. Then there’s your release plan—again, your release plan [communicates], ‘This is what I’m committed to doing over the short term.’ That short term could be a week, two weeks, two months, three months, etc. Of course those first two to four weeks are pretty confident, but then . . . as you think further and further out, things can get more obtuse and a little more fuzzy—and that’s totally okay. In fact, you should expect your roadmap to change over time. If it’s not, are you reacting properly to the market? Are you agile enough?”
In the process of building broad roadmaps, C. Todd explained that it’s not uncommon for PMs to face questioning from stakeholders around the specificity of their initiatives—but noted that these queries shouldn’t stray product teams from their course. “What I often try to do is frame it as a problem,” he said. He recommended turning those questions into opportunities to do some discovery around and validation of the problem, and looking at them as a chance to learn more about the challenges users are facing. He suggested asking questions like:
- Do you see this problem in your world?
- How big of a problem is it?
- What are the challenges that you see with this particular problem?
C. Todd also suggested engaging in a conversation with stakeholders to identify the root cause of their frustrations and to help them understand how your team prioritizes its efforts. He said:
“You can hypothesize, ‘We’re not quite sure exactly what the solution might be, but we’re thinking it could look like this or that. How would this solve your problems?’ Validate the problem and then offer a high-level solution direction that might solicit a reaction from your user or stakeholder. [This opens up space for more questioning, like], ‘What else should I know about that?’ or ‘How else are you solving this now?’ It’s a good opportunity for discovery, back and forth and validation.”
The same ethos of open communication is valuable in situations where short-term priorities or items on the roadmap shift or pivot. He said:
“Just be honest upfront about what changed and why. Obviously with some customers you can’t disclose every single detail, so you have to be mindful of that. But even if you’re humble and honest and explain ‘why’ as best you can, some customers [may ultimately] need to switch away from your product because you don’t have [the feature they need]—and that’s fair enough. It might not be the best in the short term, but those things usually have better longer term outcomes. In my experience, just being upfront and not misleading stakeholders [can open a conversation about] what can be done in the meantime, and [be an opportunity] to get them involved in the discovery and development process.”
Having a clear and organized roadmap can also be an invaluable resource for these kinds of conversations with stakeholders. If you run into objections from customers and users, coming back to your roadmap to explain your long-term vision and the “why” behind your priorities can actually help build trust and drive retention. What it comes down to, C. Todd explained, is “reframing what your stakeholders have asked for in a conversation like, ‘I’ve heard you, and agree that this is a problem to solve. But it’s actually a bigger problem that we think we can deliver a good solution for—and here’s why,’ can help keep them on board.”
Stakeholder and portfolio management at scale
C. Todd noted that stakeholder management is another common area of friction faced by many PMs. “No stakeholder likes to be managed,” he explained. “So it’s really more like stakeholder alignment. The PM has to have the skill to be able to bring everybody along on the journey—and not just your internal teams, but oftentimes your external teams, partners, and customers, as well.”
Managing the expectations and opinions of all these various groups is no easy task. “Oftentimes, those stakeholders have very different goals and needs, and sometimes they’re in tension with each other,” said C. Todd. He recommended not defaulting to solely listening to the loudest voice in the room, but to also encourage the quiet voices, and ask for data (both quantitative—like product analytics and qualitative—like customer feedback) and conviction. C. Todd also suggested trying a decision log to keep track of key product decisions that were made (including when and why), so that the team can revisit them later and evaluate whether those were really the right choices for the future of the product.
Finally, C. Todd shared some advice for enterprise organizations managing numerous product roadmaps at scale:
“As you put more products in your portfolio, you have to abstract the amount of information there, because people can only consume so much information. Also, [when you’re a large enterprise], executives aren’t going to want every single little detail. They might want the ability to dive in and say, ‘What’s underneath this? Can you show me more?’, and you have to be ready for that. This is also where pairing up your roadmap and your release plan (which should be two different things) is valuable. They have different levels of granularity—but make sure that they are consistent and aligned. Because if you have stuff on your release plan that’s not represented on your roadmap in any shape or form, you’re going to get asked why you’re working on things when they aren’t on a roadmap.”
The roadmapping tech stack
While the specific tools PMs use to inform and manage their roadmaps vary from organization to organization (and sometimes even team to team), C. Todd noted that there are a few fundamental tools you should use to build the best roadmap possible.
- A tool for gathering and centralizing all your product feedback
You can’t uncover insights in your feedback data if it’s spread across multiple platforms and sources. Be sure to use a tool (like Pendo Feedback) that allows you to aggregate all your data in one place and draw correlations between it and your quantitative product data. - A product analytics platform
A product analytics tool (like Pendo Analytics) gives you objective insight into the performance of your products and how users are interacting with them Connecting your analytics data to customer feedback is crucial for making data-informed roadmapping decisions and deciding where to focus your efforts next. - A project management solution
Project management tools like GitLab, Shortcut, or Jira are commonly owned by engineering teams, but are invaluable for organizing short-term release plans. These solutions should be used in conjunction with more holistic roadmapping and feedback solution.
Ready to bring your roadmap to life with the power of the Pendo platform? Check out our new and improved roadmapping capabilities, now available in Pendo Roadmap.
