Tag Archives: product roadmap


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 and show when which goal will be met. Sample goals are acquiring customers or users, retaining them, increasing engagement, activating users, and generating revenue. 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.

The GO Product Roadmap

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!

Learn More

You can learn more about creating an effective product roadmap by attending my Agile Product Strategy and Roadmap training course. Please contact me if you would like to have the course delivered onsite or in form of a webinar.



Product Roadmap vs. Product Backlog

The product roadmap is a strategic product-planning tool that shows how the product is likely to grow across several major releases. This creates a continuity of purpose, facilitates stakeholder collaboration, helps acquire funding, and makes it easier to coordinate the development and launch of different products.

I prefer to work with a goal-oriented product roadmap that clearly states the benefits provided by each major release, particularly in an agile, dynamic environment. You can download my GO product roadmap template from romanpichler/tools/product-roadmap where more roadmapping information is available.


The product backlog contains the outstanding work necessary to create a product including epics and user stories, workflow diagrams and storyboards, user-interface design sketches and mock-ups. It is a tactical tool that directs the work of the development team and that provides the basis for tracking the project progress in Scrum. The following diagram summarises the main differences of the two roadmap and the backlog.


Applied correctly, the two tools complement each other nicely. The product roadmap provides an umbrella for the product backlog; it tells a longer-term story about the likely growth of the product whereas the product backlog contains the details necessary to create the product.

To successfully employ both tools, you have to decide if your product backlog should be derived from your product roadmap or the other way round. Let’s have a look at the two options and discuss when they are appropriate.

Option 1: Derive the Backlog from the Roadmap (Top-down)

Your first option is to derive your product backlog from your roadmap. This assumes that you have a product roadmap available and that the roadmap provides you with a helpful input for your backlog such as a product or release goal and some features.


If you choose this option then I recommend that you focus your product backlog on the next product version or the major release, as the following picture illustrates.


This shifts the longer-term planning work to the roadmap and it results in a concise, short product backlog, which is comparatively easy to create and to update or “to groom”.

Option 2: Derive the Roadmap from the Backlog (Bottom-up)

Your second option is to derive the product roadmap from your product backlog. This assumes two things: First, you have a fairly long product backlog whose items cover more than the next release. Second, the backlog is stable enough to serve as an input for the roadmap.


To employ this option, look through your backlog and identify common themes. Group the themes and assign them to major releases. If you use my GO product roadmap then you should also consider the benefit (or goal) of providing each release and you should state the appropriate metrics to determine if the benefit is realised. The picture below illustrates this approach.


While your product backlog might still cover the same timeframe as the newly created product roadmap, the latter provides you with a high-level view of the likely growth of your product. This makes it easier to collaborate with the stakeholders including marketing, sales, service, and other business groups.

Top-down or Bottom-up?

To select the right option for creating your product roadmap and your product backlog, take a look at the lifecycle stage of your product. If your product is still changing significantly as you are, for instance, developing a brand-new one or you have recently launched the first version, I recommend that you first create your product roadmap and then derive your product backlog from it. In other words, as long as you have not achieved product-market fit and your product does not yet satisfy the customer and users needs well, you should employ a top-down approach.


If your product is stable and you have achieved product-market fit, you can consider using your backlog to create the roadmap.


Bear in mind though that markets can unexpectedly change and cause products to loose their market fit. I therefore recommend applying the top-down approach as the default or norm. In doubt, derive your product backlog from the product roadmap.

Roadmap and Backlog Ownership

As the product owner or product manager, you should lead the strategic and the tactical product decisions. You should therefore be responsible for the product roadmap and the product backlog. In an agile context characterised by uncertainty and unexpected change, the strategic product decision do not only influence the tactical ones, but the product details can significantly impact the product strategy. Customer feedback on a product increment can, for instance, cause a strategy change (pivot), which is likely to invalidate the product roadmap.

But you should not be the only person working with the roadmap and the backlog. The development team and the stakeholders, as the following picture illustrates.


Use the roadmap as the primary tool to achieve stakeholder alignment, to agree on the overall product direction, and the go-to-market strategy (that is, when which features are released). Use the backlog to decide on the product details including the user interaction, the product functionality, and the visual design. The conversations with marketing, sales, service, and the other business groups about the product direction and the product goals should therefore happen in the context of the product roadmap rather than the product backlog.

Learn More

You can learn more about working effectively with an agile product roadmap by attending my Agile Product Strategy and Roadmap training course. You can improve your product backlog practices by participating in my Certified Scrum Product Owner training course. Please contact me if you are interested in having the courses delivered at your office.


