The GIST Board and Outcome Roadmaps
Replace release roadmaps with a living board of goals, ideas, and validation steps that the whole team owns
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 4
- Confidence
- 90%
The GIST Board is the top three GIST layers (Goals, Ideas, Steps) made operational per team: the team's key results on one side, the ideas currently being pursued (with ICE scores), and the next validation steps for those ideas. It is a dynamic, at-least-biweekly working artifact that fills the missing middle layer between high-level roadmaps and low-level task boards — the layer of 'what are we actually trying to achieve and how well are we doing on it.' Paired with outcome roadmaps (commit to outcomes, not dated feature launches), it lets teams operate with far more context and autonomy.
Origin
Created by Itamar Gilad as the tasks/process bridge in GIST, designed to close the gap between the 'planning world' (managers, strategies, roadmaps) and the 'Agile world' (developers moving tickets) that a lone PM-in-the-middle can't reconcile. Outcome roadmaps are Gilad's proposed replacement for release roadmaps, detailed in his book 'Evidence Guided'.
Core principles
- 01The planning world and the delivery world don't understand each other; a lone PM forced to translate roadmaps into perfect backlogs just doesn't work and burns out
- 02Steps are learning milestones, not engineering or design milestones — the product grows in scope as it is validated
- 03Give the team context (goals + why) and they ask fewer questions, need less direction, and do more on their own
- 04Let the team, guided by a PM, use ICE to choose which ideas to test first — ownership beats top-down assignment
- 05Release roadmaps ('launch X by October') compete with and suffocate evidence-guided work; outcome roadmaps ('achieve this outcome by October') preserve it
How to run it
- 1
Set up to four key results per team
At the start of the quarter the team leads define the goals, review them with the team, managers, and stakeholders for agreement, then copy those key results (optionally with objectives) onto the board as the goals column.
Pro tip Keep it to a maximum of four key results — teams cannot deliver on more than that.
- 2
Generate ideas and score them with ICE
Draw from your idea bank or generate new ideas asking how to achieve the key results. Anyone (including managers) can propose ideas, but the team uses ICE — with the PM playing a key role — to choose which to test first.
Pro tip Letting the team pick the ideas, as counter-intuitive as it sounds, produces more ownership and better choices than manager assignment.
- 3
Define and own the validation steps
For each chosen idea, the team together decides which steps will validate it — some done by the PM, some by data analysts, some by user researchers, some by engineers coding or running experiments. Sub-teams own individual steps.
Pro tip Steps can run in parallel, not always sequentially — e.g. usability test with mockups, then with a prototype, then an A/B test for an onboarding-wizard idea.
Watch out Keep steps framed as learning milestones; don't let them collapse into 'just launch the feature and figure it out later.'
- 4
Meet biweekly and keep the board alive
Team leads update the board and the team meets around it at least once every other week to sync: are we still following the right ideas, how are we doing on goals, what are the next steps, what's blocking us. Remove ideas that prove bad or goals that are met, and add new ones.
Pro tip Run outcome roadmaps alongside it — commit to outcomes by date; only when an idea is high-confidence and already tested do you switch to delivery and put a concrete build on the roadmap.
Watch out If people know the goal is to launch a specific thing by a date, 'forget about learning, forget about evidence guided' — dated feature commitments kill the process.
In the wild
Goal: average onboarding time under two days (currently 5.5 days). Idea: an onboarding wizard. Steps: a usability test with mockups, then a usability test as a prototype, then an A/B test — each a learning milestone that grows the build's scope as confidence rises.
→ The team commits not to blindly launch the wizard but to a sequence of validation steps building confidence, altering the plan as evidence comes in.
In many orgs the planning world (managers, PMs, strategies, roadmaps, projects) and the Agile world (developers moving tickets, burning story points) don't see eye to eye, breeding mistrust. The usual fix — a PM in the middle translating roadmaps into perfect backlogs — leaves PMs exhausted with no time for research or testing.
→ The GIST Board supplies the missing middle layer so both worlds share visible goals, ideas, and steps, reducing the translation burden on the PM.
Common mistakes
Committing to dated feature launches on a release roadmap
Telling everyone 'we launch X by October' makes the goal shipping, not learning — it forces a low-confidence idea through regardless of evidence. Use outcome roadmaps that commit to results by date instead.
Framing steps as engineering/design milestones instead of learning milestones
If steps become 'build this, then that,' the team stops validating and just executes; steps must be learning milestones where the product's scope grows only as evidence justifies it.
Is it for you?
Best for
Product teams and PMs stuck between a planning layer and an Agile delivery layer that don't communicate, especially very delivery-focused teams being told only to build
Not ideal for
Teams whose upstream goals or idea-prioritization are still too weak to populate a full board — they may need to start with a lighter step backlog first
From the transcript
“what I call the gist board so it's basically the top three layers of gist the goals are on the right these are just the…”
“this middle layer of what actually are you trying to achieve and how well are we doing on it doesn't exist”
“I would recommend that you let the team pick these ideas”
“it's not uh engineering Milestone or a design Milestone it's a learning Milestone”
“if people know that the goal is to launch that thing by October forget about learning from forget about evidence guided I recommend using outcome…”
From the episode
Becoming evidence-guided
Itamar Gilad (Gmail, YouTube, Microsoft)