Building a Product Idea Bank for the GIST Ideas Layer

Run the GIST planning ideas layer with a product idea bank: collect ideas from anyone, link each to a goal, triage quickly and park instead of delete.

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

The idea bank is the working tool of the GIST planning ideas layer. In the GIST Planning Framework, ideas are hypothetical ways to achieve a goal, and Itamar Gilad asks teams to collect all of them in an idea bank, most commonly a spreadsheet or a database, where every idea is welcome and the bank can hold hundreds of ideas indefinitely (GIST Framework). A product idea bank replaces the feature backlog. Gilad's summary of the framework lists "idea banks rather than product backlogs" as one of its principles.

The reason for keeping every idea is that nobody can reliably tell good ideas from bad ones in advance. Gilad writes that at most 1 in 3 ideas deliver a positive result, and that the ideas of experienced leaders, product managers and designers do no better than average. The paper he cites, Online Experimentation at Microsoft, reports that only about 1/3 of ideas improved the metrics they were designed to improve. So GIST never kills ideas upfront, never favors management ideas, and never picks the most hyped or politicized ones. It keeps them, ranks them by evidence, and tests them in order.

This makes idea management continuous. Gilad's article says ideas are constantly collected and prioritized and that the team never stops looking for new ones (HackerNoon copy). Continuous product ideation, in this sense, is less about brainstorming sessions and more about giving every source of ideas a place to put them: customer research, support tickets, sales calls, analytics, managers and the team itself.

The output of this skill is a working idea bank: one list per goal, with a status for each idea, a short hypothesis, a source, a rough ICE score and a record of any evidence gathered. It feeds the ICE scoring skill, which decides what to test, and the step-project design that follows.

How It Works

Gilad's article on ICE scores describes how he structures an idea bank by status. Untriaged ideas are new ones from research, management, customers, the team, analytics, brainstorms and anywhere else. Candidates are the most promising ideas at the moment, typically no more than 30-40 of them. Parked ideas are the ones that did not make the cut, and that list can be as long as needed and hold ideas indefinitely. A small working set holds the ideas the team is pursuing this goal cycle, and he gives picking 3-5 ideas per key result as a typical case. Strategic ideas, which are very large or take the company outside its core business, get a status of their own.

Group the bank by goal. Each idea is written as a hypothesis linked to the goal it is meant to move. An idea with no goal cannot be scored for impact, so it is either linked to an existing goal or parked with a note until a goal makes it relevant.

Triage is deliberately quick. Gilad advises shallow assessment for new ideas: guesstimates, back-of-the-envelope calculations and easy data lookups, spending no more than a few minutes on each idea (ICE Scores). Triage gives each idea a rough ICE score and a status. Deeper evaluation is saved for candidates that are close to being tested.

Parking matters as much as selecting. Parked ideas are kept, even ones that look bad, because they come back. When someone proposes an idea again, the bank shows the earlier assessment and any test results. Gilad suggests going over the parked list every few months to remove duplicates and promote anything that now deserves to be a candidate.

The bank connects to the rest of GIST through the GIST board. Only the ideas chosen for the current quarter appear on the board, with their current ICE score, and the rest stay in the bank (The GIST Board). When a step-project produces evidence, the idea's score is updated on the spot, failed ideas leave the board, and the next candidate from the bank takes their place.

A good bank entry is short but complete: a title, a one or two sentence hypothesis in the form "if we do X, metric Y will move because Z", the linked goal, the source, the submitter, the date, the status, the ICE score, and a link to any evidence. The hypothesis form forces the submitter to name the mechanism, which makes the Confidence score easier to judge.

Step-by-Step Guide

Step 1: Set up the bank's fields

Create one shared spreadsheet or database with the fields above, plus a status column using Untriaged, Candidate, Working set, Parked and Strategic. Add one view or tab per active goal. Keep the form short enough that anyone can add an idea in a couple of minutes. A bank that is hard to add to stays empty.

