Gist planning

GIST is a planning framework developed by Itamar Gilad that structures product work into four hierarchical layers: Goals, Ideas, Step-projects, and Tasks. Unlike traditional roadmaps that commit to specific features quarters in advance, GIST emphasizes continuous evaluation based on evidence, allowing plans to adapt as learning occurs.

The framework structure

Goals define what you're trying to achieve, typically expressed as measurable outcomes. Rather than "build a mobile app," a goal might be "increase weekly active users by 30%." Goals should be ambitious but achievable, and they provide the context for evaluating everything below them.

Ideas are potential ways to achieve goals. For any given goal, many ideas might contribute to it. Ideas should be stated as hypotheses: "We believe that adding social sharing will increase weekly active users because users will invite friends." At this level, ideas are cheap-the framework encourages generating many possibilities.

Step-projects break ideas into small, testable increments. Rather than building a complete feature and hoping it works, step-projects let you test the idea progressively. The first step-project might be a fake-door test or prototype; later step-projects add functionality based on what earlier ones learned.

Tasks are the familiar work items: specific activities to complete step-projects. This is where traditional project management and sprint planning operate.

Why gist exists

Traditional product planning often fails in predictable ways. Roadmaps commit to features months in advance based on opinions and assumptions. When those assumptions prove wrong-as they often do-teams either continue building the wrong thing or face disruptive replanning.

GIST addresses this by:

Connecting work to outcomes - Every task traces back through step-projects and ideas to a goal. This prevents the common problem of shipping features that don't move metrics that matter.

Treating ideas as hypotheses - Rather than debating whose idea is best, teams test ideas and let evidence decide. This reduces politics and increases learning.

Enabling continuous adjustment - Because step-projects are small, teams can change direction based on what they learn without abandoning large investments.

Maintaining long-term focus - Goals provide stability and direction even as the specific path shifts based on learning.

Putting gist into practice

Setting Goals - Goals should connect to business objectives and be measurable. The OKR framework works well here: Objectives provide direction, Key Results provide measurement. Review goals quarterly; they shouldn't change frequently, but they should evolve as business context shifts.

Generating Ideas - Collect ideas continuously from customer feedback, competitive analysis, team brainstorming, and data analysis. Store them in an idea bank without immediate commitment. Each idea should include a hypothesis about why it might achieve its goal.

Prioritizing Ideas - Use evidence-based scoring rather than opinion. The ICE framework (Impact, Confidence, Ease) works here. Critically, Confidence should be low for untested ideas and increase only as evidence accumulates. This prevents over-investment in unvalidated assumptions.

Designing Step-projects - For top ideas, design the smallest step that could provide meaningful evidence. The first step-project for a new feature might be customer interviews, a landing page test, or a prototype-not the full implementation.

Executing Tasks - Within step-projects, normal project management applies. Sprint planning, Kanban, or whatever execution approach the team uses handles the day-to-day work.

Gist vs. traditional roadmaps

The trade-off is complexity. GIST requires more infrastructure-idea banks, scoring systems, experiment tracking-and more discipline than simply maintaining a feature list. For some teams and products, simpler approaches work fine.

Common challenges

Goal setting is hard - Vague goals ("improve user experience") provide no guidance. Goals need to be specific enough to evaluate ideas against.

Idea overload - Without discipline, the idea bank becomes a graveyard. Regular review and pruning keeps it useful.

Step-project discipline - The temptation to skip validation and build the full feature is strong, especially under pressure. Teams need to hold the line on evidence requirements.

Stakeholder expectations - Executives often want commitment to specific features and dates. GIST requires educating stakeholders about why outcome commitments are more reliable than feature commitments.

When gist fits

GIST works best when:

For products with clear requirements and low uncertainty-regulatory software, contractual obligations, infrastructure-simpler approaches may suffice. GIST adds value primarily when you need to learn your way to the right solution.

Tools like Klero support GIST-style planning by connecting customer feedback to ideas and goals. When ideas emerge from real user input and you can trace feature requests back to customer segments, the evidence basis for prioritization becomes stronger.