Step 1: Do the Prep Work

Before you create your GO product roadmap, you should carry out the necessary problem validation work. Investigate the target group, the problem to be solved, the business goals, and the technical feasibility of your product. The Vision Board, the Business Model Canvas, and the Lean Canvas are great tools to capture and validate your ideas.


To see how this can work in practice, take a look at the Vision Board below. The board captures the idea of creating a digital dance game together with the intended audience, the benefits, the key features, and some aspects of the business model:


Step 2: Build the Roadmap

The Vision Board, Business Model and Lean Canvas are helpful tools to describe the market, the value proposition, and the business model. But they not tell us how the strategy will be executed. Will the first product version deliver the entire value proposition and generate the desired business benefits, for instance, or will this take longer? Say we focus the first version of the dance game on user acquisition. While this is a necessary step towards the vision, it does not answer the question when revenue will be generated. This is where the GO roadmap comes in.

I used the Vision Board above to create the roadmap shown below. You can download a PDF and Excel template by clicking on the picture.


The roadmap above takes the Vision Board contents, and shows how the strategy is executed over the next 12 months. It states the planned major releases with their goals, key features, and metrics. Version 1, for instance, is focussed on user acquisition, version 2 on activation and revenue generation. Version 3 is about retaining existing users, and version 4 targets a new segment and tries to acquire new users. (I discuss in more detail in my post “The GO Product Roadmap”.)

Your roadmap should tell a coherent story about how the product is likely grow: Choose the goals carefully and consider their relationships.

Which timeframe your roadmap should cover and how often you want to create a major release / new product version depends on your product. You should be reasonably confident about your roadmap and avoid speculation. You can regard the roadmap goals as hypotheses, but they should be informed assumptions, and not wild guesses.

If you cannot look further than the next release, then do not employ a roadmap!

Step 3: Derive your Product Canvas/Backlog

With your GO roadmap in place, you can now take the next step and use the product roadmap to stock your Product Canvas or product backlog. The GO roadmap provides you with the goal for the next major release, the two to three key features, and the metrics, which are a great starting point for discovering the product details including the user journeys, epics, the visual design, and the nonfunctional requirements.


The GO roadmap connects the Vision Board / Business Model Canvas to the Product Canvas/backlog; it links market insights and business model with the product. What’s more, the roadmap allows you to focus your Product Canvas/backlog on the next major release, which results in a smaller and more manageable canvas/backlog that is easier to change and update.

Step 4: Pivot or Persevere?

The process I have suggested so far sounds rather sequential: Do some problem validation work, then build the roadmap, and derive the Product Canvas to develop the product. This may give the impression that the GO product roadmap is a fixed plan that simply has to be executed. But the opposite is true.

Whenever we create something new – be it a brand-new product or new features – the one thing we can be sure of is that our initial ideas don’t work out as planned. As you collect feedback from users and customers on your prototypes, product increments, and MVPs, you should always ask yourself if your product strategy is still valid.

Say we expose an early prototype of the dance game to a test group. But unfortunately, we have to recognise that the kids are less excited by the game and playing it much shorter than anticipated. This data should make us rethink our strategy by asking ourselves if our market assumptions (segment and problems/needs) are wrong or if the user experience provided by the product is adequate. In both cases we have to pivot and change the strategy together with the product roadmap, as the following picture shows.


Note that the picture above assumes that the Vision Board / Business Model has to be changed in addition to the roadmap. That’s not necessarily true if the UX or features of the product are inappropriate but the market and business model-related assumptions are valid.

Be prepared to throwaway your existing GO product roadmap and to create a new one.

To minimise any rework, do the necessary problem validation work recommended in step one, and keep your product roadmap focussed and concise. The more details you add the more attached you become to your roadmap, and the harder it is to let go.

Once you have reached product-market fit and are confident that you are building the right product for the right people, I recommend you review and adjust your roadmaps on a regular basis, for instance every two months, as part of your portfolio management process.

Learn more

You can learn more about working with the GO product roadmap by attending my Agile Product Planning training course.

Please contact me for product roadmap workshops and webinars.


A product roadmap is a high-level, strategic plan, which provides a longer-term outlook on the product. This creates a continuity of purpose, and it helps product managers and owners acquire funding for their product; it sets expectations, aligns stakeholders, and facilitates prioritisation; it makes it easier to coordinate the development and launch of different products, and it provides reassurance to the customers (if the product roadmap is made public).

Unfortunately, I find that many product managers and product owners struggle with their roadmaps, as they are dominated by features: There are too many features, and the features are often too detailed. This turns a roadmap into a tactical planning tool that competes with the Product Canvas or product backlog. What’s more, the features are sometimes regarded as a commitment by senior management rather than part of a high-level plan that is likely to change.

