GIST Framework Thinking Fills the Gap AI Just Made Wider
Itamar Gilad built the GIST framework at Google to stop teams from shipping opinions. On Stacked Sessions he explained why it matters more now that AI lets everyone ship faster.

The GIST framework (Goals, Ideas, Steps, Tasks) exists to close one specific gap, the space between the roadmap managers watch and the Jira board teams work from, where nobody is checking whether an idea is any good. AI has made that gap wider, because every artifact on both sides of it can now be generated in minutes.
Itamar Gilad, author of Evidence-Guided and a product manager on Gmail at Google for years, joined me on Stacked Sessions to walk through it. Here is the short version.
Output maxing is the new feature factory
Gilad's word for the current moment is output maxing. Roadmaps, PRDs, backlogs, specs and code all come faster with AI, so it feels like teams are more effective. Code generation stopped being the bottleneck a while ago. Then the work ships and everyone hopes. We have argued before that the PRD was never the point, and faster documents only make that more true.
"It's launch and pray."
His numbers on how that goes are blunt. Across A/B experiments, usage data and historical roadmap reviews, one successful launch in three is the best case. One in two is lucky. One in seven or one in ten is common.
The safety net is supposed to be launch and iterate, but most roadmaps leave no room for iteration, and nobody wants to stand up after a celebrated launch and say it needs another round. So the project gets called a success and the team moves on.
What the GIST framework actually is
GIST breaks product work into four layers. Mind the Product has a longer walkthrough of Gilad's original version, and he publishes GIST boards and templates for teams that want to try it.
Goals describe the change you want in customer, business or system behavior. Gilad wants these anchored to a metrics tree that starts with a North Star metric measuring value delivered to customers, sitting alongside the business metrics. The more those two trees overlap, the healthier the business model.
Ideas are hypothetical ways to hit a goal. There is always more than one, and they live in an idea bank rather than a roadmap.
Steps are how you build an idea and test it at the same time. This is where discovery and experimentation live, and it is the layer most organizations skip entirely.
Tasks are the work tracked in Kanban and Jira. Gilad's view is that teams already manage this layer well, arguably too well.
"The focus of the teams is intently on the tasks, while the focus of the managers is on the roadmaps. There's this huge gap between these two things. And no one is actually working towards validating the ideas."
He built GIST from what he saw at Google. Google Plus was the cautionary tale, a massive company-wide bet made on conviction that pulled Gmail, YouTube and Search into integration work and missed the shift to mobile social apps. Gmail's tabbed inbox was the counterexample, developed through the experimental habits that were part of Google's original DNA.
How evaluation and validation work inside GIST
The steps layer runs two activities against the idea bank.
Evaluation is a fast, systematic first pass. Gilad uses ICE scoring, which asks three questions of each idea. How much will it move a specific goal? How easy is it, in person-weeks? How much evidence supports it? For that last one he scores against his Confidence Meter, which weights a customer test far above a strong opinion. Done honestly, a lot of ideas get parked here, which he counts as a good outcome.
Validation puts surviving ideas to the test, starting cheap. A model on paper, a conversation with an expert, a stakeholder risk check, then data, then early versions in front of customers. Each round produces evidence that feeds back into the ICE score. More ideas get parked. The ones that survive go to delivery with real odds behind them, and the iteration that used to happen awkwardly after launch happens before it.
His point on the cheap end matters most. Many teams only know how to build a late-stage MVP, which he describes as a beta by another name. Wizard of Oz tests, concierge tests and fake door tests teach you most of the same things for a fraction of the cost. They also produce the evidence that keeps specification quality high once an idea does reach the build step.
Why cheap AI code does not retire the GIST framework
The argument Gilad hears most often now comes from smart people. Development is cheap, so skip evaluation and launch everything.
His answer is that evaluation was never about the cost of code. Every wrong feature bloats the product, confuses users, complicates the UI and has to be maintained forever unless you are disciplined about killing things. AI-generated code adds its own version of that bill in comprehension debt. Unless you have Google's or Amazon's balance sheet, throwing things at the wall is an expensive way to learn.
He is equally clear that GIST does not replace product taste. It pairs human judgment with evidence, the way medicine and law do. He made the same case at length in Lenny's Newsletter. It also changes the politics:
"When you go to a meeting with someone more senior than you, with opinions, that person will always win. Once you have evidence, you're empowered to actually have a much more constructive discussion."
And AI helps here too. Gilad sees it strengthening every block of the cycle, from strategy and goal setting to research synthesis, honest ICE scoring and running validation tests. The faster your build loop gets, the more valuable a fast learning loop becomes, which is part of why we think product managers should get closer to the code rather than further from it.
Where to start with the GIST framework this week
Gilad's top tip is to avoid a big-bang transformation, because process fatigue kills adoption. Pick the weakest layer and fix that one. If idea selection is the weak spot, he recommends pushing more of it down to product teams, which only works when the PM to engineer ratio gives PMs room to run validation.
- Audit your last two years of roadmap. Count how many "must-have" items actually moved a metric. Gilad says the number is surprisingly low, and it is the data that gets executives to listen.
- Pitch it in business terms. Skip the methodology talk. Say the team is likely wasting half its development effort and missing better opportunities as a result.
- Run ICE on the next five ideas in your backlog. Be strict on confidence. Park anything with no evidence behind it.
Frequently asked questions
What does GIST stand for?
GIST stands for Goals, Ideas, Steps and Tasks. Itamar Gilad created it as an evidence-guided product development framework, drawing on his work at Google.
How is the GIST framework different from a roadmap?
A roadmap commits to a list of features. GIST commits to goals, keeps ideas in a bank, and only promotes an idea to delivery once validation steps have produced enough evidence.
What is ICE scoring in GIST?
ICE stands for Impact, Confidence and Ease. Teams score each idea against a specific goal, with confidence based on the strength of evidence rather than how strongly someone believes in it.
Does AI make the GIST framework unnecessary?
No. Cheaper code lowers the cost of building, but the cost of shipping the wrong thing (product bloat, user confusion, permanent maintenance) stays the same. AI can speed up evaluation and validation instead.
How should a team start adopting GIST?
Find the layer that hurts most, often goals that measure output or ideas picked by opinion, and fix that first before moving on to the next layer.
Jeff Keyes is Field CTO at Allstacks and host of Stacked Sessions, where he talks with product and engineering leaders about how software actually gets built. Find Itamar Gilad's free GIST templates and ebooks at itamargilad.com.
Decide what is worth building before it gets built. Allstacks Product Studio pressure-tests ideas and specs with reviewers focused on different concerns and grounds them in your delivery data. See how Allstacks Product Studio works.
Table of contents
/ get started /


