Replacing Your Product Roadmap with GIST

A GIST framework implementation guide: replace a feature roadmap with GIST planning through a staged transition that keeps commitments and trust.

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

This skill is a GIST framework implementation guide for teams that plan with a feature roadmap today. Itamar Gilad created GIST as a replacement for the roadmap: his original article is titled "Why you should stop using product roadmaps and try GIST Planning" (HackerNoon copy), and he still presents it as a product roadmap alternative on his site. The GIST Planning Framework page covers the model. This page covers the transition: how to replace a roadmap with GIST without breaking promises or losing stakeholders along the way.

Gilad's reasons for dropping roadmaps are the ones most teams recognize. Getting all stakeholders to agree on a roadmap is a massive undertaking with a low return, plans are out of date soon after they are published, changes at the top ripple into replanning and cancelled projects, and because only a few big projects get funded, many potentially good ideas are killed upfront (HackerNoon copy). GIST answers those problems with goals instead of feature lists, an idea bank instead of a backlog, short step-projects instead of long projects, and regular revisits of every layer.

The difficulty is that a roadmap is also a social contract. Sales has told customers about features on it, executives have planned around it, and other teams depend on its dates. A GIST planning transition has to respect the commitments that are real while converting everything else into goals and ideas. Gilad himself reports that coworkers and board members readily understand the language of goals, ideas and step-projects and that the transition is not hard. Teams in organizations used to fixed plans may still meet resistance, and should plan for it.

The output of this skill is a transition plan: an inventory of the old roadmap sorted into commitments and ideas, a first set of GIST goals, a pilot on one or two goals, a stakeholder view to replace the roadmap, and a date for retiring the old document.

How It Works

The transition starts by sorting the roadmap. Every item is one of three things: a real commitment with an external promise, a contract or a regulation behind it; a solution to a goal that nobody wrote down; or a request with little behind it. Commitments stay and are tracked as ordinary work. Solutions become ideas under the goal they were meant to serve. Requests go into the idea bank with an honest Confidence score.

Goals come next. For each cluster of roadmap items, the team asks what outcome they were supposed to produce and writes that as a goal with a metric, a baseline and a target. This step often reveals that several roadmap features were competing answers to the same goal, which is exactly the situation GIST handles well.

Running both systems for a period lowers the risk. The team pilots GIST on one or two goals while the rest of the roadmap continues as planned. The pilot produces the evidence stakeholders need: ideas tested cheaply, some stopped early, some moving to full builds. Gilad's book includes a chapter on adoption strategies, and his GIST Scorecard is a self-assessment a team can use to discuss where it stands before and after the change.

Stakeholders need a replacement view. Gilad's answer is the GIST board, which he calls a substitute for roadmaps and Gantt charts that managers and stakeholders should see regularly (The GIST Board). For those who insist on a timeline, he offers an outcome roadmap that shows goals, research, discovery, delivery and the delay before results appear. Keeping this view up to date is what earns permission to retire the old roadmap.

The limits deserve honesty too. ProductPlan's critique of GIST notes that it handles long, multi-phase initiatives poorly and makes resource and capacity planning harder. Teams with heavy external dependencies may keep a delivery plan for committed work alongside GIST for everything uncertain.

Step-by-Step Guide

Step 1: Inventory the roadmap

List every item on the current roadmap with its source, its promised date and who depends on it. Mark which items carry a real external commitment, such as a customer contract, a regulatory deadline or a partner launch. Ask the item owners directly rather than guessing. Some items will turn out to be expectations that nobody formally promised.

Step 2: Sort commitments, solutions and requests

Keep real commitments as tracked work with their dates. Rewrite items that are solutions as ideas and ask what goal each was meant to serve. Move loose requests into the idea bank. Share the sorted list with the item owners so nobody is surprised.

Step 3: Write the first goals

Group the solution items by the outcome they aim at and write one goal per group, with a metric, a baseline, a target and a date. Keep the number of goals small. Check that each goal leaves room for several ideas, including ones that were never on the roadmap.

Step 4: Pick a pilot and build its idea bank

Choose one or two goals for a pilot quarter, ideally ones where the team was already unsure which feature would work. Put the related roadmap items and any new ideas into the bank, score them with ICE, and be strict about Confidence for items that were on the roadmap only because someone asked.

Step 5: Run the first step-projects

Design small step-projects for the top ideas and run them within the team's normal sprints. Keep each step short and set its threshold before it starts. Share results as they come in, especially ideas that are stopped early, since those show the value of the change most clearly.

Step 6: Give stakeholders a new view

Put up a GIST board for the pilot goals and share it on a regular rhythm. Where stakeholders need dates, provide decision dates for each step and an outcome roadmap. Keep the old roadmap updated for non-pilot work during the pilot so there is no gap in visibility.

Step 7: Review the pilot and expand

At the end of the pilot, compare what GIST produced with what the roadmap would have: ideas stopped, evidence gathered, goal progress. Discuss the results with stakeholders. If the pilot worked, move the remaining goals to GIST in the next quarter.

Step 8: Retire the roadmap and keep improving

Once all goals run through GIST, retire the feature roadmap and keep only the commitments list and the stakeholder views. Review the process each quarter: whether steps stay small, whether confidence scores match results, and whether leaders are letting the team choose the ideas.

Best Practices

• Honor real commitments. Breaking promises to customers or partners in the name of GIST will end the transition quickly.
• Pilot before switching everything. A quarter of evidence from one or two goals persuades more than any explanation of the framework.
• Convert roadmap features into ideas under goals, and score them honestly. A feature being on the old roadmap is not evidence that it will work.
• Share stopped ideas openly. They show stakeholders the cost the team avoided.
• Give stakeholders a view they can use. The GIST board and, where needed, an outcome roadmap replace the visibility the old roadmap provided.
• Assess where you are. Gilad's GIST Scorecard gives the team a structured way to discuss its practices at each layer.

Common Mistakes

• Renaming roadmap items as goals: "Launch feature X" relabeled as a goal changes nothing. Ask what outcome X was meant to produce and write that instead.
• Switching everything at once: A big-bang change leaves stakeholders with no view and no evidence. Pilot on one or two goals first.
• Ignoring real commitments: Some items truly carry external promises. Keep them visible and on schedule while GIST handles the rest.
• Leadership still choosing the solutions: If senior people keep deciding which features to build regardless of step results, GIST becomes a roadmap with new labels. Raise it directly and agree who chooses ideas.
• Stopping communication: Stakeholders who lose sight of the plan will ask for the roadmap back. Share the board and results on a regular rhythm.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: GIST Planning Framework

Related Skills

• Presenting GIST Plans to Stakeholders
• Defining Measurable Product Goals in GIST
• Building a Product Idea Bank for the GIST Ideas Layer
• GIST Planning Cadence: Managing Multi-Cadence Cycles

Sources

• Itamar Gilad: GIST Framework
• HackerNoon: the original GIST Planning article
• Itamar Gilad: The GIST Board and Other GIST Tools
• Itamar Gilad: Planning With Outcome Roadmaps
• Itamar Gilad: GIST Scorecard
• Itamar Gilad: Evidence-Guided
• ProductPlan: GIST Planning

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