Roadmaps, reimagined

Chapter 1: Product roadmaps 101

A brief introduction to all-things-roadmapping

プロダクトロードマップとは何ですか？

A product roadmap is a visual summary of a product’s vision or desired direction.

Roadmaps help organizations facilitate and scale communications with their customers, prospects, partners, and internal stakeholders. They do this by signaling the general trajectory of the product in the coming months—or in upcoming product releases. A roadmap not only gives users and internal stakeholders a glimpse into what features and functionality they can expect to see soon, but also creates a single source of truth for the teams responsible for building and selling the product.

The level of detail included in a product roadmap is typically a matter of company preference (more on that in chapter 3!). In general, however, it’s best practice to keep it high-level and distinguish it from its more task-oriented counterpart, the project plan.

Product roadmaps provide an at-a-glance view into the product’s future, supported by key high-level themes and initiatives. Project plans, on the other hand, denote details about how the features and optimizations within each initiative will actually come to fruition. It’s helpful to think of product roadmaps as visionary, while project plans are more tactical.

Beyond their many logistical and organizational benefits, product roadmaps also serve as powerful unification tools. They increase transparency across the organization by creating a shared understanding of your product’s direction, encourage a product-led mindset, and help internal and external stakeholders alike feel like they’re part of the planning and development process. Particularly in product experience-obsessed organizations, the roadmap is the north star for the company’s trajectory.

Who are product roadmaps for?

Every company has a different take on who should have access to their roadmaps. Some organizations choose to keep their product roadmaps close to home, only making them visible to internal teams—while others openly share their roadmaps so they’re available for everyone (namely customers, prospects, or investors) to see.

The decision typically comes down to factors like the industry the company operates within, compliance or regulatory considerations, the competitiveness of the product’s niche, how mature the organization is, and the overall ethos of the company (i.e. open-source companies are generally more likely to make their roadmaps customer-facing than more traditional corporate organizations might be).

There are three buckets of visibility you could consider for your product roadmap:

• Internal, for your product team only
  A product roadmap built by the product team, for the product team—this will typically be the most granular and technical roadmap of the bunch
• Internal
  A product roadmap that is viewable—or contributable-to—by anyone inside your organization, not just the people who directly work on the product
• Customer-facing
  A product roadmap that is accessible by both internal and external stakeholders

As a best practice, most companies start by circulating their product roadmaps internally. This gives them an opportunity to test drive the efficacy of their roadmap and solicit feedback from employees before opening it up to customer input. An internal-facing roadmap can also be a valuable way to foster empathy and collaboration among internal teams—like product, sales, customer success, and marketing—and empowers your employees to have more informed, product-led conversations with customers and prospects.

If you’re able, making your roadmap customer-facing can have numerous benefits, too. Sharing your roadmap improves transparency and increases trust with customers, helps scale product-related communications (i.e. your account teams can point to the roadmap instead of having to communicate product updates to customers manually), and shows key stakeholders that you’re actively working to innovate and improve the product. A customer-facing roadmap also signals confidence, and can even be a helpful persuasion tool for selling the product’s vision and capabilities to prospects or investors.

Whatever approach you choose (you might even opt for both!), it’s important to consider your audience as you’re building your roadmap. Think about the language you use and be mindful of the level of detail you disclose. While your internal teams might need to see all the underlying context involved in an upcoming launch, your customers only need the high-level overview. More on this is chapter 3.

Why do I need a product roadmap?

When done right, a product roadmap is a powerful reflection of your vision—and your users’ expectations—for your product.

The strongest feedback-informed roadmaps keep your product team in lock-step with your users. They focus your team on solving real problems your users are facing, as well as challenges they’re looking to solve with the product. This enables your product team to anticipate the impact of your efforts and create features and functionality that your users will actually deem valuable—which ultimately improves feature adoption and product stickiness down the road.

Product roadmaps are also incredible rallying tools. They align your organization around a shared purpose and keep your team tracking towards a common goal, encouraging a product-led mindset across your organization. They democratize ownership of the product throughout your workforce. And they hold your product team—and everyone who has a hand in the product or customer experience—accountable for contributing to the company’s strategic goals.

Depending on your organization’s stage of maturity, product roadmaps can have other benefits, too:

• Startups
  Because startups are generally focused on getting up and running as quickly as possible, their product roadmaps might look more lightweight and adhere to a tighter release cadence than those of more established companies. A well-organized product roadmap can be incredibly helpful for keeping fast-moving startup teams organized and focused, while reinforcing a spirit of continuous iteration (remember that MVP we talked about earlier?). Good product roadmaps can even help startups secure funding and interest from investors—by painting a clear vision for the product’s future and bolstering confidence in the team building it.