The GO Product Roadmap Explained

Faced with this situation, I have developed a new goal-oriented agile roadmap — the GO product roadmap, or “GO” for short. GO is based on my experience of teaching and coaching product managers and product owners, as well as using product roadmaps in my own business.

The following pictures shows what the GO product roadmap looks like. You can download a PDF and Excel template by simply clicking on the picture.


The first row of the GO roadmap depicted above contains the date or timeframe for the upcoming releases. You can work with a specific date such as  1st of March, or a period such as the first or second quarter.

The second row states the name or version of the releases, for instance, iOS 7 or Windows 8.1.

The third row provides the goal of each release, the reason why it is worthwhile to develop and launch it. Sample goals are to acquire or to activate users, to retain users by enhancing the user experience, or to accelerate development by removing technical debt. Working with goals shifts the conversation from debating individual features to agreeing on desired benefits making strategic product decisions. The development team, the stakeholders, and the management sponsor should all buy into the goals.

The fourth row provides the features necessary to reach the goal. The features are means to an end, but not an end in themselves: They serve to create value and to reach the goal. Try to limit the number of features for each release to three, but do not state more than five. Refrain from detailing the features, and focus on the product capabilities that are necessary to meet the goal. Your product roadmap should be a high-level plan. The details should be covered in the Product Canvas or product backlog, and commitments should be limited to individual sprints.

The last row states the metrics, the measurements or key performance indicators (KPIs) that help determine if the goal has been met, and if the release was successful. Make sure that the metrics you select allow you to measure if and to which extent you have met the goal.

A Sample GO Product Roadmap

To illustrate how the GO template can be applied, imagine we are about to develop a new dance game for girls aged eight to 12 years. The app should be fun and educational allowing the players to modify the characters, change the music, dance with remote players, and choreograph new dances. Here is what the corresponding GO roadmap could look like:


While the roadmap above will have to be updated and refined at a later stage (particularly the metrics), I find it good enough to show how the product may evolve and make an investment decision.

When creating your GO roadmap make sure you determine the goal of each release before you identify the features. This ensures that the features do serve the goal. Filling in the roadmap template from top to bottom and from left to right works well for me.

My post “Working with the GO Product Roadmap” explains the GO product roadmap in more detail including its relationship to the Vision Board, Business Model Canvas, and Product Canvas.


The GO product roadmap provides a new, powerful way to do product roadmapping. Rather than focussing on features, GO emphasises the importance of shared goals. This makes it easier to communicate the roadmap, create alignment, and use it as a strategic planning tool that provides an umbrella for the Product Canvas and the product backlog. The metrics provided by the tool ensure that the goals are measurable rather than lofty and fuzzy ideas. Download the template now, and try it out!

You can learn more about creating effective product roadmap and working with the GO product roadmap by attending my Agile Product Planning training course. Please contact me for bespoke product roadmap workshops and webinars.


The Three Planning Levels

Agile product planning comprises three levels: vision, product strategy, and tactics. The vision is the overarching goal, the product strategy the path to the vision, and the tactics are the steps along the way, as the following diagram illustrates:

The level of detail increases, as we move down from the vision to the tactics: Whereas the vision is typically captured by a brief statement, the strategy communicates different aspects including the market or market segment targeted, the product price and the channels, and the product’s unique selling points (USP’s). The tactics go further by describing the product details employing, for instance, user stories, design sketches, scenarios, and storyboards, as the following picture shows:

The Vision

Product planning starts with creating a vision: an overarching, shared goal that guides people. A sample vision from my own company is: “Grow Pichler Consulting without increasing headcount.” This vision may not sound mega exciting but it is very helpful for my team and me: It guides our work and focuses our efforts. Note that the sample vision doesn’t mention a specific product or service. It rather states a business goal. How the goal is realised is captured in the product strategy.

The Product Strategy

The product strategy is the path chosen to realise the vision. Without a strategy, making the right decisions about the product details is difficult: the functionality, the design, and the non-functional properties the product should exhibit. Having a strategy in place also prevents me from getting lost in the details.

I find it helpful to capture the target group, the needs addressed, the key features of the product, and the desired business benefits in the product strategy. But you may want to add the product price, the channels, the main competitors, and other important business model elements to characterise your strategy more comprehensively. As the strategy is a path to the vision, it may turn out to be wrong. This is particularly likely when a new product is created. Changing the strategy is also called a pivot.

The Product Tactics

