• Neuron

How to Create a Product Roadmap

Breaking it into a 6-step framework


Mid to late-stage product teams typically have a jam packed kanban board of tickets, and a seemingly endless list of product ideas to implement. This ranges from bugs and support tickets to feature improvements. It is common for tickets and requests to be added faster than product teams can execute them, resulting in endless backlog grooming. This is where prioritization helps and roadmapping is key.


First, what is a product roadmap?

A product roadmap is a crucial artifact that articulates the vision for the product. An effective roadmap is clear and serves to keep stakeholders and product teams aligned on what objectives they are targeting or which features they are implementing when, and why.


Trust the process.

Teams need a north star to align their actions with larger business objectives. A roadmap should serve as a guide for overall vision and direction, but with the understanding that it is not concrete and that dates are not set in stone. Making it easily accessible (in a tool like Mural) ensures that the roadmap can be frequently referenced across the organization.

We believe that roadmaps should be the output of a consensus driven approach to planning and prioritizing. Prioritization is important for identifying what is important and what is simply a nice-to-have because — when done well — it accounts for what is feasible, desirable, and sustainable. Most of all, prioritization can simplify decision making.


Typically this is a week-long process, which happens twice a year at minimum or as frequently as every quarter. In smaller organizations where there may be a need to pivot quickly to bring value to the market, or respond to a change in the space, a more frequent roadmapping cadence may be desired. Ideally the process of creating a product roadmap is a team effort. We find this to be most effective when all teams within the business — from engineering to design, and executives — are involved in the process of determining the roadmap with a full understanding of business objectives and goals. By including different areas of the business, product managers can get more insight.



Our approach


1. Conduct research

While there is a sentiment in some companies that the work of research should be done solely by the UX Researcher, we believe that this work is best shared across the product team. Instead, we advocate for a multidisciplinary approach to research and analysis. Looking beyond usability metrics to evaluate a product is crucial for understanding the big picture. Developers, visual designers, marketers, strategic partners, and customer support team leads have unique insights based on their experience with the product, the customer, heuristic evaluation findings, or the performance metrics they are accountable for.


In addition to being multidisciplinary, these efforts should be ongoing. This is not something that is done once before the product is created. We encourage our clients to commit to conducting comparative, competitive, and exploratory research at regular intervals. It is important to create a culture of assessment and validation, looking at task completion with prototypes. This helps teams make informed decisions when planning and prioritizing throughout the product life cycle. UX Researchers should treat this an opportunity to lead and nurture a culture of research and data-informed decision making.


User needs can be extracted from from a number of sources including interviews, support calls, app store reviews, and usage data.

2. Identify user needs

A product roadmap is like a funnel — collecting known challenges, issues, and feature requests. But a performative roadmap needs to look ahead and evaluate the user journey in detail to identify opportunities that will support longevity and growth. At the end of every sprint teams should reconvene to turn their notes, backlog tickets, ideas, and customer feedback into action items or features. While ideas are seemingly infinite, capacity is finite. Mature product teams should be working defensively, proactively, and stealthily. This simultaneous or three pronged approach is necessitated by competition in the market and evolving user needs. As we design and launch new features, we tend to uncover new problems or opportunities. As other players do the same, product teams need to make changes to keep their product relevant and competitive.


Defensive or reactive design is typically characterized as a product team’s response to known issues. This might include: addressing common complaints from customers, technical debt, or other trailing backlog items. This term also refers to designing to meet the industry standard or user expectations. Product teams without a culture of design or who do not roadmap at a regular interval can often find themselves stuck in a cycle of reactionary work or putting out fires, instead of developing new or proprietary features. For example, continuing to optimize a banking feature when it was really just time to integrate with Plaid.


Proactive design gives product teams an opportunity to look ahead. This includes identifying new opportunities or introducing smaller changes that provide a meaningful user benefit. This is an outcome of multidisciplinary research, which offers insights likely to have been missed by a singular UX researcher lens.


Lastly, stealth design is rooted in developing features based on new opportunities. This might be a feature not yet available in the competitor landscape. Ultimately, it is something that will distinguish your product from others. These features are typically those that support a larger business objective and have dollar value associated with them.


This is a helpful framework for analyzing user needs because it lends itself well to prioritization. While stealth features will help with user acquisition, defensive design will support retention.


3. Quantify success measurements

For teams of any stage, it is important to define and then quantify success. This not only empowers team members to understand their impact, but it also provides quantitative insight into product performance. This requires setting up comprehensive analytics and event tracking so that product performance can be assessed on an ongoing basis. In addition to analyzing the data from a high level, it is important to identify which metrics product team members are responsible for or being evaluating against. Marketing, design, and development for example, will have varying degrees of influence depending on the metric. However, across the organization people should be clear on their measurable objectives, in addition to what other teams are prioritizing. When setting goals we also recommend bringing the larger business objectives to the table as this inevitably influences the more granular goals.


