Every now and then I get asked how to best organise a product roadmap, and how to execute on it. I’ve been asked frequently enough to publish my suggestions here in this post.
Product management with “advanced common sense”
One of my all time favourite terms is how David Allen summarised his Getting Things Done approach for personal productivity: “advanced common sense”. It shows that an approach that works doesn’t have to be complex. In fact, maybe it mustn’t. A working method can just be common sense — or a slightly advanced form of it.
The same applies to managing product roadmaps. The organisations I’ve encountered so far, in practice sooner or later converge to two types of iterative process:
- Execution of product development with Agile. Frequently, Scrum is used. Sometimes Kanban.
- Organisation-wide quarterly planning for higher level goals. (e.g Q1 2019 from Jan to Mar etc.)
Hence it makes sense to structure a longer term product roadmap into calendar quarters. And to execute the implementation of the items in the current quarter with Agile, e.g. Scrum.
The topology of a quarterly product roadmap
A quarterly product roadmap can be represented quite easily in table format. Along the horizontal axis there is a column for each quarter. Typically you may want to represent 3–6 quarters, including the current one. For items that are beyond the number of quarters you represent, you can add one more column, for example for the next year, or simply “later”. Along the vertical axis you can add a row (or “swimlane”) for each product line or functional area. Imagine the product roadmap for a blockchain-based real-estate marketplace. With the above structure could look like this:
Now just add an item for each key activity. There should be at most a handful of items per quarter and track. I recommend to order them by priority in each track — items that are higher within each cell have higher priority.
You can implement a roadmap like this simply in a spreadsheet, or you can use a dedicated product such as shipit. The advantage of a dedicated product is that it integrates additional functionality, such as a short description for each item that shows on mouse hover, and a bunch of additional helpful features and integrations.
Planning and prioritising the roadmap
You use the roadmap with a “rolling” quarterly planning approach. When you approach the next upcoming quarter you plan it in detail. When a quarter completes you remove it and add one more at the end of the roadmap. Items can be slotted into any cell at any time (except for the current quarter — it should be considered “locked”).
Here’s an example: suppose it’s early June 2019. You are about to complete Q2 2019, and need to start planning Q3 in detail. These are the steps you would typically carry out:
- Check on status of Q2 items. Some of them may rolll over to Q3.
- Do an initial pass over the items in Q3 and verify if all of them are still relevant. Move those that aren’t.
- Check future quarters to see if anything should be tackled in Q3 instead.
- Do an initial ranking by priority for the Q3 items in each track.
- Discuss the draft of the Q3 priority list with your organisation’s stakeholders. Ask them for their input regarding priority of the items. Reprioritise as needed.
- Do a prioritisation and cleanup pass over future quarters.
- As Q3 approaches or starts communicate the key roadmap activities for Q3 to the teams, and give an update and outlook on the future quarters.
Quarters have a “comfortable” size: they are long enough to allow for making significant progress on major items. They are short enough to constrain the work and be able to “see the horizon” within that timeframe. They are a good timeframe to set some high level (product) goals and rally the teams round them. This applies to the current and the upcoming quarter.
Beyond 4 quarters (a year), planning and giving reasonable time estimates gets typically much harder. Just having a bucket for the next year or “later” in order to capture further out items addresses this inherent uncertainty in a pragmatic way.
With the above approach, the level of detail and certainty is high in the near term and low for things that are further out. This is exactly what you want to have.
Quarters and Sprints
The focus of the current quarter is on execution. The items on the product roadmap give only a high level direction and high level goals. Detailed planning and execution, and making sure to deliver value to the customer in frequent increments is the role of Agile process.
Within the current quarter you can easily apply Agile, for example Scrum. If you are running for example 2-week Sprints, you will have about 6 sprints to execute on the roadmap priorities for the current quarter. You may want to attack them by priority, but typically 2 or 3 may run in parallel, depending in your team size.
Is this still Agile?
As you can see from above, the quarterly roadmap planning approach integrates nicely with Agile execution. But is such a longterm planning and roadmap still truly Agile? I would argue it is complementary. In fact, one key-criticism of Agile/Scrum is that it lacks the longterm perspective. A simple quarterly roadmap as introduced may address this criticism.
At the same time the process is not expected to inhibit the key premise of Agile: being able to deliver value to the customer and to adapt and react based on feedback. The roadmap gives only the high level direction. Any details of the features for each item are carried out exactly in Agile fashion.
Furthermore, the product roadmap will only list “major” initiatives. Smaller features and increments will not be listed explicitly but just handled in your regular Agile process and ticketing system. For example with user story tickets in Jira or Trello. Often times an item on the product roadmap may link to an Epic in your Scrum, or Jira respectively.
From an organisation perspective the product roadmap can be seen as the (often missing) layer or link between vision and daily execution:
- Company or product vision: sets the course for multiple years
- Product roadmap: sets the course for months up to a year
- Agile / Sprints: sets the course for days to weeks.
Ideally all these levels should be connected so your team understands how the current sprint’s work relates to the product roadmap, and how the product roadmap in turn releases to the company or product vision.
In a next post we will talk about another important aspect of communication your product plans to your team and stakeholders: product requirements.