• Enterprises
  More established organizations with distributed teams face very different challenges from agile startups. Product managers (PMs) in this environment generally spend a good amount of time building buy-in and vying for resources. They also face the challenge of scale, and need to invest heavily in processes and tools to support the growth of the product. A good roadmap can help PMs more easily share their vision throughout the organization and make the case for additional resources. It can also unify disparate teams and—when informed by feedback and analytics—be a powerful way to validate and support product decisions.

A good product roadmap is…	A good product roadmap isn’t…
A signal of the product’s direction and vision	A feature wishlist
Data-informed and feedback-driven	Based on gut-feel alone
Flexible and updated regularly	Immovable once it’s been created
Made to increase transparency and benefit everyone who interacts with the product	Made only for the benefit of the product team

Chapter 2: Fueling your roadmap

Where to find the data you need to inform your roadmap

If you live in the software world, you likely already know what a roadmap looks like. But building a great roadmap is about so much more than just making something that looks pretty. And it demands rigor to ensure you’re not just focused on the projects and initiatives you want to work on (or think you should work on) based on anecdotal requests.

Using data to inform your roadmap and show how decisions are made is becoming increasingly important for product teams. As the software market gets more crowded and it becomes easier for users to jump ship from solutions that just aren’t cutting it, data has become every product team’s holy grail—the difference between guessing what to do next, and knowing what to do next.

A data-informed approach that equally weights both quantitative usage data and qualitative feedback is key. And having the right tools in place to feed and manage that information means your roadmapping efforts will only keep getting better with time—allowing you to confidently course-correct or encourage behaviors as needed as your system gathers more insights to inform your decisions.

In this section, we’ll cover the core data sources you should be leveraging to inform your product roadmap.

会社の戦略と目標

Your company’s overarching strategy should always be the glue that binds the elements of your product roadmap together. Aligning your product roadmap to key organizational initiatives not only ensures your team is working on the right (leadership-approved) things, it’s also the best way to validate and explain the reasoning behind any product decisions.

Your company strategy and goals are also a great way to gate-keep your product roadmap. As you build it, ask yourself: What does the company want to achieve? Which markets matter? Who is our target customer persona? Do the activities in our roadmap align with these goals? If an item on your roadmap doesn’t support a business initiative, chances are it shouldn’t be there in the first place. There are a million different things you could build, but very few that you should.

ユーザーアナリティクス

Roadmaps are only as good as the data that feeds them. Fueling your roadmap with guesses and gut-feel alone leaves your team building blind. And as much as every PM knows and loves every inch of their product, they aren’t “every user” and never will be. Without a clear view into the ways users are really engaging with your product—where they’re spending most of their time, where they’re getting stuck, which features they find most (or least) useful—your team can’t create a plan to meaningfully address those problems.

User analytics provides an objective, unbiased look into your users’ moments of frustration and delight. This information helps you identify exactly which aspects of your product need improvement—something that being too familiar with the product makes nearly impossible for PMs to undertake on their own. By understanding your users’ behaviors, you can better guide them through your product, and build initiatives or features into your roadmap to address the sticking points they’re experiencing.

お客様の声（VoC）

Qualitative insights add rich color and context to analytics. Qualitative data—gathered through surveys, polls, and feedback—helps you get to the “why” behind the numbers, so you can understand the full picture and address the root causes of the problems your users are facing. Combined with usage and behavioral data, the perspective of the people who use your products day-in and day-out is a critical source of inspiration for your roadmap.

The best roadmaps are informed by a strong voice of the customer (VoC) program. Having a VoC program in place helps your team scale the process of gathering customer sentiment and requests, and—when done well—ensures their wants and needs get reflected in the features you’re building. Incorporating qualitative data and VoC insights into your roadmap ultimately leads to better adoption and loyalty down the road, and shows your users that you value their opinions.

見込み客のリクエスト

Requests and suggestions you hear from prospects can be a great source of inspiration for your product roadmap—especially if the same ideas or themes keep surfacing again and again. Since they’re usually new to your offering, prospective buyers bring fresh perspective to your product. Their insights can be particularly valuable if they’re exploring other solutions, too—giving you an opportunity to learn more about your competitors and any wider market changes you might need to respond to.

