Defining Measurable Product Goals in GIST

Define measurable product goals for GIST planning: outcome-based goals with a metric, baseline, target and date that anchor ideas, steps and tasks.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

Measurable product goals are the top layer of the GIST Planning Framework, and every other layer depends on them. Itamar Gilad describes goals as the company strategy stated through desired outcomes: where we want to be, by when, and how we will know we got there (GIST Framework). When someone asks why a piece of work exists, a goal should answer. Ideas, step-projects and tasks are all judged by whether they move it.

The main discipline is keeping goals about outcomes. Gilad points out that strategy plans often prescribe solutions, such as adopting a technology or entering a market, instead of setting goals, and he borrows the military principle of telling people where to go but not how to get there. An outcome-based product goal leaves the solution open. "Increase the share of new accounts that complete setup in their first week" is a goal. "Launch the setup wizard" is an idea, and belongs in the idea bank.

GIST goals usually take the form of OKRs. Gilad writes that he learned goal setting at Google, where teams spelled out quarterly goals as Objectives and Key Results. A key result should be specific, time-bound, measurable and verifiable, as the What Matters OKR guide puts it. In GIST the key results are what the GIST board tracks, with the target value next to the current one (The GIST Board).

The goal layer also has the longest horizon. In the original article, goals look a year or more ahead, are defined at the start of the year, and are evaluated and adjusted every quarter so the team does not chase stale goals (HackerNoon copy). The output of this skill is a short goal sheet: a few goals, each with a metric, a baseline, a target, a date, an owner and a line on why it matters.

How It Works

Gilad's later work adds structure above team goals. In Evidence-Guided he recommends two top-level metrics: a North Star Metric for the value the product delivers to customers and a Top Business Metric for the value the business captures (book resources). His article on true-north metrics gives North Star examples such as messages sent for WhatsApp, minutes watched for YouTube and nights booked for Airbnb, and argues the two top metrics should rise and fall together. A write-up of his Mind the Product talk describes the same split between impact metrics such as revenue and outcome or North Star metrics.

Team goals connect to those top metrics through a metrics tree. The top metric is broken into the drivers that produce it, and each team picks the branch it can influence. A team working on onboarding might own the share of new users who reach first value. The tree shows why that metric matters to the business and stops two teams from optimizing against each other.

A measurable goal then needs four parts. The metric says what is measured and how. The baseline is the current value over a stated period. The target is where the team wants the metric to be. The date bounds the attempt. Without a baseline a target is a guess, and without a date nobody can tell whether the goal was missed or is still in progress.

Choosing the metric is where most goals go wrong. Leading metrics, which the team can move within a quarter, work better at team level than lagging ones such as annual revenue, which depend on sales, pricing and the market. Vanity metrics, such as signups that never activate, are easy to move and say little. A good test is to ask what the laziest way to hit the target would be. If that path would hurt users or the business, add a guardrail metric or rewrite the goal.

Goals also shape the idea space. A goal that is too narrow, such as a click-through rate on one button, admits only a few ideas. A goal framed around a user outcome admits many, which matters because most ideas fail. Gilad writes that at most 1 in 3 ideas deliver a positive result (GIST Framework), so a goal that allows only a handful of ideas leaves the team few chances to succeed.

Finally, goals stay stable while the layers below them move. Ideas are added and dropped weekly and step-projects change every sprint or two, but a goal changes only at the quarterly review, or when strategy changes. That stability is what lets the team experiment freely underneath it.

Step-by-Step Guide

Step 1: Gather the strategic inputs

Collect the company strategy, any top-level OKRs, the North Star and business metrics if they exist, and recent customer research. Note the problems and opportunities each input points to. If strategy is only stated as solutions, such as "build a mobile app", ask what outcome the solution is supposed to produce and write that down. That outcome is the raw material for a goal.

Step 2: Find the metrics your team can move

