ロードマップの再考

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, for example, items in the roadmap are organized into three main categories:

• 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 features and projects. 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.

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 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 into them.

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. Closing the loop encourages stakeholders to continue engaging with your organization—and continually feeds your well of potential future product ideas.

There are many methods for communicating back. For example, using an in-app guide, through a regular product update, your customer newsletter, webinars, or your customer community. Pick the methods that work best for you and your customer base.

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.