3 Types of Roadmaps in UX and Product Design

A roadmap is a strategic, living artifact that prioritizes, and communicates a team’s future work and problems to solve. It is meant to act as a single source of truth representing your UX team’s North Star. It helps the team align around a single vision and set of priorities.

Roadmaps are not meant to track execution of features across releases, but rather communicate a vision — the problems that will be solved. Roadmap items lack formal, discrete task definition and represent a range of potential future work (from research to analysis, design, and development) that has yet to be defined. 

There are 3 types of roadmaps teams can create, depending on their goal, context, and audience: 

1. Product roadmaps represent all future problems that need to be solved, including UX, marketing, content, design, research, development, support, and/or operations. 
2. Field roadmaps represent all future problems to be solved by UX (for example, related to design, research, or content), but do not include problems outside of UX (for example, in marketing, development, and support).
3. Specialty roadmaps are a subset of field roadmaps and focus only on problems within one UX area (for example, in user research). 

These three scopes have different benefits and are appropriate for different situations. This article discusses each roadmap scope, as it relates to UX; however, the 2 lower-granularity roadmaps (field and specialty) could be applied to any other field — for example, you could have a marketing roadmap and, within that field, one or more marketing-related specialty roadmaps.

Product Roadmaps Include Product, UX, and Engineering  

This type of roadmap is the broadest and most labor-intensive. It requires collaboration across multiple departments, such as product management, user experience, engineering, content strategy, customer success, and marketing. Because everyone is involved, product roadmaps capture a strategic vision across an entire product. 

Ownership

• Product managers are the primary owners and creators of product roadmaps. It is their responsibility to drive crossfunctional-team efforts and set the product-wide strategy. They lead the roadmapping initiative by scheduling time for corresponding meetings, facilitating the prioritization of future work, and creating the artifact. 
• Domain leads (e.g., UX, engineering, marketing) work collaboratively with product managers to define the roadmap. For example, a UX lead may help a product manager prioritize work when it comes to impact to the user, while an engineering lead may contribute technical-feasibility insights. In some cases, a UX lead may play the role of the product manager and lead the creation of a product roadmap. This most occurs when there is no PM, the assigned PM has limited bandwidth, or the PM lacks a user-centeric mentality. 

Benefits

• Force crossfunctional collaboration. Product roadmaps are collaboratively created by product management and crossfunctional leads. This process facilitates important discussions (for example, necessary tradeoffs) and creates coownership over the vision created. 
• Create a shared mental model. The product roadmap represents a shared visual representation of future effort. Anyone across the organization can glance at the product roadmap and understand the strategic vision of the product. 
• Breakdown department silos. Product roadmaps establish the bigger picture. We can see how our work relates to the work of other departments because they include all problems, not just UX ones. They communicate relationships, dependencies, and the role our work plays in the greater vision.

Challenges

• Require crossfunctional participation. While product roadmaps can be created in a silo without collaboration, you need others to buy into the product vision that your roadmap establishes. Consensus is most likely to be established if collaboration starts from the beginning. However, this is easier said than done: departments will have conflicting goals (usually driven by success metrics), which makes prioritizing problems tricky and potentially tension-ridden.  
• Involve politics. Because product roadmaps are ideally used by everyone (including stakeholders and clients), inevitably politics will play a role (for example, who creates the roadmap, who contributes to it, who has authority to change it, and even the criteria used to prioritize within it). While balancing the politics is worth it (for the sake of building a shared vision), the collaborative process to create a product roadmap is far more laborious and time intensive than those for other roadmaps.

Field Roadmaps Include Multiple UX Areas  

Field roadmaps include problems to be solved by any UX area: user research, UX design, content, information architecture. Unlike product roadmaps, field roadmaps can cover multiple products (or product areas). They provide a way to align across UX areas and educate stakeholders on the user-centered design process.

Ownership

• UX directors or leads are the primary creators of field roadmaps. These leaders (or managers) oversee multiple UX areas within a product and are responsible for the team(s) who deliver on the UX vision. These are often the same individuals who participate in the creation of the higher-level product roadmap and thus understand the driving strategy and vision.       
• UX program managers may also be creators of field roadmaps. They are the people tasked with program- or organization-level design operations that include multiple UX areas.