Data can be used to support decision making and prioritization when new ideas inevitably surface. For example, app store reviews may show a growing demand for iOS dark mode, and while this would make a small, vocal segment of users happy it is important to pragmatically evaluate the impact, if any, relative to other features that have already been scoped and resourced for. When increasing scope or adding a new feature it is important to remember that capacity is finite, meaning we need to question whether a new feature is merely a distraction or a true value add.




4. Identify risks

Effort and duration can be risks when not accounted for accurately. This is why we like the poker planning technique for estimation, which is useful for cleaning up the product backlogs and not overloading sprints. This is a consensus based approach to estimating and sprint planning. This is a natural next step to making decisions about which tickets or opportunities to act on as it introduces scope and makes it possible to account for capacity.


Whether you proceed with this specific technique or not, the next step is to estimate and scope the opportunities or tickets identified and grouped in the previous step. Engineers will need to provide estimates to understand effort and timing. It should be understood (of course) that the roadmap is not rigid, but instead flexible and evolving. This is a consensus driven approach that generates accurate estimates from across the project team. Like everything else we’ve endorsed for roadmapping, this approach is collaborative and cross-functional.

It is important that estimates are as accurate as possible. This ensures that priorities reflect capacity, which can help teams understand whether other longer term objectives are being put at risk due to upcoming sprint activities.


5. Consider technical constraints

Before committing to a solution it is important to identify any technical constraints. Failing to do this honestly can jeopardize both timeline and budget. Without fully understanding the constraints or challenges their technology choices are likely to pose, teams may create technical debt and deploy bandaids, the impact of which is not known immediately.

The concept of technical debt — which refers to the higher, long term costs of choosing a series of shortcuts, either because they are faster, easier to implement, or too costly to replace — is an important one to understand. Most product teams have some degree of technical debt. Typically budget, capacity or a narrowed view of the product can lead teams to invest in the wrong or merely short term solutions.


Additionally, technical debt can be expensive and inefficient in the long term. It is important to think about technical constraints in the long term. Asking for example whether the choices you make now will slow the organization down in the medium term or lock you into dependence on a single resource or vendor. For example, for content heavy marketing websites we often encounter client teams that cannot publish changes without involvement from a prior development vendor. This creates a bottleneck which interferes with initiatives as there are typically not enough developer resources to manage other projects as well as content updates. We then find that teams leverage a number of plugins to gain autonomy, which can create a messy patchwork of tools that can have adverse effects on website speed and security. However, the longer a pattern like this persists, the larger the effort required to replatform the CMS.

To begin introducing timelines and chronology, we prompt our clients to think about what they want to do now, next, and later. This begins by drawing three concentric circles. The smallest circle in the center represents “now,” while the circle in the middle represents “next” and outside of that represents “later.”


To begin introducing timelines and chronology, we prompt our clients to think about what they want to do now, next, and later. This begins by drawing three concentric circles. The smallest circle in the center represents “now,” while the circle in the middle represents “next” and outside of that represents “later.”


6. Come up with potential solutions

Once you have analyzed the data, stated your goals, identified the risks, and worked through the technical constraints it is time to act. Using what you have learned in the earlier steps, you will be able to propose solutions that are not only desirable, but actually feasible. By accounting for risks and constraints you are likely to avoid technical debt and manage risk, or make an informed decision about how much risk or debt you’re willing to take on. When working through potential solutions we recommend choosing a framework that will help you evaluate them based on effort and value or show chronology based on your goals.


It can be challenging to accept that we cannot achieve all our product goals immediately. As mentioned above, capacity is often one of the most common barriers. As a result many ideas inevitably make their way into the backlog. As priorities change it is important to periodically groom the backlog and reprioritize accordingly. To start, try doing this quarterly at minimum, though ideally this should align with the existing goal setting and reporting schedule that teams are following.


Prioritization is never really done and the roadmap is continually evolving as new requests are always coming in and opportunities are always evolving. Ultimately, the goal is to provide product teams with a north star. Priorities can be expressed as features, tasks, or questions to be answered. This ensures that the activities for an upcoming period reflect the goals and priorities of the organization. Like everything else in the roadmapping process, selecting the next great product feature should be collaborative.


Looking for a strategic design partner to support your product roadmapping process? Email us at hello@neuronux.com to tell us about your product and your goals.

Subscribe for more UX insights, case studies, and events from the Neuron team.

Let's talk!

Join us (virtually) for our monthly UX Meetup in San Francisco.

  • Neuron's LinkedIn profile
  • Neuron's Medium blog
  • Neuron's YouTube Channel

Interested in joining the team?  Explore Careers at Neuron.

Neuron © 2020