In general, it’s a good idea to approach prospect feedback with a little bit of caution. Because most prospects haven’t used your product yet, any objections or issues they have with your features during the sales cycle might actually be moot once they do start using it. So don’t fret too much if nominal, one-off comments come up. On the flip side, if a prospect makes a request that aligns with your company strategy and vision, committing to including their idea in your product roadmap can be a great way to seal the deal and get high-value initiatives into your queue.

市場動向

While it’s never a good idea to abandon your strategy just because of goings-on in the market around you, understanding the competitive landscape can be an important source of information for your roadmap—and even add context to user behaviors or the engagement you’re seeing with your product.

If your product roadmap is grounded in your company’s goals (hint: it should be!), any movements in the market or news from your competitors shouldn’t sway your plans too much. Instead, stay the course and leverage your market knowledge to guide strategy discussions. Consider where your industry is heading and where you need to focus to stay differentiated (or maintain parity). And think about how this insight might impact how you talk about your roadmap with prospects and customers.

Chapter 3: Building your roadmap

How to structure and bring your roadmap to life

No matter what tools your organization uses, conceptually, building your roadmap is relatively simple. While there isn’t a one-size-fits-all approach for the exact format and level of detail you should include, the same general structure and basic building blocks apply across the board.

In this section, we’ll walk through the basic steps involved in building a great product roadmap.

Establish ownership

Before you start putting your roadmap together, it’s important to determine who will own it and keep it current. Nine times out of ten, that person will be your PM.

PMs are the conduit between the broader organization and everything going on inside the product. Their responsibilities include creating and managing the roadmap, triaging incoming feedback, and holding the right teams accountable for their specific workstreams. PMs are typically also charged with building buy-in for initiatives at the leadership level and ensuring that anything their team is working on stays in alignment with the company’s overarching goals.

If you’re a multi-product organization, you likely have multiple PMs. By extension, that means you’ll have multiple product roadmaps, with each PM responsible for their own product area. In this scenario, it’s also important to appoint someone—typically the manager of those PMs—to oversee all your various roadmaps and help keep tabs on the features and initiatives each product team is working on. This helps prevent duplicity and creates a more united product organization (and ultimately, a more cohesive product experience).

Start with strategy

Your roadmap is only useful if it’s grounded in strategy. Without a firm footing in your organization’s goals, your roadmap could run the risk of turning into a disorganized (and ever-growing) wishlist of features without a clear end goal.

Before you start building your roadmap, it’s critical to have a clear sense of your company’s direction and goals for the coming weeks and months. Are there important organizational changes on the horizon that could impact the product? How is the company positioning itself and its offerings? What key performance indicators (KPIs) does the company need to achieve, and how will the product contribute to them?

Knowing the answers to these questions will help you decide what makes the cut—and perhaps more importantly, what doesn’t—for inclusion in your roadmap. If you can’t map an initiative back to your company’s strategy, there’s a good chance you shouldn’t be giving it your time or attention. Sticking to strategy also helps you stay focused and avoid feeling overwhelmed by all the things you need to accomplish. Your product teams will feel empowered to say “no” or “not now” if they’re asked to work on something that doesn’t align with the company’s current goals.

Determine your information hierarchy

Depending on the platform you use to build and manage your product roadmap, you may be working with a preset content hierarchy that organizes all the different aspects of your roadmap. Regardless of whether your system pre-defines these categories for you, or if you create them yourself, be sure to establish a taxonomy and hierarchy that works for your team.

In Pendo Feedback, for example, items in the roadmap are organized into four main categories:

• Swimlanes
  Swimlanes help organize your roadmap by product area. You can use swimlanes to break up the items in your roadmap by teams or accountabilities, areas of expertise, or any other structure you use to divide and conquer everything you need to get done.
• Initiatives
  Sometimes called epics, initiatives group more granular objects—namely, features and requests—under a shared objective or big idea. Initiatives should clearly tie back to company goals and ladder up to the product vision. Establish a clear naming convention for your initiatives: descriptive enough to be easily understood by someone who doesn’t live and breathe your product, but broad enough to capture all the individual features within it.
• Features
  Features are the specific elements of the product you plan to build—product capabilities and functionality you’re working to add or optimize. By grouping the features on your roadmap under initiatives or epics, you’ll be able to tell a clear story about the role each feature will play in helping the organization achieve a goal or adhere to its strategy. And you’ll be able to clearly articulate the “why” behind everything your team is creating.