The product tactics describe the product details: the product functionality, the user interaction, and the user interface design. Great techniques to capture these aspects are epics and ready stories, scenarios, design sketches and mock-ups, constraint stories, and sprint goals. New product features are best delivered incrementally so we can learn from the feedback we collect. I use blog posts, for instance, to create the material for my e-learning course. This allows me to learn from the feedback I receive, and to validate my strategy and the product details.

Product Planning Tools

I prefer to use the agile product planning tools shown in the picture below:

To capture my vision and the key elements of the product strategy I like to employ the Vision Board and the GO product roadmap. I use the Business Model Canvas to describe aspects not covered by the Vision Board such as partners, and customer relationship.

To capture the details, I use the Product Canvas. The canvas allows me to work with personas, epics, scenarios and storyboards, design sketches and mock-ups, constraint stories, sprint goals, and ready stories. For an incremental product update, a product backlog may be sufficient to capture the product details.


Creating successful products requires more than attention to the product details. Ensure you have a shared in vision in place, and choose a strategy that guides you towards the vision. Use early feedback to validate if you are on the right path, if your strategy is valid. Let the product strategy help you decide what your product should look like and do.

You can learn more about agile product planning and creating a powerful vision and product strategy by attending my Agile Product Planning training course.

What is an Agile Product Roadmap?

A product roadmap is a high-level plan that describes how the product is likely to grow. It allows you to express where you want to take your product, and why it’s worthwhile investing in it. An agile product roadmap also facilitates learning and change. A great way to achieve these objectives is to employ a goal-oriented roadmap – a roadmap based on goals rather than dominated by many features.

Here is a sample agile product roadmap that shows the anticipated development of a dance game app for kids:


The roadmap above states the date, the name, the goal, the key feature, and the metrics for each major release or product version. It is a goal-oriented product roadmap, and it applies the GO roadmap template, which is explained in more detail in my post “The GO Product Roadmap”.

The benefit of a goal-oriented roadmap is that it shifts the conversation from arguing over features to agreeing on shared goals. This mitigates the conflict between viewing roadmap features as commitments and agile teams who only commit for next few weeks.

What Benefits does a Product Roadmap Provide?

A product roadmap can provide the following five benefits: First, it helps you communicate how you see the product develop.

Second, it helps align the product and the company strategy. By anticipating how the product is likely to grow you can show how the product helps the organisation reach its goals. This makes it easier to secure a budget for the next fiscal year.

Third, a product roadmap helps manage the stakeholders and coordinate the development, marketing, and sales activities.

Fourth, a product roadmap facilitates effective portfolio management, as it helps synchronise the development efforts of different products.

Last but not least, using a roadmap supports and complements the Product Canvas and the product backlog. This allows the canvas and backlog to focus on the tactical product development aspects, as I explain in more detail below.

When should I Use a Product Roadmap?

I usually create a product roadmap once I can confidently look beyond the next major release. If you cannot look further, then do not employ a roadmap! What’s more, I want to ensure that the assumptions about the target group, the needs to be addressed, and key aspects of the business model have been validated, as the picture below illustrates:


In the picture above, the market and business model assumptions are captured on a Vision Board. But you can also use the Business Model Canvas or Lean Canvas to state and validate your ideas. While the Vision Board and the two canvases are helpful tools, they not tell us how the strategy will be executed. This is where the product roadmap comes in.

How do the Product Roadmap and the Product Canvas/Backlog Relate?

Using a product roadmap can benefit your Product Canvas and product backlog . Here is why: As the roadmap takes care of the strategic product planning aspects, it frees the canvas/backlog to focus on the tactical work, as the picture below illustrates.


Say you release a new product version every three months. I would then suggest that your product roadmap should capture the next four major releases, while your Product Canvas or product backlog focuses on creating the next product version.

The following table summaries the differences between the product roadmap and the product backlog:

Who Owns the Product Roadmap?

As the product roadmap captures decisions about the product’s futures, the individual responsible for the product success should own the roadmap. In an agile context, the product owner should hence manage the product roadmap. The team members and stakeholders contribute, as the following picture suggests.


Having one person in charge of the product roadmap and the Product Canvas/backlog unites the strategic and the tactical product planning aspects, and establishes clear authority and responsibility.


A product roadmap allows you to communicate where you want to take your product. If applied correctly, the product roadmap and the product backlog complement each other nicely. But before you create your roadmap, make sure that you are able to forecast how your product is likely to develop in the future.

Learn more about working with product roadmaps by attending my Agile Product Planning training course. You can also download my GO product roadmap template that allows you to create goal-oriented, agile roadmaps.

This post was last updated on 15 January 2014.