GO Product Roadmap: Goal-Oriented Product Roadmaps

Created by Roman Pichler - https://www.romanpichler.com/

Overview

The GO product roadmap is a goal-oriented product roadmap created by Roman Pichler. GO stands for goal-oriented. Pichler defines a product roadmap as "a strategic product plan that describes how the product is likely to evolve over the coming months" (The GO Product Roadmap). His format answers the question "what is a product roadmap for?" by putting outcomes first: each column of the plan states a goal the product should achieve, when it should be met, the few high-level features needed to meet it, and the metrics that will show whether it was met.

Pichler introduced the format in an article published on 25 November 2013 (The GO Product Roadmap). The problem he describes is familiar to most product managers. Roadmaps are often dominated by features: there are too many of them, they are too fine-grained, and stakeholders read them as commitments. Such a roadmap, he writes, makes it hard to secure agreement, overlaps and competes with the product backlog, and changes constantly. He says he developed the GO roadmap from his experience teaching and coaching product managers and product owners and from using roadmaps in his own business. He is also candid about its roots: he did not invent this specific roadmap format, and in his words "It has been around for several years, and I honestly do not know who first suggested it."

The official template has five rows (GO Product Roadmap template and checklist). Date is the date or time frame when a goal should be met. Name is the name of the new release, useful when meeting the goal produces a major version. Goal is the outcome or benefit you want to achieve. Features are the high-level features required to meet the goal. Metrics are the measures that determine whether the goal has been met. Columns run left to right through time, so reading one column tells you the whole story of one step in the product's development.

The goal row carries the method. Pichler calls it the most important of the five elements and adds, "Strictly speaking, all other elements are optional" (Get the Outcomes on Your Product Roadmap Right). His summary of the ordering is "Goals come first, features second." Sample goals from his writing include acquiring new users, increasing engagement, and removing technical debt. Features stay on the roadmap only as means to those ends, kept coarse-grained, with epics and user stories left in the product backlog.

The GO roadmap sits inside a larger planning model. In Pichler's model the vision describes the ultimate purpose, the product strategy states how the vision will be realised, the roadmap states how the strategy will be implemented, and the backlog holds the detail (Choosing the Right Planning Horizons). He writes that roadmaps benefit from a twelve-month horizon in his experience, with quarterly product goals (Choosing the Right Planning Horizons), and suggests going further by focusing the product backlog on the next product goal (The Product Roadmap and the Product Backlog). That is why the method asks for a validated product strategy before any roadmap work starts.

Two practical rules shape how the roadmap is used. Dates depend on the audience: Pichler recommends dates or narrow timeframes on internal roadmaps that align teams and stakeholders, and coarse timeframes or no dates at all on external, customer-facing ones (Should Product Roadmaps Have Dates?). And the roadmap is a living plan, reviewed together with the product strategy, which his checklist puts at "at least once every three months as a rule of thumb" (GO checklist).

The format has spread well beyond Pichler's own site. Template galleries such as Lucid and airfocus publish versions credited to him, and Mike Cohn's Mountain Goat Software podcast devoted an episode to his outcome-based roadmapping. Pichler has since applied the same five elements to product portfolios and shown how the roadmap maps onto OKRs. If you want to set up the grid itself, the GO product roadmap template skill walks through building one.

Core Principles

Goals Come First, Features Second

Every column starts with an outcome or benefit, and features are added only afterwards. Pichler describes features as "a means to an end, but not an end in themselves" in his original article. Starting with goals moves the stakeholder conversation from which feature ships when to which outcome matters most. A roadmap built the other way round tends to collect every request that someone lobbied for.

One Goal per Timeframe

Pichler recommends using one product goal at a time because it creates clarity and alignment and makes progress easier to track (The GO Product Roadmap). Several goals in the same period dilute focus and invite resource conflicts. He treats an occasional second goal as acceptable and a habit of multiple goals as a sign that the timeframes are too big or that stakeholders cannot agree. If a single goal feels impossible, that disagreement is the thing to resolve.

Goals Describe Real Outcomes

A goal must describe the value the product should create. Pichler warns against goals that are really features in disguise, such as "measure calorie intake", and suggests asking why the capability matters until the true outcome appears (Get the Outcomes Right). He also favours compound goals that name a user benefit and a business benefit together, so that neither side is forgotten. A goal written as an output cannot guide feature choices, because it already is one.

Few, Coarse-Grained Features

The features row holds big product capabilities that act as placeholders for specific functionality. The official checklist says to "Limit their number to three to five per outcome" and to keep product details such as user stories in the backlog (GO checklist). Every feature must be required to meet the goal in its column. Detail on the roadmap makes it harder to agree, more prone to change, and a competitor to the backlog.

Measurable Goals

Each goal needs metrics that tell you whether it was met. The checklist asks for metrics that are precise and time-bound: say how you will know the goal was met and when you will be able to find out, for instance one week after release (GO checklist). Stating metrics also forces goals to be specific. A goal without a way to judge it cannot be reviewed honestly.

Strategy Before Roadmap