• Requests
  Requests are submitted by users or internal teams through Pendo Feedback. As their name suggests, they’re the specific additions or changes users want to see in the product, and can be used to add context to your roadmap at either the feature or initiative level.

Some organizations use an even more granular hierarchy in their product roadmaps. But for most teams, this structure is more than enough. If your roadmapping platform allows for the addition of more categories, just be careful not to overdo it. Only use as many levels as you really need to avoid overcomplicating or cluttering your roadmap.

Create a structure

Here comes the fun part—actually building the bones of your roadmap!

One of the first decisions you’ll need to make is whether you want to assign timeframes or deadlines to all the features and initiatives in your roadmap. By default, Pendo’s roadmapping functionality is laid out in a quarterly format, as this is often the top timeline used by product teams to communicate their product strategy (though we’re also working to add more scales to suit different roadmapping styles). A word of caution: if you do decide to include deadlines in your customer-facing roadmap, you may run the risk of upsetting customers or prospects if your development schedule doesn’t go exactly to plan. So proceed with caution!

Other options for laying out your roadmap include level of urgency, prioritization (e.g. now, next, later), planned product releases, or company announcements. Regardless of which structure you choose, pick something that aligns with your organization’s project management framework, and be sure your team knows how to navigate the roadmap.

Once your structure is set, work your way from the “who” (swimlanes) to the “why” (initiatives) to the “what” (features), validating your decisions and incorporating additional user context and feedback (requests) as you go. In Pendo, populating your roadmap is as simple as defining your swimlanes, naming your initiatives, then dragging and dropping the corresponding features or requests into them. And with Pendo Feedback’s prioritization and upvoting capabilities, you’ll get a clear sense of which features your users want most, and which will ultimately deliver the greatest value to your business.

Tell a story

The story you tell through your roadmap will vary depending on how and with whom you share it.

In general, internal roadmaps are more granular than those shared externally. They often include nitty gritty details and user metadata that adds valuable context for the teams responsible for the product—but that external parties can’t (and shouldn’t) see. On the other hand, customer-facing roadmaps keep things more high-level. They give customers, prospects, and investors a “drive by” of what you’re working on and how it will make their lives easier, while getting them excited for the future.

Here are some general considerations to keep in mind as you look to your roadmap as a storytelling tool:

• Customers and prospects
  Tell a story about progress. Your customers want to know that their voices are heard and that your product team is listening to their feedback—while prospects want to feel confident that your product can help them reach their own goals. Showing progress being made against requests and providing a general timeline can go a long way in earning trust and loyalty.
• Customer-facing teams
  Tell a story about empowerment. Your roadmap can be a powerful tool for empowering your customer-facing teams—specifically sales and customer success. It gives them leverage in conversations with customers, arms them with language to more confidently talk about the product, and can even help them close deals with prospects who have specific product needs and requests. Be sure to provide enablement to your customer-facing teams so they know how to talk about the roadmap—and so they don’t make promises your product team can’t keep.
• Product and engineering teams
  Tell a story about alignment. For your product and engineering teams, your roadmap is the north star—keeping them tracking towards the same goals and working on the right tasks. Your roadmap should help them clearly visualize their responsibilities, see the status of initiatives and features, and help them easily find contingencies or helpful context.
• Leadership
  Tell a story about impact. Your roadmap is a great way to keep your management and leadership teams informed about what you’re working on and—perhaps more importantly—why. Like your customers and prospects, your leadership team doesn’t need to know the minutiae involved in each feature you’re building. But they do need to know what impact your product team’s efforts will have, and how they are contributing to the bottom line. Your roadmap is a powerful tool to help demonstrate action and show the “why,” made even stronger with supporting VoC feedback.

フィードバックの循環

Once your roadmap is in place, it’s critical to ensure you have clear processes in place for keeping anyone who has contributed to it—through feedback, requests, or otherwise—informed on the progress you’re making.

Pendo Feedback simplifies this task of closing the loop through automated emails and in-app messages, triggered with every feature or initiative status change. This simple action builds trust with your audience, lets them know you’re listening and acting on their input (even if you can’t get to their specific request right now), and makes them feel like a valuable and respected part of your innovation process. Closing the loop also encourages stakeholders to continue engaging with your organization—and continually feeds your well of potential future product ideas.

Putting your roadmap to work

Tips for creating actionable and adaptable roadmaps

A roadmap isn’t a “set it and forget it” kind of endeavor. Once live, it’s important to keep it updated to make sure it demonstrates real-time progress, inspires curiosity, and accurately reflects your company’s strategy (and how your product contributes to it).

