Product roadmapping

When a product doesn’t have a vision, there are 2 possibilities, it:
a) moves to whichever direction the mood might be like at that day
b) doesn’t move at all

So. Chaos or stagnation?

“When there is no vision, products perish”

One popular tool for creating a product vision is roadmapping.
Roadmap is a graphical way of showing where your product is heading to. It helps you to visualize your product vision.

Roadmap is your vision tool
The input to creating a roadmap can come from many other parties (users, developers, designers, CEO, shareholders), but you are the one responsible for putting it together and communicating it.
You’re likely already swimming in ideas from different departments and customers. As a PM, your job is to filter through them and putting together a coherent product plan from them.

What is included in the roadmap?
* High level strategic goals — Use high-level themes. Generalize. Avoid too much detail. This gives you room to maneuver with the solutions. Roadmap is not for listing features.
* Releases by quarters — Be vague about deadlines. Avoid concrete dates in your roadmap. People might treat them as grand ceremony dates and commit to them. Use quarters or ranges instead.
Exception: Use specific dates when you have a hard market-defined deadline, like Christmas.

What’s worth doing?

How do you decide on which elements should be on the roadmap?
a) You can use the table below to list all the candidates for the roadmap
b) Side the candidates with value vs the cost & risk:

b) Assign complexities to each point.
c) Assign risk to each point:

d) Calculate the weighted score for each candidate
e) Map the result to a Valuemap:

Valuemap sections:
Red — Undesirable. Low value, high risk.
Orange — Low priority. Rather low value, considerable risk.
Blue — Strong candidates.

When the company and the product are more established, assigning monetary values using Cost/Benefit/Risk analysis can be a good tool too.

Different parties and departments

Ideally, you’d want to involve each department in your roadmap creation process. For example, the dev team can give good input about technical dependencies which determine the order of some candidates.
You could organize a workshop!
Furthermore, if each department feels that they co-created the roadmap, they’re much more likely to buy into it.

Your role, in any case, is to be the facilitator of ideas and people. You can’t please everybody. To keep your roadmap on focus, you’re gonna have to say “No” a lot of times.

When presenting…
craft your presentation according to what aspect of it the listener(s) need to hear:
Development — Explain what is the long term plan for the product. They will try to figure out what technological decisions they need to make upfront. Management — Explain the benefits and the costs of each release. Marketing and launch plans might also be important to them.
Sales — Explain the selling points to the customer. Knowing the product vision might help them to close deals.

Be clear about how you are making roadmap decisions. This helps to facilitate the discussion around the roadmap — everyone might have their favorite features. The PM should justify why X is more important than Y.

Roadmap building blocks: Features vs Goals

When you think in terms of product features every day, then it might be tempting to create a roadmap from features as well. This inherently makes the roadmap too detailed and too attached to specific solutions. You don’t want that.

Goal-oriented roadmaps help you focus on specific objectives other than just producing features. For example, increasing engagement, acquiring customers or eliminating technical debt. The idea: Goals >Features.
Features are just means to reach the goals. Developing features in itself doesn’t have any value.

In this case, you want your roadmap progress to be measurable. Use metrics to determine if your roadmap goal has been met or not. Example:

Lastly, your roadmap shouldn’t be a wall decoration that you print out once and announce it “Done”. It’s an actively used tool that can be frequently changing. How often your should review your product roadmap depends on how mature your product is:

Happy mapping!