GIST Planning Framework: Goals, Ideas, Steps, Tasks

Created by Itamar Gilad - https://itamargilad.com/

Overview

The GIST Planning Framework is Itamar Gilad's alternative to the feature roadmap. GIST stands for Goals, Ideas, Step-projects and Tasks: goals state the outcome a team wants, ideas are hypothetical ways to reach it, step-projects are small pieces of work that build and test an idea, and tasks are the daily work inside each step. Gilad introduced it in the article Why you should stop using product roadmaps and try GIST Planning, whose HackerNoon copy is dated January 30th, 2018. He later made it the organizing model of his book Evidence-Guided, where the third layer is simply called Steps.

Gilad's case against roadmaps comes from his own experience. In the original article he writes that getting stakeholders to agree on a roadmap is a large undertaking with a low return, that his roadmaps and Gantt charts were already out of date the day he published them, and that changes at the top of the plan set off rounds of replanning and cancelled projects. Roadmaps also fund only a few big projects, so many potentially good ideas are killed before anyone tests them. His book page describes his background in senior roles at Google, where he worked on YouTube and Gmail, and at Microsoft.

The model rests on a hard fact about product ideas. Gilad writes that at most 1 in 3 ideas will deliver a positive result, and often far fewer, citing the Microsoft paper Online Experimentation at Microsoft, which reports that only about 1/3 of ideas improved the metrics they were designed to improve. He adds that experienced leaders, product managers and designers do not pick winners at a better rate than anyone else (GIST Framework). If most ideas fail and nobody can reliably spot the good ones in advance, committing to a list of features months ahead is a bet made blind.

GIST answers that problem by separating what the team wants to achieve from how it might get there. Goals are defined through outcomes and, in Gilad's telling, draw on the Objectives and Key Results he used at Google. Ideas go into an idea bank, where none are killed upfront, and are ranked by evidence with Sean Ellis's ICE scoring; the skill on the GIST planning ideas layer covers running that bank. The top ideas are then broken into step-projects, each no more than 10 weeks long by Gilad's rule (GIST Framework), and each step is treated as an experiment in the sense of Lean Startup's Build-Measure-Learn loop. Tasks sit at the bottom and run on whatever agile method the team already uses.

The four layers change at different speeds, and that is deliberate. Goals look a year or more ahead and are reviewed quarterly, ideas are collected all the time, step-projects are chosen each quarter and reprioritized every one to two weeks, and tasks are planned in sprints and adjusted daily (HackerNoon copy of the original article). The skill on GIST planning cadence covers how to run those rhythms together.

The planning artifact that replaces the roadmap is the GIST board. Gilad describes it as goals on the left, this quarter's ideas in the middle and two to five steps per idea on the right, reviewed in weekly or bi-weekly team meetings, and he calls it a substitute for roadmaps and project Gantts that managers and stakeholders should see regularly (The GIST Board and Other GIST Tools). Building a GIST planning framework presentation around that board is a skill of its own.

GIST has critics. ProductPlan's glossary entry notes that it handles long, multi-phase initiatives poorly, makes resource and capacity planning harder, and assumes that all roadmaps are rigid. Those are fair limits to weigh, and a staged GIST framework implementation that keeps real commitments on a separate list answers some of them. The framework fits teams that own an outcome and face real uncertainty about which solutions will move it, and it adds little when the solution is already known.

Core Principles

Goals describe outcomes

A goal says where the team wants to be, by when, and how it will know it got there, and it answers the question "why are we doing this?" for any piece of work. Gilad borrows the military idea of telling people where to go without telling them how to get there (GIST Framework). A goal written as a feature ("launch the new dashboard") skips that question and locks in one solution before any evidence exists. In the book he ties goals to a North Star metric for value delivered and a top business metric for value captured (book resources).

Ideas are hypotheses

Gilad stresses the word hypothetical: an idea is a guess about how to reach a goal. Because most ideas fail and seniority does not improve the odds, GIST does not kill ideas upfront, does not favor management ideas, and does not pick the most pitched or politicized ones (GIST Framework). That keeps the decision about what to build tied to evidence instead of to who argued hardest in a meeting.

Rank by evidence

Ideas are prioritized with ICE: Impact, Confidence and Ease. Gilad credits the method to Sean Ellis and treats Confidence as the check on the other two, because Impact and Ease are guesses whose reliability depends on the evidence behind them (ICE Scores). His Confidence Meter gives low confidence to opinions and higher confidence to data and test results (Product Discovery With ICE). He warns against teams that invent ideas, score them and then build whatever ICE tells them to; the score picks what to test next.

Think big, start small

Gilad takes the phrase "Think Big but Start Small" from Google's pillars of innovation. Turning a promising idea into a project of many months is, in his words, a common and costly mistake, so the idea is split into small step-projects run one at a time, such as a mockup, then a prototype, an MVP, dogfood, a beta and finally a launch (GIST Framework). Each step puts a more complete version in front of more users for longer (Building Your Project for Learning and Execution).

Every layer stays agile

Gilad's point about Agile is that it fixed the project waterfall but left the planning waterfall in place. In GIST, ideation, planning and execution happen at the same time, and every part of the plan is revisited on a regular schedule. The task layer needs no change from what agile teams already do. What changes is that the goals, ideas and steps above it can now move as well (GIST Framework).