The roadmap implements a product strategy, so the strategy has to exist and be validated first. Pichler advises against creating a roadmap if you lack a valid strategy or cannot look beyond the first release, because the result is speculative and costs stakeholder trust (Three Common Product Roadmapping Mistakes). Goals are derived by breaking the strategy's user and business goals into smaller, measurable steps. That derivation is what connects the roadmap to the company's direction.

Shared and Adaptive

A roadmap only works if the people who use it understand and support it. Pichler recommends creating and updating it in collaborative workshops with key stakeholders and development team members, aiming for consent (Stakeholder Buy-in). The same group reviews it regularly as data, feedback, and markets change. A roadmap that is never revisited stops describing the plan.

Steps

1. Validate the Product Strategy Confirm that you have a product strategy that states the users and customers, their needs, the business goals, and the standout features. Pichler assumes the strategy has been validated, meaning its key risks and assumptions have been addressed with evidence (Get the Outcomes Right). If it has not, do the discovery and strategy work first. Also check how far ahead you can realistically see, because a roadmap built on guesses will be rewritten within weeks. The output of this step is the strategy the roadmap will implement.

2. Derive Candidate Goals Break the strategy's needs and business goals into smaller, specific outcomes. For a mature product, also look at your key performance indicators: a declining engagement metric or rising bug count can point to a goal such as improving the user experience or reducing technical debt. Test each candidate with the why question so that no feature slips in disguised as a goal. Where it helps, write compound goals with a user part and a business part. The output is a list of candidate outcomes.

3. Order and Right-Size the Goals Order the goals so they tell a coherent story of how the product will grow, with each one building on the last. For young products Pichler suggests a narrative such as acquisition, then activation, retention, and revenue, and for mature products ordering by cost of delay (Product Roadmap Prioritisation). Size them so each can be met in a reasonable period; his guideline is that "Roadmap goals should be no smaller than six weeks and not bigger than four months" (Get the Outcomes Right). Split goals that are too big and merge those that are too small.

4. Add Metrics to Each Goal For every goal, write down how you will tell whether it was met and when that will be knowable. Define terms precisely, for instance whether "new users" means registrations or unique visits. Include a target where you can, and a baseline if you have one. If making every goal measurable is too hard today, Pichler suggests making at least the first one measurable and refining the rest at later reviews. The output is the metrics row.

5. Select a Few Coarse Features Only now list the capabilities needed to reach each goal, keeping to a handful per column. Check that each feature is required for its goal and remove any that are not, however senior the requester. Keep epics, user stories, and design detail in the product backlog. For later columns, accept that features are rough placeholders that will change. The output is the features row.

6. Set Dates and Names for the Audience Decide whether the roadmap is internal or external. For an internal roadmap, state a target date or a quarter, and check with the development team that each date is realistic without overtime. For an external roadmap, use coarse timeframes or remove the date row. Add a release name only when meeting the goal produces a major version worth naming.

7. Co-Create and Secure Consent Bring key stakeholders and development team representatives together in a facilitated workshop to review or build the roadmap. Work through goals before features and resolve conflicts at the goal level. Check agreement explicitly, for example with an agreement scale and dot voting, and aim for consent, meaning nobody has a meaningful objection. The person in charge of the product makes the call when agreement cannot be reached.

8. Review and Adapt Regularly Review the roadmap together with the product strategy on a regular cadence, quarterly as a rule of thumb, and sooner when something significant changes. Check whether the last goal was met, whether upcoming goals still make sense, and whether features or metrics need to change. Keep the backlog in sync, since slower progress or new user data can change the roadmap. Share the updated version with everyone who relies on it.

GO Roadmap vs Other Roadmap Formats

The GO roadmap is one of several common roadmap formats. The table compares it with the formats it is most often weighed against, using each originator's own description.

Pichler does not reject feature-based roadmaps outright. He recommends them only when the product is mature and its market is stable, and goal-oriented roadmaps whenever the product or the market is likely to change (How to Choose the Right Product Roadmap Format). Janna Bastow writes that the original Now-Next-Later roadmap was sketched out in 2012 and titled Current, Near Term, and Future (ProdPad). Pichler himself mentions a now-next-later grid as an option for ordering releases on an external roadmap (10 Tips for Creating an Agile Product Roadmap).

When to Use

• Your product or its market is changing, for example a young product or a market with new competitors, which is where Pichler recommends goal-oriented roadmaps over feature-based ones.
• Stakeholders keep arguing about individual features, and you need a shared standard (the goal) against which to judge each request.
• You have a validated product strategy and need a plan that shows how it will be implemented over the coming months.
• You need one artefact for internal planning with dates and a coarser external version for customers, since the same format supports both.
• Your organisation already uses OKRs, and you want a roadmap whose goals can be read as objectives.

When Not to Use

• You have no validated strategy yet or cannot see past your first release, because any goals you write will be speculation.
• The product is mature and the market is stable, so change is low and a more detailed feature-based roadmap can forecast accurately.
• A customer contract or regulator fixes specific deliverables on specific dates, where you need a release or project plan for those items rather than a goal-level roadmap.
• The work ahead is a single well-defined project, such as a migration, that a release plan already describes; forcing it into a goal column adds ceremony.