Avoid Roadmap Pitfalls By Focusing on Problems, not Features

One of the daily struggles that product managers are going through is answering one single question posed by executives, PR, marketing, sales, and customers.

“And now, what’s next?”

You hear that a lot. Instinctively, you might believe that maintaining a roadmap will help you have an answer anytime you hear this question.

Why roadmaps matter?

Every company primarily has two finite resources: cash and time. Budgeting defines what the company feels is important enough to spend cash on. In a tech company, the roadmap is a document that articulates what we feel is important as measured by time spent. As such, a product roadmap can be one of the clearest statements about how a company plans to win, which is extremely important for aligning the rest of the organization. This impacts not only the product and engineering teams but aligns all functions in an organization around the top priorities.

Roadmaps usually describe features the team commits to ship over the next few releases. For most organizations, everything revolves around the roadmap.

Marketing uses the roadmap to plan the stories they’ll tell to entice new customers (and get existing ones to upgrade). Customer support uses it to ensure reps are trained to help with new features. And, of course, product development uses it to allocate resources and to speed future development.

But, did roadmaps always worked out in the past? How many have helped the organization and how many have just blown up in your face?

Traditional (feature) roadmaps are a poor way to set expectations and understanding with stakeholders. The top reasons why they fail include:

• 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.

A good product roadmap doesn’t constrain the creativity of the product team to solve problems, it doesn’t limit iterative learning and it doesn’t lock the organization into dated deliverables.

Thematic roadmapping as a starting point: A Promise to Solve Problems, Not Build Features

Themes are an alternative for features. Instead of promising to build a specific feature, the team commits to solving a specific customer problem.

Themes help teams stay focused without prematurely committing to a solution that may not be the best idea later on. This is particularly important for roadmaps that go out 2, 3, or more years into a fuzzy future.

The viability of a feature may shift dramatically, while the nature of an important customer problem will likely remain the same. As each part of the roadmap gets closer, the customer problems often become clearer, making solutions easier to find.

Here’s an example:

A typical roadmap feature might be a data export capability to some CRM. Customers may have even asked for this feature, with a promise to purchase more licenses if the product had it.

With themes, the product strategy team would research why customers want to move their data to their CRM. How does it make their life easier? Might it be even better if the integration were bi-directional, so the data could move in both directions? How up to date does the CRM data need to be? What happens after it gets into the CRM? What’s the bigger problem that needs solving by the customer with this integration?

By understanding how having the data exported to CRM contributes to solving a bigger problem, the team may uncover interesting alternative solutions. Maybe the CRM just plays as an intermediate stop along the way to becoming something bigger? If so, maybe there’s functionality the team could add to the product, or might already exist but is currently hard to find?

When a team has a clear definition of a problem, solutions are often easy. Usually, the biggest source of trouble with defining solutions comes from unclear problem definitions. By making the problem the centerpiece of the strategy, more resources will be available to help with definition.

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 Prime Video 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 fulfilling their mission. It isn’t focused on how these problems are solved before they need to be, and they are focused on the real problems that people have.

In addition to the thematic roadmapping basics, there are 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 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.

How to create a good theme

A great theme 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 Prime Video 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.

By analogy to why user stories need acceptance criteria, great themes need to have a 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.

For mature organizations that possess a good knowledge of the problems their customers have, the list of personas and their problems will help create well problem-scoped themes.

For startups, it will be more helpful to write the themes as experiments you are running.

Thematic Roadmapping anti-patterns

There are a few traps that people can fall into when trying themselves to thematic roadmaps.

Themes that are too broad in the problem are bad

Example: “Viewers should have a great viewing experience”. Themes should be small enough to fit within a sprint or two. If needed, break it up and prioritize it.

Themes that are goal or metric focused are bad

Example: “Viewers should increase their hours watched by 20%”. When you have a KPI, it is your organization’s job to constantly optimize it. You need to get down to real user/customer problems, that are scoped at a few sprint levels, no more.

Themes that never end and never really change are bad

Example: “Review latest live driving and create simulations”. You will need to take on important bugs but you shouldn’t just park a theme there. Not only it’s unlikely that the hypothesis is well enough scoped that it is always being worked on but it also tends to be psychologically harmful to teams when something is always there looming in a roadmap.

Themes that are just ideas or questions are bad

Example: “how to include a more social experience for viewers”. The thematic roadmap isn’t a place to collect ideas from stakeholders. Ideas belong to the idea log and everyone’s ideas aren’t what you as a product person are meant to manage.

Thematic Roadmapping best practices

Co-create the roadmap with stakeholders works best!

A lot of product managers make the mistake to build the roadmap by themselves and present it to their managers, executives, and stakeholders. This doesn’t prepare you for success.

Instead, ensure you do the legwork to pull together the themes into a “to be considered” column. These are the themes that you think are important.

Discuss together the pros and cons of different orders and arrange the themes together in the different columns of the roadmap.

Because your executives and stakeholders are the people that need to know and agree to the changes as they happen, it’s a good idea to update the roadmap with them too.

When a theme gets to “now”, prepare the sprint with your team

Usually, it’s when you are preparing to take on a sprint that you should move a few high importance themes from the “next” column to the “now” column.

Talk to the team about it. Get their thoughts. Really.

When they accept the themes as those for the sprint, then only you should create the work items, not before.

The creation of the work items should be done with the whole team, or at least the “three amigos”.

Three amigos refers to the primary perspectives to examine an increment of work before, during, and after development. Those perspectives are:

• Business – What problem are we trying to solve?
• Development – How might we build a solution to solve that problem?
• Testing – What about this, what could possibly happen?

The concept of three amigos intends to balance between no collaboration between people with different perspectives and involving an entire team in discussing all the details of every increment of work.

Generally, a few minutes of collaborative 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

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. Run retrospective meetings regularly to see how to further adapt the process to your teams.

Roadmapping is a process that not trivial because it has many uses and receives a great deal of interest from various stakeholders. In the majority case, it will ease the roadmapping if you focus on the problems you are solving, instead of the solutions.