Sketch the metrics tree from the top metric down to the drivers your product area influences. Mark the metrics your team can move within a quarter through product changes. Drop metrics that depend mainly on other teams or on the market. Keep a short list of candidates, each with a clear definition of how it is calculated.

Step 3: Establish baselines

Pull the current value of each candidate metric over a stated period, and note how much it normally varies. A target means little until you know where the metric stands and how noisy it is. If a metric cannot be measured reliably yet, make instrumenting it the first piece of work instead of setting a goal on it.

Step 4: Choose a few goals and set targets

Pick the small number of goals the team will actually pursue, and write each one with its metric, baseline, target and date. Set targets that are ambitious but plausible given the baseline and the trend. Give each goal an owner. Add one sentence explaining why the goal matters, linked to the top metric it feeds.

Step 5: Stress-test each goal

For each goal, ask how the target could be hit in a way that hurts users or the business, and add a guardrail metric where needed. Check that the goal describes an outcome and does not name a solution. Check that it is broad enough to allow several different ideas. Rewrite any goal that fails these tests.

Step 6: Align with stakeholders

Review the draft goals with leadership and neighboring teams before the quarter starts. The questions to settle are whether the goals serve the strategy and whether any team's goal conflicts with another's. Agree who approves the goals, and confirm that the team chooses the ideas that pursue them. Record changes and the reasons for them.

Step 7: Seed the idea layer

For each goal, write down the ideas people already have for reaching it and put them in the idea bank as hypotheses. Seeing several possible ideas per goal is a useful check that the goal leaves room for choice. If every idea for a goal is the same feature, the goal is probably a solution in disguise.

Step 8: Publish the goals and schedule reviews

Put the goals on the left of the GIST board with current and target values, and share them with the team and stakeholders. Schedule the quarterly review where goals are evaluated and adjusted. Update the current values on the board at each weekly or bi-weekly review so progress is always visible.

Best Practices

• Keep the number of goals small. Each goal needs ideas, steps and attention, and a team spread across many goals makes little progress on any of them.
• State every goal as an outcome. If the sentence contains a feature name, move the feature to the idea bank and ask what it was meant to achieve.
• Record the baseline and its normal variation. Without them, nobody can tell whether a change is real or noise.
• Pair a primary metric with a guardrail. A growth target with a quality or retention guardrail closes off the easiest ways to game it.
• Tie team goals to the top metrics through the metrics tree, as Gilad recommends in Evidence-Guided. This keeps local goals from drifting away from what the business needs.
• Review goals quarterly and leave them alone in between, following the original GIST cadence. Changing goals every few weeks makes the experiments underneath them meaningless.

Common Mistakes

• Writing a feature as a goal: "Ship the new dashboard" commits to a solution before any evidence exists. Rewrite it as the outcome the dashboard was supposed to produce and put the dashboard in the idea bank.
• Setting a target with no baseline: A target of a given rate means very different things depending on where the metric starts. Measure first, then set the target.
• Choosing a metric the team cannot move: Company revenue or market share depends on many teams and on factors outside the product. Pick the driver in the metrics tree your team actually influences.
• Too many goals: A long goal list spreads the idea bank and the steps thin. Cut to the few that matter most this period and say explicitly what is not a goal.
• Ignoring gaming: A goal on signups alone invites low-quality signups. Add a guardrail and check it at every review.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: GIST Planning Framework

Related Skills

• Building a Product Idea Bank for the GIST Ideas Layer
• ICE Scoring: Prioritizing Product Ideas by Confidence
• GIST Planning Cadence: Managing Multi-Cadence Cycles
• Replacing Your Product Roadmap with GIST

Sources

• Itamar Gilad: GIST Framework
• HackerNoon: the original GIST Planning article
• Itamar Gilad: The GIST Board and Other GIST Tools
• Itamar Gilad: The Three True-North Metrics
• Itamar Gilad: Evidence-Guided book resources
• Mind the Product: The GIST Framework by Itamar Gilad
• What Matters: OKR meaning and definition

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.