In this section, we’ll cover a few best practices for making the most of your shiny, new roadmap.

Give your roadmap a home

A customer-facing roadmap won’t do you any good if no one can find it. Be sure to make the roadmaps you want customers, prospects, or investors to see easy to find. Give them a home in your app, on your website, or in other media materials, and enable your customer-facing teams to confidently speak to them.

Leverage your roadmap to scale

Leverage your roadmap not only as an organizational tool, but also as a vehicle to scale your efforts. Encourage customers and prospects to engage with your roadmap and ask them to submit feedback or vote on the activities that matter most to them. And push your customer-facing teams to direct customers to your roadmap if they have questions about pending or in-progress features. If your roadmap is rock-solid, it can help your team broaden their outreach efforts and reduce some of the manual back-and-forth that comes with explaining changes in your product.

Prioritize your roadmap using data

Prioritize key initiatives and features based on customer and prospect feedback, not gut feeling. Taking a data-informed approach—based on what your users are saying they want and need most from your product (and backed by behavior or usage analytics)—is the best way to ensure that you’re continually focusing your efforts on the right things, at the right time.

Keep your roadmap updated

Your roadmap is intended to indicate your product’s direction in the coming weeks and months. But that doesn’t mean you can just set it up and forget about it until next quarter. More often than not, roadmaps continually evolve. As strategies change, dependencies get uncovered, and priorities shift, so should your roadmap. Make sure each PM has a plan and cadence for reviewing their product roadmap and making adjustments as needed.

Feed your roadmap with good data

Your roadmap is only as good as the data that feeds it. So it’s critical to invest in tools that capture both quantitative usage data and qualitative feedback to continually inform your strategy and color your roadmap.

A tool like Pendo Analytics allows you to understand how your users are really using your product. Combined with qualitative user insights—gathered through a tool like Pendo Feedback—you’ll be able to get a complete picture of the user experience and be more strategic about planning and executing on your roadmap. This continuous cycle of data gathering, synthesis, and planning ensures your roadmap is always timely and data-informed—so you can feel confident in your product strategy and users’ likelihood of adopting your new features.

---

Roadmapping checklist

A simple checklist to get your roadmap ready for prime time

You’re ready to get roadmapping! Use this handy checklist as you build your roadmap—and whenever you make adjustments to it—to help set your product up for success.

Get your checklist here

STRATEGY

• Assess your company’s strategy and goals
  What are your organization’s goals for the coming months or quarters? What strategic initiatives must the product support? What KPIs do you need to hit? How can the product help the company get there?
• Evaluate your existing roadmaps (if applicable)
  Does this strategy call for a new roadmap? Or could you create new swimlanes or initiatives inside an existing one?
• Establish ownership
  Who will be responsible for building and keeping the roadmap up to date?
• Determine your audience
  Who is this roadmap for? Will it be made public or only viewable by internal stakeholders?

STRUCTURE

• Choose your platform
  Which roadmapping tool will you use?
• Set up your structure
  How will you lay out your roadmap? Are there specific milestones or company announcements you need to work around or be aware of? Is the timeline realistic?
• Document key themes
  What specific areas or functionality should the product team focus on to help the company reach its strategic goals?
• Establish your swimlanes
  How do you want to organize the initiatives your team will focus on? What value will these efforts deliver to your users?
• Populate your initiatives
  What big ideas or groups of features will bring that value to life? How does each initiative contribute to the company’s vision?
• Add in features
  What specific capabilities do you plan to build that will contribute to each initiative?
• Incorporate feedback
  Are there specific user requests that add additional context to each feature or initiative? Is the feedback prioritized, and does it inform which areas of the product you’re focusing on?
• Add supporting context
  Are there any other details your product or engineering teams should know that could help them be more successful?

SCALE

• Train your internal teams
  Do your customer-facing teams know how to confidently talk about the roadmap? Have they been adequately enabled to discuss any roadmap-related questions with their customers or prospects?
• Share your roadmap
  Based on your audience, where will your roadmap live? How will your stakeholders find it? What story is your roadmap telling—and does it resonate with your audience?
• Solicit input
  How will you gather feedback and encourage users to engage with your roadmap? Where should users go to submit ideas or weigh in on what matters most to them? Do you have a process in place for triaging incoming feedback?
• Close the loop
  Do you have a system in place to close the loop with your users and keep them informed of changes to your roadmap? What kinds of updates or communications should users expect from your team?