Avoid roadmapping pitfalls by focusing on problems, not solutions
Thematic roadmapping, in practice
The daily struggle for product managers is answering one single question posed by executives, PR, marketing, sales, and customers: “What’s next?”
Instinctively, you believe a roadmap is the solution. But it hasn’t always worked out in the past. How many have actually helped the organization? How many have just blown up in your face?
Thematic roadmapping as a starting point
I first came across thematic roadmapping through Jared Spool’s article in UIE about Bruce McCarthy’s original idea of themes.
Unfortunately, the traditional roadmap is a poor way to set expectations and understanding with these teams. Bruce McCarthy has a lot of thoughts on why they fail including this great list of problems. The top ones are:
- No strategic goals — you should be linking your day-to-day work with the high level strategy of your organization rather than purely reactive work.
- Focusing on features — it is all about delivering value rather than specific features when communicating the future of your product.
- Inside out thinking — your roadmap should be focused on how you are building for your customers not what you think is best internally.
From these problems Bruce came up with an alternative that addresses many of the issues. You should definitely read this. It changed how I thought about roadmaps and made them make a lot more sense.
I haven’t found much about thematic roadmapping after some posts in 2015. When I have talked about this multiple times in the last month I knew there was a need to revisit.
Updates to thematic roadmapping
The key is that you are no longer giving roadmaps with specific dates and particular features. Themes are real customer problems collected to be attacked on a per sprint basis.
A service like Netflix may have themes that are focused on viewers watching something they will be entertained by as soon as possible. Good themes could be “viewer can’t find a half watched show they watched last” or “viewer isn’t able to restart a show from the beginning.” They identify problems that are key to a fulfilling their mission, it isn’t focused on how these problems are solved before they need to be, and they are focused on real problems that people have.
In addition to the thematic roadmapping basics, I have found a few other practices helpful:
- Simple horizons of ‘now,’ ‘next,’ and ‘later’ — we don’t need timeframes just expectation setting on what order we work on our themes.
- Higher likelihood of happening as we move the theme from ‘later’ to ‘next’ to ‘now’ — we need to set the expectations low for items that aren’t being considered right now.
- Higher confidence it is important as we move it from ‘later’ to ‘next’ to ‘now’ — as we increase our confidence that a problem is worth solving we move it closer to now. It isn’t necessarily that it is confidence in how to solve but only that we really need to solve it.
- More WIP as we move out — we shouldn’t turn the roadmap into an idea parking lot, only the highest priority themes should be on it.
- Limited life — themes shouldn’t exist forever they should be cycled through.
- No dates, unless they are really important — marketing, PR, and other big bang dates can be on this as a marker but you shouldn’t put dates on anything else.
- Uses personas — always focus down to a particular persona or JTBD for the problem.
If you adhere to these rules you will find that your roadmap will be simple and easy to understand and powerful when describing what to do next.
It can be done in Trello and look something like this:
In a Google Sheet it can look like this:
You can get both the Trello board template and Google Sheets template and copy it for yourself.
How to create a good theme
The original article does a great job talking about what makes a great theme: it is something that is “solving a specific customer problem.” They shouldn’t be epics either. They aren’t just random collections of features. They are important problems in their own right.
Let’s look at a good theme we identified earlier for the hypothetical Netflix roadmap: “Viewer can’t find a half watched show they watched last.”
It is good for a few reasons:
- It is a problem that doesn’t presuppose a solution. There are many different ways to allow a half watched show to be selected and viewed.
- In this case it is meant to be a highly important aspect to the frustration of viewers that stop watching something before it is done.
- There are personas (or a type of job) with the “viewer” to know who is impacted.
- It is (probably) scoped enough to be handled in a release or two. That being said, it could need to be split if certain aspects, like double-tasking this for going to the next episode in a series isn’t right to handle in this theme.
Just like great user stories need acceptance criteria I have found that great themes have good hypothesis on why they are important. You don’t want to get down into the details of themes until the team is ready to work on them but you don’t want to go into a theme without an understanding of why it exists.
Middle to later stage organizations will have a lot of knowledge of the problems their customers have. From this list of personas and their problems you can create well scoped problem themes.
However, for earlier stage startups, it may be more helpful to write the themes as experiments you are running. It could even be as simple as understanding whether you can even do the basics of your business model (e.g. ‘can we get buzz at a conference we are attending?’).
Theme anti-patterns
There are a few traps that people can fall into when thinking about themes though. The biggest culprits are those that will stick around for longer than a few sprints.
First, themes can be too broad in the problems that they are trying to cover. They should be small enough to fit within a sprint (or two) in your current framework. If there is a lot being considered break it up and prioritize it. A theme for our fictitious Netflix roadmap would be “Viewers should have a great viewing experience.”
Second, those that are goal or metric focused are bad. When you have a KPI it is your organization’s job to constantly optimize it. You need to get down to real problems that are scoped at a few sprint level. An example would be “Viewers should increase their hours watched by 20%.”
Third, various maintenance themes like ‘bug fixing’ that never end and never really change are bad. Yes, of course, you will need to take on important bugs but you shouldn’t just park a theme there. I find it hard to believe that the hypothesis is well enough scoped that it is always being worked on. Also, I have found that it tends to be psychologically harmful to teams when something is always there looming in a roadmap. Please don’t create themes like “Review latest live driving and create simulations.”
Finally, the last anti-pattern is that they are just ideas. The thematic roadmap isn’t a place to collect ideas from stakeholders or to be used as an ‘icebox.’ They are more than welcome to keep them in an idea log (say in Google Docs) but everyone’s ideas aren’t what you as a product person are meant to manage. This would be as if people said we should consider “how to include a more social experience for viewers.”
Co-creation with stakeholders for the win!
One mistake I see a lot of product people make is build the roadmap by themselves and present to managers, executives, and stakeholders with a ‘ta da!’ This doesn’t prepare you for success.
Ideally, you should do the legwork to pull together the right themes into a “to be considered” column (see the templates above). These are the themes that you think are important and present the structure to your stakeholders when starting the discussion. Until you talk with them keep the structure and the list of themes separate.
Discuss the pros and cons of different orders. Place them together.
When updating the roadmap it is a good idea to change it with your executives and stakeholders as well. These are the people that need to know and buy in to the changes as they happen.
When a theme gets to ‘now’
Generally when you are preparing to take on a sprint you should pull a few high importance themes from the ‘next’ column into the ‘now’ column. Talk to the team about it. Get their thoughts.
When they accept the themes as those for the sprint then you should create the work items, not before. And you should do it with the whole team. I find that a few minutes of private work creation based on the current themes is way more likely to get all of the important stuff written down to meet the theme.
New processes are new experiments
None of this is new but it is maybe put together in a new way. In fact, there are no perfect processes just those that work for your team.
What is most important is that you try out processes for your organizations as experiments in themselves. You should be constantly doing retros to see how to further adapt process to your teams.
Roadmapping will always be a process that is difficult to get right with so many uses and users. I have found that in the majority case what you need is to focus on the problems you are solving, not the solutions.
