GIST planning did not replace OKRs at Google. That framing has followed the framework around for years, and it gets the relationship exactly backwards. GIST uses OKRs. The Objective and Key Results you already write sit at the top of GIST as its Goals layer. What GIST adds is the part OKRs never covered: a disciplined way to decide what to build, test those bets cheaply, and connect all of it to daily engineering work.
Itamar Gilad built GIST while he was a product manager at Google, drawing on Lean Startup, agile development, and evidence-based decision making. He named it for its four levels: Goals, Ideas, Steps, and Tasks. The framework has spread well beyond Google since, and in 2024 Gilad expanded the thinking into a full book, Evidence-Guided: Creating High Impact Products in the Face of Uncertainty. If you have only ever seen GIST described as an OKR killer, this is the version worth understanding.
The four levels, and how fast each one moves
The reason GIST holds together is that each level runs on its own clock. Strategy changes slowly. Daily work changes constantly. Most planning systems break because they try to force both onto the same cadence, which is why a twelve-month roadmap is stale the week after you publish it. GIST separates the timescales on purpose.
Goals describe where you want to be, by when, and how you will know you got there. Gilad writes these as OKRs. You set them roughly yearly and review them each quarter.
Ideas are hypothetical ways to hit those goals. New features, redesigns, pricing changes, growth experiments. These are collected continuously and never stop flowing.
Step-projects break an idea into experiments, each no longer than about ten weeks. You define them at the start of a quarter and reprioritize them every week or two as results come in.
Tasks are the bite-sized activities that implement a step. This is your existing sprint board and kanban. GIST changes nothing here, which is part of the point.
So goals move on a yearly-to-quarterly rhythm, ideas are always open, steps turn over every one to two weeks, and tasks run in normal sprints. Each layer is agile at its own speed instead of one giant plan pretending the future is knowable.
Where GIST came from, and the roadmap problem it attacks
Gilad’s frustration was specific. A traditional feature roadmap, he argued, is “outdated the day I published them.” It commits a team to a fixed sequence of features months out, which quietly turns an agile team back into a waterfall one. Worse, it forces you to prioritize ideas before you have any evidence about them, so the features that survive tend to be the ones with the most senior person behind them rather than the ones most likely to work.
That last point is the uncomfortable one. On most roadmaps, the loudest stakeholder wins. GIST is a deliberate attempt to replace that dynamic with a testing loop, so ideas earn their place by producing evidence rather than by who proposed them. If you have read the case for a now, next, later roadmap, GIST is a more structured cousin of the same instinct: stop pretending you can schedule discovery.
Goals: this is where your OKRs live
Here is the correction stated plainly. In GIST, the Objective of your OKR is the Goal, and the Key Results are the measurable targets you track on the board. GIST does not compete with OKRs. It gives them somewhere to go.
Gilad is specific about one discipline that trips up most teams: do not stuff initiatives into your OKRs. Keep the OKRs about outcomes you want (activation rate, retention, revenue) and push the “how” down into the Ideas layer. The moment a key result becomes “ship feature X,” you have smuggled a solution into your goal and lost the ability to change your mind about how to hit it. If your OKRs currently read like a feature checklist, that is the first thing to fix, and it is a common enough failure that it deserves its own diagnosis.
Goals sit on the left of a GIST board as key results with a target value and a current value, so anyone looking at it can see the gap the team is trying to close.
Ideas: build a bank, stop killing ideas early
The Ideas layer is where GIST diverges most sharply from how teams usually operate. Gilad’s premise is grounded in a number he cites often: only about one idea in three delivers a positive result. Even strong product teams are wrong most of the time.
If two out of three ideas fail, then front-loading a decision about which idea to build (the roadmap move) is close to guessing. So GIST says: stop killing ideas at the proposal stage. Collect them all in an Idea Bank, a running list that never gets deleted. An idea that looks weak today might become obvious after next quarter’s data. An idea that looks brilliant might die in its first test. The bank keeps both alive until evidence, not opinion, decides.
Each quarter you pull a handful of ideas from the bank onto the board to work on. The rest wait. Nothing is lost, and nobody has to win a debate to keep a suggestion on the table.
Step-projects: the ten-week experiment ladder
An idea is a hypothesis, and you test a hypothesis in stages that get more expensive as confidence rises. This is the heart of GIST and the part teams most often skip.
Instead of committing to build the whole idea, you break it into step-projects, each capped at roughly ten weeks. Gilad describes a progression that climbs from cheap and fake to real and shipped: mockup, then prototype, then MVP, then dogfood, then beta, then full launch. Each step is a real experiment with a result. If a step fails, you stop and you have spent weeks, not two quarters. If it succeeds, you graduate to the next, more expensive step with more evidence behind it.
The mechanism is the ladder. You are always spending the smallest amount of build effort that will produce the next piece of evidence. A mockup can kill a bad idea for the price of an afternoon. Only ideas that keep surviving cheap tests earn the right to expensive engineering.
How ideas get ranked: ICE and the Confidence Meter
If you are not scheduling by seniority anymore, you need another way to decide which ideas get worked on. GIST uses ICE scoring: Impact, Confidence, and Ease. Score each from one to ten, and the ideas with the best combined score go first. It is deliberately rougher than RICE, because at the idea stage precision is false comfort.
The Confidence in ICE is where Gilad added something genuinely useful, a tool he invented at Google to end circular debates: the Confidence Meter. Instead of arguing about how sure you feel, you tie confidence to the strength of your evidence on a fixed scale. The weakest evidence barely counts. The strongest is worth hundreds of times more. His hierarchy, from weakest to strongest, runs roughly like this:
- Self-conviction (“I just believe in it”): 0.01
- A pitch deck or aligned strategy: 0.03 to 0.1
- Other people’s opinion (experts, investors, press): 0.1 to 0.2
- Estimates and business cases: 0.4 to 0.5
- Anecdotal evidence (a few interested customers): 0.5 to 1
- Market data (surveys, smoke tests, competitor signals): 1 to 3
- User evidence (20+ interviews, usability studies, an MVP): around 3
- Test results (A/B tests, longitudinal studies): 4 to 5
- Launch data from a live production system: 10
The gap between the top and bottom is the whole point. “I believe in it” scores 0.01. A real A/B test scores 4 or 5. When you multiply those into a prioritization score, a strongly held opinion with no evidence gets divided into near-irrelevance, while a tested idea gets amplified. It is a numeric way of saying that data outranks confidence, and it works precisely because the numbers are lopsided enough to settle arguments.
What is new since GIST first spread
If you learned GIST from a blog post around 2018, the framework itself has not changed, but the thinking around it has matured. Gilad’s 2024 book Evidence-Guided reframes GIST as one part of a larger evidence-based operating system rather than a roadmap replacement you bolt on. The book walks through choosing the right outcomes, prioritizing ideas with ICE and the Confidence Meter, and building and learning at pace. Practitioner summaries and templates for the GIST board now exist across most planning tools, from Miro and Airtable to purpose-built boards in Fibery and Draft.io.
The through-line of the newer material is a softer sell on the mechanics and a harder sell on the mindset: the framework matters less than the habit of demanding evidence before you commit engineering time. GIST is the scaffolding. Evidence is the load it carries.
Where GIST gets hard in practice
Having watched planning systems succeed and fail across two decades of operations work, the honest caveat is this: GIST is easy to draw and hard to live in. Three failure modes come up repeatedly.
The first is that the Idea Bank becomes a graveyard. Collecting every idea is only useful if you actually pull from the bank and test things. Plenty of teams adopt the board, love the tidiness of it, and never run a real experiment. The mockup-to-MVP ladder is the engine, and without it GIST is just a nicer-looking backlog.
The second is that leadership keeps treating steps as commitments. The whole model depends on a step-project being allowed to fail and stop. If an executive sees “prototype pricing change” on the board and starts telling customers it is coming, you have recreated the roadmap problem inside GIST. The framework needs air cover for experiments to genuinely be experiments.
The third is confidence theater. The Confidence Meter only works if people score honestly. It is trivially easy to label a hunch “market data” to push a pet idea up the list. The number is a discipline, not a formula, and it degrades the moment a team games it.
None of these is a reason to skip GIST. They are the reasons to adopt the whole thing rather than the parts that are comfortable. Take the board without the experiment ladder and you get organization without learning. Take the goals without the OKR discipline and you get a feature list wearing a strategy costume. The value is in the coupling: outcomes at the top, an honest bank of ideas in the middle, cheap tests that climb toward expensive commitment, and a confidence score lopsided enough to make evidence win the argument.
That is the framework Gilad actually built. Not a replacement for OKRs, but the missing machinery that turns them into shipped product.
Sources: Itamar Gilad, “Why you should stop using product roadmaps and try the GIST Framework”; Itamar Gilad, “The GIST Board and Other GIST Tools”; Itamar Gilad, Evidence-Guided: Creating High Impact Products in the Face of Uncertainty (2024); The GIST Framework, Mind the Product; Confidence Meter evidence hierarchy via Votito.