In every organization roadmaps look differently, are planned differently, and used differently. Nevertheless, many of them make one fundamental mistake: To treat a product roadmap as a project plan = a prioritized list of features that are deployed on a timeline and have due dates.
This leads more often than not to a lot of unnecessary planning work, too many alignment meetings, an inflexibility of changing the roadmap, and slow or impeded implementations. At the end of the quarter, everyone is frustrated with “not making progress” and feels trapped in a hamster wheel of constant planning, alignment, and feature creep.
The good thing is that alternative approaches exist that make roadmaps much more enjoyable for your whole organization and the one that I personally favor comes originally from the company ProdPad: theme-based roadmaps.
How theme-based roadmaps work
A theme-based roadmap is based on 2 key principles:
- Instead of listing features, the roadmap contains themes and initiatives
- Instead of planning features on a Gantt chart/timeline, initiatives are separated into 3 buckets: Now, Next, Later
A theme represents a user or business problem you plan to solve in order to reach your OKRs. Similar to what we highlighted already in the previous chapter, themes are outcome-focused rather than output-focused. In the simplest version, your themes are your objectives, but for large goals, you might have several themes per OKR.
An initiative is an opportunity to solve the problem/work towards achieving the intended outcome of the theme:
- If there has been no concrete solution discovered yet, this initiative can be a discovery activity to collect data and validate a potential solution (“How might/can we…?”).
- If a solution has been ideated and validated, the initiative could be to deliver the solution.
The three “time buckets” can be understood like this:
- NOW – Initiatives (delivery as well as discovery) your team is currently working on, typically within the next 1-3 sprints.
- NEXT – Initiatives your team is going to work on as soon as some items in the “Now” stage are completed (typically within the next 3 months).
- LATER – Initiatives that might fit your current strategy, but have been committed for neither discovery nor delivery work.
Initiatives in each bucket are prioritized from top to bottom (more about that later).
To make the concept easier to digest, let’s take a look at a simplified example implemented with Trello:
Each initiative has its own ticket and is labeled with an OKR and/or theme it contributes to. It can also be helpful to label initiatives as discovery or delivery tasks.
Each ticket should contain the following information in the description:
- 1 Problem to solve (and why)
- 2 Desired outcome when the problem is solved
- 3 Cross-functional input required (design, data, new server setup, etc.)
- 4 Customer feedback and data around the problem
- 5 Ideas how to solve the problem
- 6 EPICS / User stories link to your delivery backlog (e.g. in JIRA)
- 7 Working documents (i.e. links to core documents e.g. KPI outcomes)
The more advanced the initiative is on your roadmap, the more details it should contain. Initially, you only have identified the opportunity that can help achieve one of your OKRs. Then, you’ll collect data and get a deeper understanding of the problem space. Next, you come up with concrete ideas, and lastly, you realize one or several of the ideas. If the idea is a feature, you can add links to the EPICS and/or user stories in your software development tool (e.g. JIRA).
For each initiative check if its completion has cross-functional dependencies and if yes align with the other parties on how to work together on this initiative.
For further inspiration take a look at ProdPad’s current roadmap which is publicly available.
(credit: Tom Lombardo)
Plan Roadmap (Quarterly)
At the end of each quarter align your product roadmap with your OKRs for the upcoming quarter.
Sometimes your roadmap only requires small adaptions while other times it changes almost completely. How much the roadmap changes depends on many factors, such as: how significantly your goals changed compared to the previous quarter, how many small vs. big initiatives you have, how many initiatives you accomplished last quarter, and how good your roadmap is managed and filled with new initiatives during a quarter.
6 Steps to planning your roadmap
Here are 6 steps to set up your roadmap (we will elaborate on them further in the following sections):
- Groom list of product initiatives
- Assign a theme / OKR for each initiative
- Prioritize all initiatives (see below how)
- Assign initiatives to the Now, Next, or Later stage according to their priorities
- Align with your engineering/product team and get their commitment
- Align with stakeholders and get their commitment
For steps 1 to 5, many product teams spend 1 full day together (if possible on an off-site) to plan the first version/draft of their (OKRs and) product roadmap.
Ideally, preparation is happening before (or you allow time for individual brainstorming at the beginning of the workshop), so that every participant is equipped with relevant input and you have more time for fruitful discussions. Examples:
- The product manager brings in relevant discovery opportunities as well as requests from various stakeholders.
- Engineers come with important tech legacy/debt topics.
- Everyone brings in any initiative he or she finds relevant.
Next, initiatives can be discussed, grouped, and prioritized together.
After the workshop, the roadmap is fine-tuned and aligned with all stakeholders. Don’t expect to get your roadmap completely done in one day/workshop. Often you have to clarify details before having a clear picture of some initiatives, get some estimations from your team, and do another round of alignments and adaptations.
Who should attend the workshop?
There is no straightforward answer for it. I’ve seen companies where all product teams and top management participate, but also just the core product team (product manager, designer, engineers). Or certain stakeholders only attend part of the workshop when their input is required.
So there is no right or wrong and you need to experiment to find the right balance for your organization. Typically it’s beneficial to keep workshop teams as small as possible to get things done, which works well as long as you collect input from other stakeholders before the workshop and align with them again afterward.
To get a list of initiatives to consider for your roadmap, you can do the following:
- Update your existing initiatives and see if they are still relevant for the upcoming OKRs.
- Analyze your latest product data and discovery experiments to identify any relevant opportunities.
- Brainstorm about new initiatives (all team members): What does your product need? What would be great to test & build? Any tech debt?
- Screen your discovery and delivery backlog.
- Gather initiatives and requirements from all stakeholders and team members.
A good framework you could use to identify new initiatives is Impact Mapping.
There are many different product prioritization techniques, yet the one that I find most relevant for planning your roadmap is the following:
- Basic requirement: OKR contribution/alignment
- ICE formula: (Potential) Impact (user value as well as business value) * Ease * Confidence
The first aspect is just a “checkmark” to ensure every initiative you consider is relevant for your goals (and thus your product vision).
The second one is the main prioritization technique, called ICE, which was originally invented by Sean Ellis. His formula helps you to identify the initiatives that generate the highest impact with the lowest effort while considering the fact that often we underestimate the effort and overestimate the impact. I recommend reading a blog article from Itamar Gilad to learn more on this topic.
You can calculate the ratings for impact, effort/ease, and confidence very superficial (“subjective” 1 to 5 scale) or very sophisticated (e.g. calculate the business value as estimated future revenue).
Both can work, choose what makes sense for you the most and that you can defend in front of stakeholders, but don’t over-engineer it. Also, keep in mind that the main reason for prioritization is to say NO to as many things as possible.
Before rating the effort of an initiative, add a rough estimation of the time it likely requires to complete (in weeks). For delivery initiatives collect this input from your engineers.
Now allocate your prioritized initiatives to one of your 3 buckets based on your rough estimates:
- NOW: Initiatives to work on in the next 2 – 6 weeks
- NEXT: Initiatives to work on in the 2nd half of the upcoming quarter
- LATER: Initiatives that are unlikely to be worked on next quarter
While allocating your initiatives, take a few things into consideration:
- Ensure a healthy balance between discovery and delivery initiatives.
- Do not assume your teams can spend 100% of their time (= 3 full months per quarter) on initiatives. For instance:
- For delivery initiatives, subtract at least 20% of available engineering time for regular maintenance, bug fixing, and urgent/unexpected work. Find out what this number is in your organization. If it is larger than 30%, you likely have tech legacy and other tech issues that should be resolved at some point.
- For discover teams, mostly product managers like you, keep in mind that you have many responsibilities and you cannot work only on discovery initiatives.
- Take vacation times into consideration, too.
- If you notice that your (mostly engineering) team capacity is not large enough to get important initiatives done (and thus reaching important OKRs is at risk), see if you can temporarily move people from one team to another or hire additional ones. However, simply adding more resources does not necessarily translate into more outcomes (not output), so analyze this decision carefully.
- If you do not have time estimates per initiative, you can also do a rough assessment: Count the number of small/medium/large initiatives your team completed last quarter. Allocate a similar amount of initiatives for the next quarter. (assuming headcount stays the same)
The item at the very top of the “NOW” later is the #1 priority in your company.
Once the roadmap is “ready” from your side, collect feedback, iterate and align it with everyone:
- Can everyone on your team commit to the goal of delivering the initiatives in NOW and NEXT within the next quarter?
- Do your stakeholders agree with and commit to your roadmap or are there disagreements about some priorities or initiatives in general to resolve?
Keep in mind that your roadmap is never really “final”, so there is no need to “get it perfect”. Because no matter how much effort you put into it, 2 days into the next quarter and there can already be a change necessary, no matter how meticulous your planning was.
Thus, on the one hand, a roadmap should be planned properly, but on the other hand, it should be a living document that, at any given time, represents the priorities of your team based on the latest insights you have.
Final tips: For every (quarterly) roadmap update plan enough time for aligning priorities with all stakeholders (e.g. prioritizing initiative A for marketing vs. initiative B for sales) and be super transparent about why you prioritized A vs. B. If 2 stakeholders do not agree on the priority of something relevant for them, put them in 1 room and let them resolve it through a constructive discussion (and act as facilitator).
During the quarter it is easy to get super busy with daily discovery and delivery tasks and neglect updating the roadmap. However, this is important to ensure transparency across the company and it saves you time with the next quarterly planning.
Here is what to do with your initiatives:
- For delivery initiatives with clarity on the corresponding solution(s): Break it down into epics and stories in your software management tool and plan the release.
- For identified opportunities without concrete solution(s): Come up with solution ideas and validate them, document your outcomes. Prioritize again when the next steps are clear.
- For suggested user/business problems: Start with problem research to collect data on whether the problem is worth solving or not, and document your outcomes. Prioritize again when the next steps are clear.
During a quarter you deliver new features, learn new things about your customers, have unexpected changes and opportunities. Thus, it is likely your roadmap needs also adaptations during a quarter.
Consequently, manage priority changes swiftly, align with your stakeholders, unblock stuck initiatives as fast as possible, and constantly take a step back and take a look at the big picture to ensure your team still works on initiatives that have the biggest impact (with the highest level of confidence) on your OKRs and product vision.
A theme-based roadmap will help to avoid endless feature and timeline discussions as initiatives do not have specific due dates. Specific deadlines look like promises to stakeholders and often can’t hold, as it is a prediction of the future that nobody is good at.
If asked by when something is ready, rather use the bucket approach: “This is something we are currently working on” (NOW bucket) or “We are going to work on this after initiative XY is completed” (NEXT bucket).
Almost obvious to say that your roadmap should be visible and transparent to everyone in the organization and progress as well as setbacks should be communicated pro-actively.
Here is one possible way to facilitate cross-functional exchange about the roadmap:
Every 2 weeks, an open and organization-wide stand-up takes place where all product teams gather in front of a whiteboard with the up-to-date roadmap on it. Every owner or contributor of an initiative gives a quick update about it and can address any questions or ask for input. All stakeholders can join the stand-up and thus stay updated about the progress of initiatives that impact their team. Thanks to the theme-based roadmap stakeholder discussions will focus more on outcomes and less on specific delivery outputs (for that product teams have sprint meetings and release plans):
- Roadmap = Manage Outcomes
- Sprint or Release Plan = Manage Outputs