Benefits

• Bridge UX areas. A field roadmap interweaves objectives from all UX areas. For example, the design team can see what research is tackling concurrently. The roadmap enables general awareness and fosters crosspollination (for example, a designer can observe research relevant for her future work). 
• Communicate the UX-design process. While a user-centered design approach is second nature for UX practitioners, many teams must still educate their stakeholders on what it means to design user-first. A field roadmap communicates the design process, from early discovery research, to content creation, to wireframing, because future UX work is clearly articulated and prioritized. It gives a high-level view into the problems the UX team must solve and frames needs from the beneficiary’s point of view.

Challenges

• Outline process, not resource allocation. A field roadmap is still a relatively high-level artifact, especially if the product is complex, with many different features or channels. Field roadmaps are too broad to indicate meaningful resource allocation (compared to specialty roadmaps, which are granular enough to communicate bandwidth). Ownership (within a theme) on field roadmaps is at the team or area level, whereas ownership on specialty roadmaps is at the individual team-member level.      
• Require coordination with the product roadmap. While field roadmaps are less laborious than product roadmaps because they are driven primarily by the UX group, they still require collaboration with the product director or manager whose responsibility is to drive the overall strategy of the experience. Prioritization of UX problems should align to the higher-level roadmap or product priorities. 

Specialty Roadmaps Include One UX Area 

This roadmap scope focuses on just one UX area (e.g., user research, UX design) and outlines the problems this area will solve. Specialty roadmaps can cover multiple products (or product features) but will always include only efforts related to the roadmap’s area. They support alignment within a specific team, as well as communicate resource bandwidth and allocation. 

Ownership 

• Lead or senior UX practitioners (of any area) can create specialty roadmaps. These specialty roadmaps outline their team’s realm of responsibility as it relates to the specific UX area.     
• ResearchOps or DesignOps roles who are responsible for owning the operational aspects of research or design are also common creators of specialty roadmaps. For example, a ResearchOps manager may create a research roadmap to organize and communicate who is working on what problem and balance resource allocation.  
• Individual UX contributors can create specialty roadmaps that outline the problems they will personally be tackling in the future. This type of low-granularity roadmap is most common on small teams (or organizations with lower UX-maturity), where an individual operates as a team of one and wants to communicate the strategic approach to her work. 

Benefits

• Communicate bandwidth and allocation. Specialty roadmaps are great tools for visualizing bandwidth because it’s easy to see which team member tackles what problem. At a glance, a specialty roadmap can give insight into how many themes (now, next, and in the future) each team member is responsible for. This information can balance workload, in addition to advocating to stakeholders for additional resources to cover unassigned themes.   
• Unite and align team members within an area. In organizations where areas are distributed to varying pods or teams (each with their own lead), specialty roadmaps bring alignment and awareness of the work done by others in the same area. They encourage knowledge sharing, crosspollination, and a general sense of belonging.  
• Easy to create. Due to the scoped nature of specialty roadmaps, they tend to be the easiest to the create (especially if the creator is the primary owner of each theme). Collaboration isn’t required and there is far less politics involved than in the creation of product and all-UX roadmaps. Specialty roadmaps are a great start point for UX practitioners creating their first roadmap. 

Challenges

• Limited audience. Specialty roadmaps are, as their name suggests, specific. Thus, they are relatively few people who find them useful (or care about their existence). Less time and labor should go into creating them, since their use is limited. Try to time-box their creation, spend minimal time making them “pretty”, and prioritize a tool that enables easy revisions.    

Conclusion 

Product roadmaps are good for collaborating across departments and driving one united vision but are too complex to clearly communicate all aspects of the UX process. Field roadmaps interweave UX problems that need to be addressed by all UX areas and, thus, effectively convey the UX-design process to stakeholders. Specialty are useful for advocating for resources and balancing bandwidth because they identify who works on what. 

The first question you should ask yourself is: what is the primary goal of the roadmapping initiative? Each roadmap scope achieves different goals. Your roadmap scope should match the benefits you hope to receive.

Learn more in our full-day course UX Roadmaps.