Reviewing and Adapting GO Roadmap Goals

Review a GO product roadmap with the product strategy: judge each goal on its metrics, update what changed, and keep the backlog in sync.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

A GO product roadmap is a forecast, and forecasts go stale. Roman Pichler's checklist lists "Adaptive" among the roadmap's overall criteria: the roadmap is regularly inspected and adapted, "at least once every three months as a rule of thumb" (GO Product Roadmap template and checklist). This skill covers running those reviews so they produce decisions and a current plan. The roadmap format itself is covered on the GO Product Roadmap page.

Reviews exist because the inputs change. Development progress may be faster or slower than expected, user data and feedback arrive, competitors move, and the product strategy itself shifts. Pichler describes a product roadmap as a living document that has to be regularly updated to account for development progress, user data and feedback, and changes in the overall product strategy (Should Product Roadmaps Have Dates?). A roadmap that is not reviewed gradually describes a plan nobody is following.

Pichler recommends combining roadmap and strategy reviews. Doing them together saves a meeting and keeps the two plans in sync, since the roadmap states how the current strategy will be implemented and bigger roadmap changes may require strategy adjustments (Tips for Effective Product Strategy Reviews). He suggests allowing two to three hours for a quarterly strategy and roadmap workshop, assuming it is well prepared and facilitated.

The cadence can vary. In his agile roadmap tips, Pichler gives a range from every four weeks to every three months, depending on how young the product is and how dynamic the market is (10 Tips for Creating an Agile Product Roadmap). Between reviews, he recommends continuously watching product performance through KPIs and keeping an eye on competitors and trends, so that important changes are spotted early. The output of each review is an updated roadmap, a short record of what changed and why, and communication to everyone who relies on the plan.

How It Works

A review looks backward and forward. Looking back, it asks whether the goal for the period just ended was met, using the metrics defined for it, and what the team learned. Looking forward, it asks whether the upcoming goals are still the right ones, in the right order, with the right features and metrics.

The strategy half of the review gives the forward look its context. Pichler suggests examining four factors when reviewing the product strategy: performance, trends, competition, and company (Tips for Effective Product Strategy Reviews). Performance covers the KPIs. Trends covers new technology, regulatory, or social developments. Competition covers new products, features, and entrants. Company covers internal changes such as a new business strategy or key people leaving. From that assessment, the options range from no change through small and big changes to retiring the product.

The roadmap half follows. For each upcoming goal, the group decides whether to keep it, change it, reorder it, or replace it. Metrics for later goals, which were rough when first written, are sharpened for the next goal. Features for the next goal are revisited in light of what the team learned. Dates are checked against progress, and where they are no longer realistic, the group decides which of goal, date, and budget gives.

The backlog is part of the picture. Pichler notes that the relationship works in both directions: backlog changes, slow progress, or user feedback can cause roadmap changes, which in turn can affect the strategy (Choosing the Right Planning Horizons). After the review, the backlog is refocused on the next roadmap goal.

The same people who helped create the roadmap should review it. Pichler recommends involving the development team and key stakeholders, preferably in a collaborative workshop with a facilitator, so that changes carry the same buy-in as the original plan.

Step-by-Step Guide

Step 1: Set the cadence and triggers

Put a recurring review on the calendar, quarterly by default, and more often for young products in fast-moving markets. List the events that trigger an extra review, such as a major competitor move, a significant KPI change, or a strategy change. Block the time in advance so urgent work does not crowd it out.

Step 2: Gather the evidence

Before the review, collect the metric results for the goal just completed, the current KPIs, relevant user feedback, and notes on trends, competitors, and company changes. Summarise development progress against the roadmap's dates. Circulate the pack ahead of the meeting so the time together is spent deciding.

Step 3: Judge the completed goal

Using the metrics defined for it, decide whether the goal was met, partly met, or missed. Discuss what the team learned, including surprises. If the result cannot yet be read because the metric has a delay, note when it will be available and follow up then.

Step 4: Review the strategy

Walk through performance, trends, competition, and company. Decide whether the strategy needs no change, a small adjustment, or a bigger change. A big change means the roadmap below it will need substantial rework, which may need its own workshop.

Step 5: Update the upcoming goals

For each upcoming goal, decide to keep, change, reorder, or drop it. Sharpen the metrics and features for the next goal. Check dates against progress and apply the agreed flexibility where they no longer hold. Add a new goal at the end if the horizon has moved.

Step 6: Refocus the backlog

Align the product backlog with the next roadmap goal. Remove or archive items that no longer serve any goal, and add the detail the next goal needs. Check that any release plan reflects the updated roadmap.

Step 7: Record and communicate the changes

Write a short note of what changed and why, and publish the updated roadmap in all its views. Tell stakeholders about changes that affect them directly, especially date changes. Keep past versions so later reviews can see how the plan evolved.

Best Practices

• Review the strategy and roadmap together. Separate meetings let the two plans drift apart, which Pichler's combined review is designed to prevent.
• Prepare the evidence in advance. A review that starts by reading numbers runs out of time before decisions are made.
• Judge goals on their metrics. Whether the features shipped is a delivery question; whether the goal was met is the roadmap question.
• Match the cadence to the product. Young products in dynamic markets need shorter cycles, within Pichler's range of every four weeks to every three months (10 Tips).
• Watch KPIs between reviews. Continuous monitoring lets you call an extra review before a problem becomes a crisis.
• Keep the review collaborative. Changes agreed by the same group that built the roadmap keep its buy-in.

Common Mistakes

• Skipping reviews when things look fine: Markets and competitors change even when your numbers do not. Keep the cadence.
• Declaring success when features ship: Shipping is not the goal. Read the metrics before calling a goal met.
• Rewriting the roadmap every month: Constant goal changes suggest the goals are too small or the strategy is unstable. Fix the underlying cause.
• Updating the roadmap without the backlog: A changed roadmap with an unchanged backlog means the team keeps working on the old plan. Refocus the backlog on the next goal.
• Changing the plan silently: Stakeholders who discover changes by accident lose trust in the roadmap. Announce what changed and why.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: GO Product Roadmap

Related Skills

• GO Product Roadmap Template: How to Build One
• Defining Goals for a GO Product Roadmap
• Setting Metrics for GO Roadmap Goals
• Mapping Features to GO Roadmap Goals
• Structuring Roadmap Timeframes and Time Horizons
• Aligning Stakeholders with a GO Product Roadmap

Sources

• Roman Pichler: GO Product Roadmap template and checklist
• Roman Pichler: Should Product Roadmaps Have Dates?
• Roman Pichler: Tips for Effective Product Strategy Reviews
• Roman Pichler: 10 Tips for Creating an Agile Product Roadmap
• Roman Pichler: Choosing the Right Planning Horizons for Your Product

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.