The team owns the path

Goals set direction, and the team picks the ideas and steps that pursue them. In the original article the team chooses the goals and ideas it will pursue each quarter and defines step-projects to match (HackerNoon copy). The goals are the constraint, and the choice of solution stays with the people closest to the evidence. Where leaders keep choosing the solutions themselves, GIST turns into a roadmap with new labels.

The plan is visible to everyone

Gilad writes that the whole planning system should be visible to anyone in the company and to the board. He reports that coworkers and board members readily understand the language of goals, ideas and step-projects and appreciate its realism (HackerNoon copy). Visibility is also what lets a team drop a failed idea without a political fight, because everyone saw the evidence.

How the Model Has Evolved

GIST has changed between the original article and the book. The core four layers are the same, but the names and the validation guidance have grown.

AFTER stands for Assessment, Fact-Finding, Tests, Experiments and Release-results (book resources). Gilad's earlier validation article describes the first four as a ladder, from quick internal assessment and fact finding through user tests to controlled experiments, and argues that most ideas should be rejected or parked at the cheap end. The book, published September 18, 2023, also covers scaling GIST across teams and adopting it in an existing company (book page).

Steps

1. Set outcome goals Define a small number of goals that describe outcomes for users and the business, each with a metric, a current value and a target. Gilad's original article sets goals at the start of the year for a horizon of a year or more and adjusts them every quarter. OKRs are the usual format, and each key result should be measurable and verifiable. Check each goal by asking whether it would still make sense if the first idea for reaching it failed. If it would not, the goal is really a solution.

2. Open the idea bank Collect ideas for each goal in one place, usually a spreadsheet or a simple database, and welcome ideas from anyone: research, customers, managers, the team and analytics. Gilad's rule is that no idea is killed upfront, and a bank can hold hundreds of ideas indefinitely. Link each idea to the goal it serves. Keep a short description and the reasoning, so the idea can be judged later by someone who was not in the room.

3. Triage and score ideas with ICE Give each new idea a quick Impact, Confidence and Ease estimate, spending only a few minutes on each, and sort the bank by the result. Score Confidence from the evidence you actually hold, however much people like the idea. Move the most promising ideas to a short candidate list and park the rest. The score tells you what to test next. Step-projects decide what gets built.

4. Pick this quarter's working set At the start of the quarter, choose the handful of ideas per goal the team will pursue and put them on the GIST board. Gilad suggests picking a small working set for each key result and leaving everything else in the bank. The team makes this choice, with the goals as the constraint. Write down why each idea was chosen, because that reasoning will be tested.

5. Break each idea into step-projects Plan the first step for each chosen idea as a small experiment with a clear question, a success measure and an end date, and keep every step within Gilad's limit of ten weeks. Start with the cheapest validation that could change your mind, such as a data check or a fake-door test, and move to prototypes, betas and A/B tests only if the idea still looks good. Write down what result would make you continue and what would make you stop. Each later step puts a more complete version in front of more users.

6. Run tasks in your existing sprints Break the active step into tasks and run them on the team's usual Scrum or Kanban board. Nothing about sprint planning or daily standups has to change. Keep each task linked to its step, idea and goal, so anyone can see why the work exists. Gilad places the task board to the right of the GIST board so work flows left to right.

7. Review the board and update it Every week or two, walk the GIST board from left to right with the team. Update ICE scores with the new evidence, remove failed ideas along with their steps, bring in the next idea from the bank, and plan the next step for ideas that passed. Share the board with managers and stakeholders so they see progress in terms of evidence and outcomes. Record why each idea was dropped so it is not re-proposed without new evidence.

8. Adjust goals each quarter At the end of the quarter, check progress on each goal and adjust targets or retire goals that no longer fit the strategy. Re-score the bank against the updated goals and look through parked ideas for anything new evidence has revived. Look at the process too: whether steps were small, whether confidence scores matched results, and whether the team really chose its own ideas.

When to Use

• A team owns a measurable outcome, such as activation or retention, and does not know which solutions will move it. GIST is designed for exactly this kind of uncertainty.
• The roadmap is out of date within weeks of each planning cycle, and replanning is eating time. GIST schedules change into the plan through regular reviews at every layer.
• Stakeholders keep pushing features and prioritization turns into lobbying. The idea bank and ICE scores move the argument onto evidence and goals.
• The team ships on time but key metrics do not move. Treating each feature as an idea with a step to test it shows which work actually helps.
• Leadership already uses OKRs and wants a way to connect them to daily work. GIST adds the idea, step and task layers under the goals.

When Not to Use

• The solution is known and the work is execution, such as a compliance change, a migration or a contractual commitment. There is no hypothesis to test, so the idea and step layers add overhead.
• Leaders will not separate goals from solutions and keep dictating features. GIST then becomes extra process with no extra autonomy.
• The work is a long, tightly coupled program with fixed external dates and heavy capacity planning, such as hardware or regulated launches. ProductPlan's critique that GIST handles multi-phase initiatives and resource planning poorly applies most here.
• The team cannot measure outcomes yet. Without data on the goal metric, confidence scores and step results cannot be checked, so build the measurement first.