Mapping Features to GO Roadmap Goals

Map a few coarse-grained features to each goal on a GO product roadmap, check every one serves its goal, and move the detail to the backlog.

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

The features row of a GO product roadmap lists the capabilities needed to reach the goal above it. Roman Pichler describes these features as the output required to create the desired outcome, "a means to an end, but not an end in themselves" (The GO Product Roadmap). This skill covers choosing those features once the goals are set, keeping them few and coarse, and handling everything that does not make the cut. Background on why goals come first is on the GO Product Roadmap page.

Pichler's checklist gives three rules for the features row (GO Product Roadmap template and checklist). Goal-directed: each feature must be required to meet a product goal on the roadmap. Coarse-grained: features describe big product capabilities that act as placeholders for specific functionality, and product details such as user stories stay in the product backlog. Focused: only sketch the features crucial to meeting the goal, and "Limit their number to three to five per outcome."

The rules exist because detail on a roadmap causes predictable problems. Pichler lists them: a detailed roadmap is harder to understand, harder to agree on, more prone to change, competes with the product backlog, and restricts the development team's freedom (Three Common Product Roadmapping Mistakes). A short list of capabilities per goal keeps the roadmap strategic and leaves the backlog to do its job.

Mapping features is also where most stakeholder requests land. Items that were on an earlier roadmap, ideas from sales, and technical work all need a home. Pichler's approach is to check whether each item helps reach one of the goals, assign it if it does, and otherwise discard it or consider whether the goals should change (Product Roadmap Prioritisation). That makes this skill the point where the roadmap's goal-first principle is either kept or quietly abandoned.

The output is the features row: for each goal, a handful of named capabilities, each with a one-line reason it serves the goal, plus a record of items moved to the backlog or declined.

How It Works

Mapping runs in one direction: from goal to features. For each goal, ask how the product has to change to meet it. Pichler suggests a set of questions for this in his guide to outcome-based roadmaps: does the user experience have to change, does functionality have to be added or changed, are new non-functional requirements needed, and are bug fixes or architecture work required (How to Get Started with Outcome-Based Product Roadmaps). The answers are the candidate capabilities.

Candidates then compete for a small number of places. The checklist limit of three to five per goal forces the team to choose the capabilities most likely to move the goal's metric. In his original article Pichler puts it slightly differently: try to limit features to three, and do not state more than five. Capabilities that are useful but not needed for the goal become backlog items under the goal, where the team can still pick them up.

Coarse means capability-sized. Pichler uses the term feature for a product capability, a large piece of functionality bigger than an epic (Get the Outcomes on Your Product Roadmap Right). A good roadmap feature reads like "guided first-project setup" rather than a user story. The detail is worked out in the backlog, which Pichler recommends focusing on the next roadmap goal.

Existing items are handled next. Take the old roadmap entries, open requests, and technical work and check each against the goals. Items that serve a goal are assigned to it, often as backlog items. Items that serve no goal are declined or parked, and occasionally an important item reveals a missing goal, which goes back to goal-setting rather than being squeezed into the features row.

Later columns get lighter treatment. Features for goals several months away are rough placeholders, because the team will learn a lot before starting them. In his original article Pichler criticises roadmaps whose features are regarded as a commitment instead of as part of a high-level plan that is likely to change, which is why they stay coarse.

Step-by-Step Guide

Step 1: Confirm the goals and metrics are settled

Check that each goal is an outcome, has metrics, and has been agreed. Mapping features to unstable goals means redoing the work. If a goal is still disputed, resolve that first. The output is the list of goals you will map to.

Step 2: Generate candidate capabilities for each goal

For each goal, work through Pichler's questions: what must change in the user experience, functionality, non-functional qualities, and technical health for this goal to be met? Include the development team, since they often see the technical work others miss. Write each candidate as a capability the product should gain.

Step 3: Choose three to five per goal

Rank the candidates by how likely they are to move the goal's metric and by rough effort. Keep the few that matter most to the goal. Move the rest into the backlog under that goal so they are not lost. If more than five seem essential, the goal is probably too big and should be split.

Step 4: Write a one-line reason for each feature

Next to each feature, write how it serves the goal. This makes the mapping reviewable and helps stakeholders understand why their request did or did not appear. A feature whose reason sounds weak when written down is a candidate for removal.

Step 5: Sort existing items and requests

Take every item from the previous roadmap and every open request. Assign each to the goal it serves, usually as a backlog item. Decline items that serve no goal, following Pichler's advice to use the outcome as the decision tool. Flag any important item that fits no goal for discussion at the next roadmap workshop.

Step 6: Check coverage and balance

Look across the columns. Every goal should have at least one feature, and every feature should sit under exactly one goal. Check that the combined work in each timeframe is plausible for the team, since an overloaded column will slip. Adjust the features, the goal size, or the timeframe if it is not.

Step 7: Focus the backlog on the next goal

Move the detailed work for the nearest goal into the product backlog as epics and user stories. Remove or archive backlog items that serve no current goal, as Pichler suggests when adopting outcome-based roadmaps. Keep later columns at capability level until their goals come closer.

Best Practices

• Start from the goal every time. Asking what the goal needs produces a different and usually shorter list than asking which requests can be squeezed in.
• Use the limit as a design constraint. Three to five features per goal forces the conversation about which capabilities matter most, which is the conversation the roadmap exists to have.
• Keep features capability-sized. If a feature reads like a user story, it belongs in the backlog, a point Pichler makes in his article on the roadmap and the backlog.
• Write down why each feature serves its goal. The reason is what lets stakeholders accept a no.
• Include enabling work. Bug fixes, performance work, and architecture changes can be required to meet a goal and belong on the list when they are.
• Treat later features as hypotheses. Expect them to change as the team learns, and say so when you present the roadmap.

Common Mistakes

• Mapping in reverse: Starting from a feature list and inventing goals to justify it produces goals nobody believes. Set the goals first, then choose features.
• Too many features per goal: A long list turns the roadmap into a release plan and makes every item look like a commitment. Keep to three to five and move the rest to the backlog.
• Stories on the roadmap: User stories and epics make the roadmap harder to read and quicker to go out of date. Keep them in the backlog.
• Orphan features: A feature that serves no goal usually got there because someone important asked. Decline it or discuss it at the next workshop, but do not leave it unexplained.
• One feature serving several goals: Spreading one capability across columns hides where the effort goes. Assign it to the goal it serves most and note any secondary benefit.

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
• Structuring Roadmap Timeframes and Time Horizons
• Aligning Stakeholders with a GO Product Roadmap
• Reviewing and Adapting GO Roadmap Goals

Sources

• Roman Pichler: The GO Product Roadmap
• Roman Pichler: GO Product Roadmap template and checklist
• Roman Pichler: Three Common Product Roadmapping Mistakes
• Roman Pichler: Product Roadmap Prioritisation
• Roman Pichler: How to Get Started with Outcome-Based Product Roadmaps
• Roman Pichler: Get the Outcomes on Your Product Roadmap Right
• Roman Pichler: The Product Roadmap and the Product Backlog

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