The GIST Model
Split product work into Goals, Ideas, Steps, and Tasks so evidence — not opinion — drives what gets built
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 4
- Confidence
- 95%
GIST is a meta-framework that breaks the entire product-building process into four separately-tackleable layers: Goals (what we're trying to achieve), Ideas (hypothetical ways to achieve them), Steps (ways to implement AND validate an idea via build-measure-learn loops), and Tasks (the delivery work managed in Kanban/Jira). Rather than jumping from an idea straight to execution, GIST forces a team to define measurable end states, generate many competing ideas, validate cheaply before committing, and only then deliver. It is designed to move an organization from 'opinion-based development' to 'evidence-guided' product management.
Origin
Created by Itamar Gilad, former long-time PM at Google (Gmail, YouTube, identity), based on his experience watching Google Plus fail as a top-down opinion-based bet while the Gmail tabbed inbox succeeded as an evidence-guided one. Gilad is explicit that GIST is not a brand-new invention — it 'puts in place a lot of existing methodologies... based on Lean Startup, on design thinking, product Discovery, growth' — assembled into one model. Detailed in his book 'Evidence Guided'.
Core principles
- 01Opinion-based development (believe an idea, go all-in, implement) wastes enormous resources building the wrong things; evidence-guided development learns earlier and is faster to real outcomes
- 02The four layers are big changes but each can be tackled on its own — you don't adopt the whole system at once
- 03The principles and frameworks transfer across companies, but the process is the most brittle part and MUST be adapted to each company
- 04Good teams learn AND build at the same time — it's a fallacy that learning means building slowly
- 05Success is measured by time-to-outcome (getting the RIGHT bits to production), not time-to-production
How to run it
- 1
Define Goals as measurable end states
Establish where you want to end up, expressed as metrics, not as a plan of what to build by when. Use overarching company-wide goals (North Star metric + top business KPI) rather than siloed per-department goals that push people in different directions.
Pro tip When people say 'I have goals' but actually discuss what to build, by when, and with what resources, that's planning work — not goals.
Watch out Having many goals or vague/output-based goals is a telltale sign you are NOT actually evidence-guided.
- 2
Generate and evaluate Ideas objectively
Treat ideas as hypothetical ways to reach the goals, sourced from founders, managers, stakeholders, teams, research, and competitors. Evaluate them consistently and transparently (using ICE) instead of via a battle of opinions or highest-paid-person's-opinion.
Pro tip Let the team — not just managers — pick which ideas to test first; it creates ownership and better decisions.
Watch out Cognitive biases convince you your idea is far superior to alternatives when it's almost impossible to predict which idea is best amid market, user, tech, and org uncertainty.
- 3
Run Steps to validate before committing
Break each idea into build-measure-learn loops that grow the product's scope as evidence accumulates. Start with the cheapest validation and only invest more as positive evidence appears.
Pro tip Steps are learning milestones, not engineering or design milestones — you build the product IN the process of validating it.
Watch out Don't build an elaborate 'MVP' that is minimal in no way and only learn after launch — that's just old-style 'beta' with a new name.
- 4
Execute Tasks with an engaged team
Manage the concrete delivery work (tickets, story points, production pushes) in your Agile tools — but bring developers out of the pure-delivery 'cage' so they also participate in discovery.
Pro tip A disengaged, output-only development team is a signal to adopt the tasks layer of GIST and give them discovery work.
Watch out Putting a lone PM in the middle to translate roadmaps into perfectly-prioritized backlogs 'just doesn't work' and burns the PM out on planning with no time for research or testing.
In the wild
Google feared Facebook's growth, created a ~1,000-person division (the size of Android), and connected Gmail, YouTube, and Search to Google Plus over a couple of years. Everyone believed in it, so they went all-in and executed the plan. 'None of it worked' — people didn't need another social network. Gmail rolled back the integration and Google Plus shut down in 2018.
→ Tremendous waste of millions of person-hours; Google also missed easier mobile-social opportunities like WhatsApp and Snapchat. Became Gilad's epitome of opinion-based development.
A small idea nobody believed in. The team researched why passive users lived in inbox clutter, set a user-centric goal, tested rigorously on their own inboxes, then dogfooders, then external testers, and built data-mining and machine-learning teams for categorization — despite most colleagues thinking splitting promotions/social was 'the stupidest idea.'
→ About 85-88% of users love the feature; Gmail has ~1.8 billion active users, most using it — a very high-impact feature born from low confidence in opinions plus heavy evidence.
Common mistakes
Treating the Goals layer as a planning session
Teams take the goals layer and discuss what to build, by when, and with what resources — that's planning, not goal-setting. Goals must paint the measurable end state, or evidence has nothing to guide you toward.
Trying to adopt the whole framework at once
A too-big transformation causes fatigue: you create heavy process for many people, don't see results, and give up after a quarter. Start with the single layer that maps to your biggest current problem instead.
Is it for you?
Best for
Product leaders and PMs at companies emerging into modern product management (they have teams, OKRs, and Agile but can't put it all together) or at companies that were once evidence-guided and regressed after a culture or management change
Not ideal for
Very early-stage startups still searching for product-market fit (building the full metric tree and heavyweight OKRs is overkill) and elite product companies already balancing judgment with evidence well
From the transcript
“goals are there ideas steps and tasks and essentially it's price to break the change which is a really big change for a lot of…”
“goals are about defining what we're trying to achieve ideas or hypothetical ways to achieve the goals steps are ways to implement the idea and…”
“gist is not a brand new invention it's a meta framework that puts in place a lot of existing methodologies it's based on Lean Startup…”
“when people say I have goals usually they they take the goals layer and use it as a planning session”
“it's not about getting the bits to production it's about getting the right bits to production”
From the episode
Becoming evidence-guided
Itamar Gilad (Gmail, YouTube, Microsoft)