A good brainstorm produces more options than a team can pursue. That is the point. Trouble starts when the raw list is treated as either a vote tally or a backlog. Similar ideas remain scattered, popular suggestions look more certain than they are, and quieter ideas disappear before anyone checks what they could teach.
An idea shortlist is a bridge between generating possibilities and choosing what to test. It does not declare a winner. It shows which ideas currently fit the agreed problem, what support exists, and what the smallest useful test could be.
Keep idea generation and selection separate
During brainstorming, people need room to add incomplete or unusual suggestions. Evaluation at that moment can narrow the conversation too early. After the session, however, every idea needs enough structure for a fair comparison.
Start from the original notes rather than memory. Keep the source wording nearby, including questions and objections. If the session was recorded with permission, use the relevant moment only as a reference; do not turn casual remarks into commitments. The purpose is to preserve context, not to create false authority.
Turn each suggestion into an idea card
One line on a whiteboard rarely says enough. Give every distinct suggestion a small card with five fields:
- Idea: a neutral name that describes the action.
- Problem link: which part of the agreed problem it addresses.
- Source note: the workshop comment or observation behind it.
- Open question: what is still unknown.
- Smallest test: the least expensive way to learn something useful.
Do not improve the idea while transcribing it. If the source is vague, mark the gap. “Create a better welcome experience” is not yet the same as “place a volunteer greeter at the entrance.”
Merge duplicates without erasing useful differences
Read the cards and group those that aim at the same change. Two notes may use different language but propose the same mechanism. Others may sound similar while solving different moments in the experience.
For example, “send an itinerary before the event” and “let attendees save sessions” can sit in a planning cluster. A lobby greeter belongs elsewhere because it helps after arrival. Keep the original notes under the cluster so the team can see what was combined. If a difference changes the test, keep separate cards.
Check three criteria, not a single score
A weighted score can look precise even when the evidence is thin. For an early shortlist, three plain-language checks are usually enough:
- Relevance: Does the idea address the problem the team agreed to work on?
- Support: Is there an observation, request, or constraint behind it, or is it mainly a hunch?
- Testability: Can the team learn something meaningful without building the full solution?
Label each criterion supported, unclear, or not supported yet. These labels expose missing information. They do not pretend to measure value to a decimal point.
A worked example: choosing ideas for first-time attendees
Imagine a fictional community-event team. Its agreed problem is: first-time attendees struggle to choose a session and often ask for directions after arriving. The workshop produced six notes:
- color-code the session tracks;
- offer a personalized itinerary;
- place a volunteer greeter by the entrance;
- make a five-minute orientation video;
- put a QR map on the check-in card;
- send text reminders before each session.
The team first separates planning from navigation. It then checks its notes. Repeated questions about room locations support the greeter and QR-map ideas. There is less evidence that people want reminders. A personalized itinerary may be relevant, but it is not the quickest way to learn whether clearer choices would help.
The shortlist becomes two tests:
- Navigation test: place one volunteer at the entrance for the first hour and record the categories of questions asked.
- Planning test: give a small group a one-page, color-coded track guide and ask them to choose a session before arrival.
The QR map, orientation video, itinerary, and reminders remain in the record. They are deferred because the first two tests can clarify the need more quickly—not because the other ideas are permanently rejected.
Record why an idea moved forward or stayed behind
Every shortlisted idea should have a one-sentence rationale. Every deferred idea should have a next question. This prevents the next meeting from repeating the same debate.
A useful note might read: “Shortlisted because arrival questions are documented and a one-hour greeter test is reversible.” A deferred note might read: “Revisit reminders after we learn whether session choice or wayfinding is the larger problem.” When the team makes a final choice, move that result into a decision log.
Copy this idea-shortlist template
Agreed problem:
Idea cluster:
Source notes:
Relevance: supported / unclear / not supported yet
Support: supported / unclear / not supported yet
Testability: supported / unclear / not supported yet
Smallest useful test:
What we expect to learn:
Shortlist status: shortlist / defer / needs clarification
Reason:
Next checkpoint:If the shortlist comes from a learning workshop rather than a product session, use the same structure to choose one small practice experiment. This workshop debrief workflow shows how to carry one idea into real work.
Run a final fairness check
Before sharing the shortlist, ask four questions. Were duplicates merged consistently? Did a senior speaker's idea receive extra weight without extra support? Did the group preserve objections and uncertainty? Can someone trace each shortlisted test back to the notes?
Then take five ideas from one permitted brainstorm. Merge the duplicates, add one evidence line and one smallest test to each, and shortlist two. The result should make the next learning step clearer without pretending the team already knows the answer.
