How to Choose the Right Product Roadmap Format

By Roman Pichler, 19th February 2015
Photo by Matt Howard, courtesy of Pexels

A product roadmap is a high-level plan that shows how a product is likely to develop over the next few releases. While that’s true for any roadmap, there is no one right product roadmap format. Instead, you should choose the roadmapping approach that works best for your product. This post shows you how to do it.


Feature-based vs. Goal-oriented Product Roadmaps

Product roadmaps come in different shapes and sizes. But the two most popular formats are probably feature-based and goal-oriented roadmaps. The former are built on product features such as registration, search, or reporting, which are mapped onto a timeline.

Goal-oriented roadmaps focus on goals or benefits instead. Sample goals are acquiring users, retaining them, increasing engagement, activating users, generating revenue, and removing technical debt. Features are viewed as second-class citizen. They are derived from the goals and usually used sparingly.

The following picture illustrates the two different roadmap formats showing two major release, m and n .

Not that independent of its format, your product roadmap should tell a realistic and coherent story about the likely growth of your product. It should execute the product strategy so that each release builds on the previous one moving you closer towards your vision. It should not contain a random sequence of goals or a loose collection of features!


A Sample Goal-oriented Roadmap Format

If you would like to try out a goal-oriented roadmap, then take a look at my GO product roadmap template below. You can download it from romanpichler.com/tools/product-roadmap or by clicking on the following picture.


Choose the Right Product Roadmap Format

While I am biased towards goal-oriented roadmaps, they are not always the best fit. To  select the right roadmap format for you product, consider the maturity of the product and the stability of its market. The younger your product is, the more uncertainty and change are likely to be present. A young product therefore benefits from a roadmap that focuses on product goals. Older, mature products lend themselves to feature-based roadmaps that provide more details. The reason for this is simple: As your product reaches maturity, it experiences fewer changes, and you are in a better position to correctly anticipate its growth.

But your product’s age is not the only driver that influences your product roadmapping approach. If your product is mature but its market segment is volatile, for instance, as competitors keep adding new features or the technologies change, you will have to update your product to defend its market share. As a consequence, uncertainty and change creep back into your roadmap. This makes it difficult to plan ahead in detail and to correctly forecast when which feature will be released. Instead, you are better off creating a roadmap that is built on goals.

Taking into account product maturity and market stability results in the following matrix.

The matrix above captures the maturity of your product on the vertical axis and the stability of its market on the horizontal axis. By distinguishing a young and a mature product and a dynamic and a stable market, four quadrants emerge that help you choose the appropriate format for your roadmap.

I recommend using a product roadmap that is based on goals when your product and / or your market are likely to change. Employ a feature-based roadmap only if your product has reached maturity and the market is stable. This is in contrast to what I see most organisations do: Create feature-based roadmaps even though the product and the market change. Don’t make the same mistake. Use feature-based product roadmaps only when little change and uncertainty are present.

But bear in mind that mature products can change too. You may, for instance, rejuvenate a mature product like Apple has done with the iPod Nano. To keep it attractive, the company has considerably changed the product since its launch in 2005. It has shrunk its size and shape and it has given it a touch screen. You may therefore have to switch from a feature-based roadmap back to a goal-oriented one!

Summary
Article Name
How to Choose the Right Product Roadmap Format
Description
Find out how to choose the product roadmap format that works best for your product.
Author

Learn More

You can learn more about creating an effective product roadmap with the following:

Source: http://www.romanpichler.com/blog/how-to-choose-the-right-product-roadmap-format/

RSS Feed

10 comments on “How to Choose the Right Product Roadmap Format

  1. Ed Russell

    Hi. Great article. When talking about about goals, what do you mean by “activating users”?

    • Roman Pichler

      Hi Ed, activation means activating users, that is, getting people to use a product. It’s the second step in David McClure’s AARRR process: acquire users, activate them, retain them, generate revenue, and get referrals. Hope this helps!

  2. Roman Kleiner

    The distinction between goal-based and feature-based roadmaps is very good, but I’d argue that even with evolving products or markets, there is the occasional need for feature-based.

    For example, a B2B product might have a few enterprise accounts that influence its roadmap.

    Also, the boundary between goal-driven and feature-driven may become blurred; for example, there are a couple of strategic goals (e.g. rework our reporting system), but then there are a couple of tactical features added in: an 80/20 split.

    • Roman Pichler

      Hi Roman, Thanks for your comment. My rule of thumb is: Whenever uncertainty and change are present, I prefer to use goal-oriented roadmaps; otherwise feature-based ones work fine. Hope this helps.

  3. Svetlana

    Hi, Roman. Thank you for the article. It made me think a lot about what kind of goals should I chose for goal based approach to roadmap.
    Should it be smth like “Create functionality for users on-boarding”? Or “Increase number of active users by 20%” ? Second option sounds a little bit confusing for me. What if we don’t achieve it by the deadline?

    • Roman Pichler

      Hi Svetlana, Thanks for your feedback. I would choose your second example as the goal. The first one sounds more like a feature or a deliverable that is required to meet the goal.

      If you struggle to meet the goal, then explore if partially meeting it is acceptable. If not, you will have to increase the budget or push out the date. But that’s the same for working with a list of features: If you must deliver all features but struggle to do so, then you have to flex either time or cost. (Quality should be fixed assuming that you want to be able to adapt your product quickly in the future.)

      Does this help?

  4. Mohammad Nafees Sharif Butt

    Some teams make the mistake of coming up with a sprint goal after they have selected the highest priority stories that they would like to take up in a Sprint. It is an anti-pattern and result in lack of direction and focus from the team (and a sprint goal that is punctuated with lots of “… and …. and ….”). The same anti-pattern exists at a macro level if product owners start with feature-based product roadmaps instead of goal-oriented product roadmaps.

    In my opinion, avoiding the anti-pattern at sprint level is relatively easier. However, even i find it difficult at times to manage the diversity of incoming requests and trying to put one of them to a hold because my prodcut is going to have a goal-oriented roadmap and this release won’t have any of the competing requests.

    • Roman Pichler

      Hi Mohammad,

      Thanks for your comment. As I have argued in my post, there is no one right roadmap format. If your product is mature and the market is stable, then a feature-based roadmap can work well. Similarly, once you have addressed the risk relating to a specific major release and now focus on completing features and optimising the product, then forming a sprint goal based on high-priority product backlog features can be effective. As a rule of thumb, look at the product lifecycle to get the roadmap right and the project lifecycle to do the same thing for your sprints.

  5. Martin Kardzhiev

    Great article. However, goals need to be SMART (http://topachievement.com/smart.html). If goals are vague, they don’t bring the same value.
    Retaining customers sounds like a goal but on the other hand there’s nothing specific within it.

Leave a Reply

Your email address will not be published. Required fields are marked *