Step 2: Seed it with existing ideas

Gather ideas that already exist: the old backlog, feature requests, notes from customer interviews, sales asks and ideas people have been lobbying for. Rewrite each as a hypothesis linked to a goal. Do not filter at this stage. Getting everything into one place is what makes the ideas comparable.

Step 3: Link every idea to a goal

Go through the seeded ideas and attach each to the goal it would move. Ideas that serve no current goal go to Parked with a note, and are not deleted. If many good ideas have no goal to attach to, raise it at the next goal review, since the goals may be missing something.

Step 4: Triage with a rough ICE score

Give each idea a quick Impact, Confidence and Ease estimate, spending only a few minutes per idea as Gilad suggests. Record where the Confidence came from, even if the answer is "opinion". Move the most promising ideas to Candidates and park the rest. Keep the candidate list short enough that the team can actually discuss it.

Step 5: Open the bank to everyone

Tell the company where the bank is and how to add an idea. Set the norm that new ideas go into the bank instead of into meetings or direct asks to engineers. Thank people for submissions and show them where their idea landed. Visible treatment of submissions is what keeps people using the bank.

Step 6: Run a weekly intake

Once a week, triage everything that arrived as Untriaged. Merge duplicates, link ideas to goals, give each a rough score and a status. Update the scores of ideas that got new evidence from research or step-projects. Keep this routine short so it survives busy weeks.

Step 7: Choose the working set each cycle

At the start of each goal cycle, pick a small working set of candidates per goal to put on the GIST board and design step-projects for. Use the ICE ranking as the starting point for discussion. Record why each idea was chosen, so the reasoning can be checked against results later.

Step 8: Review parked ideas periodically

Every few months, go through the parked list. Remove duplicates, close ideas that are clearly obsolete with a note, and promote any idea that new evidence or a new goal has made more promising. Look for patterns: themes that keep coming up are often a sign of a real user problem.

Best Practices

• Write every idea as a hypothesis with a mechanism. "If we add X, Y will improve because Z" is easier to score and test than a feature name.
• Keep ideas, do not delete them. Gilad's rule is that the parked list holds ideas indefinitely, so earlier assessments and test results can be found when an idea returns (ICE Scores).
• Record the source of each idea. Ideas from customer research and ideas from a hallway conversation carry different evidence, and the source helps set Confidence.
• Treat management ideas the same as everyone else's. Gilad's GIST article is explicit that GIST does not favor management ideas.
• Show only this quarter's ideas on the board. The bank holds everything, and the board shows what the team is working on.
• Keep triage fast and save deep analysis for candidates. Spending an hour on every new idea turns intake into a bottleneck.

Common Mistakes

• Treating the bank as a backlog: A backlog implies a commitment to build. An idea bank holds hypotheses, and most of them will never be built. Keep the language and the status values honest about that.
• Deleting weak ideas: A deleted idea comes back without its history. Park it with the reason, so the next person who proposes it can see what was already learned.
• Letting the bank rot: Without a weekly intake, untriaged ideas pile up and people stop submitting. A short, regular routine matters more than a thorough one.
• Orphan ideas: Ideas with no linked goal cannot be scored for impact. Link them or park them, and use a pile of orphans as a signal to review the goals.
• Lobbying around the bank: If people still get ideas built by asking an engineer directly, the bank loses its purpose. Route every idea through it, including the ones from leadership.

References

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

Related Skills

• Defining Measurable Product Goals in GIST
• ICE Scoring: Prioritizing Product Ideas by Confidence
• Designing Step-Projects to Validate Product Ideas
• GIST Planning Cadence: Managing Multi-Cadence Cycles

Sources

• Itamar Gilad: GIST Framework
• HackerNoon: the original GIST Planning article
• Itamar Gilad: ICE Scores, All You Need to Know
• Itamar Gilad: The GIST Board and Other GIST Tools
• Kohavi et al.: Online Experimentation at Microsoft

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