How to run a brainstorming meeting with ideas worth exploring
A brainstorming meeting helps a group come up with and develop possible answers to a specific problem. A good one leaves a visible set of ideas, the assumptions behind them and a next step for testing the best ones.
Start with a question that leaves room for options
Frame the session as an open question, not a choice between fixes you already have. Say a training team is preparing an online workshop. Don't ask which reminder email to send.
Ask: “How could we help registered attendees arrive ready to take part?” That opens up the materials, the invitations and the opening activity. Name the real constraints, like the date and prep time.
Atlassian's mindmapping play works the same way: start with a central question, link related thoughts, then pick the ideas worth exploring. A plain shared document works too when you don't need a visual map.
Bring the right people
Invite people with different views, and give everyone the same short context note so nobody starts behind. For the workshop example, that means:
- A facilitator.
- Whoever sends the invitations.
- Whoever answers attendee questions.
- If you can, an attendee.
Share the evidence, not your favorite fix
Share a few real examples of the problem, such as unanswered prep questions or confusing invitation wording. Don't present your favorite fix as the problem. Say up front whether the session only produces ideas or whether someone will pick an experiment at the end.
A 45-minute agenda you can adapt
Starting with solo writing gives everyone a chance to get an idea down before the discussion starts.
| Time | Activity | Useful output |
|---|---|---|
| 5 minutes | Clarify the question, evidence, and constraints | A shared problem statement |
| 7 minutes | Write possible approaches independently | Ideas before group discussion |
| 13 minutes | Share, clarify, and connect ideas | An organized set of alternatives |
| 12 minutes | Examine a few candidates against agreed criteria | Assumptions and trade-offs |
| 8 minutes | Choose an exploration step and an owner | A testable next action |
Example: turn a good idea into a small test
The workshop group comes up with four ideas and spells out what each one assumes. Those assumptions are questions to check, not reasons to drop the ideas.
They score the ideas against prep effort, value to a first-time attendee and fit with the schedule. The sample exercise wins: it's cheap to make, and its assumption is easy to test. Two colleagues new to the workshop will try a draft.
Can they understand the task without a facilitator? Maya drafts it by Wednesday; Leon collects the readers' questions.
| Idea | What it assumes |
|---|---|
| A prep checklist | People can find it before the session |
| A sample exercise | Attendees can understand it without a facilitator |
| A short welcome call | Attendees have another free slot |
| A clearer invitation | The invitation is where people get confused |
Judge ideas fairly and in the open
Don't judge ideas while people are still generating them. IDEO's brainstorming rules start with deferring judgment and list critiquing ideas too soon among the biggest brainstorming mistakes.
When it's time to evaluate, use criteria tied to this problem: prep effort, value to a first-time attendee and fit with the schedule. Ask what each idea needs before calling it easy. A vote shows interest, not feasibility.
Keep the ideas you set aside, with the reason. “Needs a mailing-list change we can't finish this week” says more than “rejected.” If the group can't choose, name the missing evidence and who will get it.
Follow through before booking another brainstorm
Post a short record somewhere shared, so someone who missed the session understands why the next step exists:
- The problem statement.
- The ideas, including the ones set aside and why.
- The chosen experiment and its owner.
- The next check-in.
Learn before you brainstorm again
Review what the test taught you before generating more ideas. If the team already knows the options and needs to commit, hold a decision meeting instead. If the problem needs specialist investigation, bring in that expertise. Brainstorming can't prove technical feasibility or settle a factual dispute.




