How to build a simple and agile roadmap
Roadmaps that look too far into the future are a waste of time. For startups it's impossible to accurately predict what will work or what customers will want a year in advance. There's a better way.
Roadmaps are a waste of time.
I’m talking about long roadmaps organized in Gantt Charts or roadmaps looking too far into the future. Roadmaps that tightly align all tasks to specific start and end dates are often outdated as soon as they're shared with a startup’s team. This is because for startups who operate in an uncertain environment it's impossible to accurately predict what will work or what customers will want a year in advance.
Instead, I recommend using a yearly rolling roadmap that is continuously prioritized, planned, and reviewed every 6 weeks.
This type of roadmap is divided into five sections: Review, Now, Next, Later, and Open.
Review: this section is for evaluating recently launched roadmap items.
Now: this section represents the current 6-week period of work.
Next: this section outlines the plan for the following 6 weeks.
Later: this section includes items to be worked on at a later time.
The Open section is where ideas and initiatives that haven't been prioritized yet are kept.
By working with this type of roadmap, teams can prioritize and plan their work in a more agile way, focusing on the present while keeping an eye on the future. Every 6 weeks, the team can review progress and make tactical plans for the upcoming Next section.
Why is this better?
Working with product horizons can be more effective than using complex far in the future looking roadmaps for several reasons:
Simplicity: Product horizons are a simple, easy-to-understand way of organizing product development efforts. They provide a high-level view of what needs to be done and when, without getting bogged down in the details.
Flexibility: Product horizons are more flexible than complex Gantt charts, which can be rigid and difficult to modify. The "now, next, and later" framework allows for changes in priorities or unexpected events without requiring a complete overhaul of the plan.
Collaboration: Product horizons can be a useful tool for facilitating collaboration and communication among team members and stakeholders. The simple framework allows everyone to understand what's happening and what's next, making it easier to align priorities and work together toward common goals.
Information, a good agile roadmap should contain
Initiatives and Epics
To get started, you should create initiatives and epics. Epics can be part of an initiative, but they can also be standalone items on the roadmap, and not necessarily a part of a larger initiative above it. The initiative or epic description should be brief and easy to understand for external readers. It should be concise yet informative, allowing anyone to quickly scan the roadmap and understand the focus of the initiative.
An initiative is a big bet or opportunity that spans from 2-12 months. An epic has a smaller scope than an initiative, and a collection of epics forms an initiative. Epics can be completed within 6 weeks, from ideation to delivery.
Milestones
Milestones are crucial for each initiative. They allow you to break down larger initiatives into smaller items and track progress over time. Without this breakdown, initiatives may remain stagnant and feel like no progress is being made. It's important for the team to plan their work based on milestones or Epics, rather than solely focusing on the larger initiative.
Example for milestones
Kick-off
Problem discovery
Solution discovery
Implementation Milestone 1
Implementation Milestone 2
Release on testing environment
QA
Release on live
Detailed initiative/epic description
To understand why we want to pursue an initiative, we must first answer a series of questions. I strongly recommend addressing the following questions, which are primarily drawn from Reforge's feature map template and augmented with other valuable information pertaining to initiatives.
It's important to note that the feature map places greater emphasis on identifying the problem or opportunity rather than the actual solution, which may not yet be fully defined.
Target description: Qualitative description of what target segment/customer/user group this feature designed for
Target size: Estimated % of our active user base our target segment represents
User problem description: User problem that this feature solves
User Problem Frequency:How often the target user experiences the problem the feature is designed to solve
User Problem Severity: How important is the problem to target users
Business Impact: Impact of the initiative on the strategic benefit it is attributed to.
Strategic Importance: Importance of feature to the product’s value proposition
Hypothesis: If/Then/Because we observed
Solution: A high level description of the solution or multiple possible solutions
Benefit
The benefit is a core component of a product strategy. Its description should summarize how the initiative will delight customers or outperform the competition, build the feature in a way that is difficult to replicate, and align with the product strategy in a way that enhances margins. This will help the team understand the significance of the initiative and its intended impact on the product and customer base.
Team and Owner
It is important to assign only one owner and one team to drive an initiative to avoid unclear responsibilities and ensure accountability for its success. The team field should indicate the responsible team, and the person field should specify the owner, typically the Product Manager. This will help streamline communication and decision-making processes.
Status
The status of each item on the roadmap is critical to track.
Not started:
the work is not started
Discovery line up:
This status is limited to items in the "Now" section. An item is placed in the discovery line up, if you intend to commence its discovery within the current six weeks, but have not yet begun work on it. The discovery of this item is meant to start within the current six-week cycle, although it may take longer than six weeks to complete.
Delivery line up:
This status is also limited to items in the "Now" section. An item is moved to the delivery line up when we intend to begin work on its discovery within the current six weeks but have not yet commenced. The delivery of this item is meant to start within the current six-week cycle, although it may take longer than six weeks to complete.
Discovering problem:
This status is also limited to items in the "Now" section. An item with this status is in progress, someone is working on discovering what the problem is that you want to solve.
Discovering solution:
This status only applies to items in the “Now” section. An item with this status is in progress, someone is working on discovering and defining the solution.
In delivery:
This status only applies to items in the “Now” section. This status is applied when someone is working on implementing the solution.
Review:
This status is applied to items, which were launched and are being monitored and analyzed.
Done:
This status only applies to items in the “Review” section. The work is done, the analysis of this item is done, it can be closed.
Progress
This field provides information about the status of the progress of an initiative in %. Ensure that the progress is regularly updated at a frequency of at least once every two weeks. You can accomplish this by incorporating it as a recurring agenda item during your product team meetings. It is important to share significant updates with relevant stakeholders to keep them informed and engaged with the progress.
Date
It is required to specify the start and end dates for initiatives, with high precision for those included in the "Now" section.
For initiatives in the "Next" section, the dates can be less precise, and for those in the "Later" section, they are merely indicative and highly unreliable.
When an initiative is listed in the "Now" section, its due date must be treated as a commitment, and it is crucial to be transparent with stakeholders about it. If the due date needs to be modified, it is essential to inform everyone involved promptly.
RICE
The RICE prioritization model is a framework used to prioritize projects or features based on four factors: Reach, Impact, Confidence, and Effort. Make sure to clearly define the scale for each one of them, so your rating is actually comparable.
Reach refers to the number of customers or users who will be affected.
Impact is the magnitude of the change or effect of the initiative on the strategic benefit it is attributed to.
Confidence is the level of certainty that the desired outcome will be achieved.
Effort is the resources needed to complete the project or feature.
The scores for reach, impact and confidence are multiplied together and divided by the effort to give a final prioritization score, allowing for a data-driven approach to decision-making.
Score = Reach x Impact x Confidence / Effort
The RICE framework should be exclusively used for initiatives in the “Next” section, as they are the potential candidates for the upcoming six-week period, and it aids in determining their priority. There is no point to prioritize initiatives in the Later or Open section, because you might not know much about these initiatives in order to be able to accurately prioritize them.
Views
When creating a roadmap, it's important to consider the different stakeholders who will be using it and tailor the views accordingly. Different tools offer the ability to build different views. Here are some useful proposals for useful views:
Overall List: This is a list which contains all initiatives without any filters.
Management roadmap: This is a list which only contains initiatives, all epics all filtered out. This view is relevant for your management so you are able to focus their attention on the most important initiatives the management cares about.
Board: Shows initiatives by status
Timeline: If you stakeholders demand from you to put your roadmap on a timeline, you can do that by following the hints in the “Date” paragraph.
Takeaways
Long, detailed roadmaps with specific start and end dates are often a waste of time as they quickly become outdated and do not allow for changes in priorities or unexpected events.
Using a yearly rolling roadmap divided into five sections - Review, Now, Next, Later, and Open - allows for a more agile way of prioritizing and planning work while keeping an eye on the future.
Product horizons provide simplicity, flexibility, and facilitate collaboration and communication among team members and stakeholders.
An agile roadmap should contain initiatives and epics, milestones, a detailed initiative/epic description, target description, user problem description, solution, benefit, team and owner, and status.
The status of each item on the roadmap is critical to track, and it is important to keep the stakeholders updated. You can facilitate transparency towards stakeholders by giving them access to your roadmap and building stakeholder specific views.