How not to run a brainstorm: 5 mistakes to avoid

Things to avoid for a successful brainstorm

Elena Borisova
3 min readNov 14, 2021

The principle is old and simple — by bringing more people into ideation, you get more perspectives and a higher chance of solving your problem in a better way. And you’ll improve the team’s motivation along the way: when people contribute to idea generation, they are way happier contributing to implementation.

Despite doing brainstorms frequently, we find ways to mess them up. Here’s a list of mistakes I’ve made and seen repeated while running and participating in dozens of brainstorms.

1. Having a topic that is too broad or too narrow

A generic prompt like “How do we make our landing page better?” triggers more questions than ideas (“hm, where do I start? What’s better? And how do we even know it needs improvement?”). It leaves analytical participants paralyzed while the creative ones go astray.

On the other hand, watch out for the situation when your question already implies the right solution and doesn’t leave space for diverging (e.g., “How do we show items users recently searched for?”)


To narrow the problem down, focus on a specific user problem. To keep it broad, make sure you’re discussing the problem itself, not a particular solution. For the two examples above this might look like “How can we help users pick up where they’ve left off?”

Not sure where to start? Here are some ideas on how to figure out users’ needs or problems.

2. Not limiting the number of participants’ ideas

People have limited attention and mental capacity. After discussing the first 20 ideas, everyone is tired, bored, no one cares anymore, and when is the lunch break already? Participants start rushing through neither properly considering ideas nor having discussions.


  • Limit number of ideas per person
  • With 8+ people, split into smaller groups

3. Not having a discussion

Discussion is arguably the most valuable part where people can build up on top of each other’s ideas. It gets neglected either due to lack of time or lack of understanding. What often happens is when one person starts commenting on someone’s idea, someone else intervenes with something around “We’re brainstorming, no judgment!”. While going wild and suspending judgment is great for ideas generation, a discussion will help to clarify and refine them.

Real magic happens when people build up on each other ideas


  • Plan the time for discussion upfront
  • Explain why it’s good

4. Making all the decisions by voting

If you’re making decisions democratically, you might end up with Trump.

Unless you’re working in a very homogeneous team or on a well-known topic, some participants have more context, expertise, or responsibilities for the outcome than others. If a business owner is the one to take all the downside of the project, their vote should have more weight. For a technical decision, technical team members should have more weight¹ and so on. Though implementing this is messy and complicated, there are two practical ways to make decisions in brainstorming results:

  • Run the very basic impact/effort exercise together with the team
  • Let a decision-maker decide, but keep prioritization criteria transparent and be open to re-negotiate. Most commonly, it looks like this: product owner runs everything through prioritization matrix with impact, confidence, effort, etc., and makes it visible to the team via, say, Google Sheets.

5. Not making decisions at all

While diverging part of brainstorms got a lot of publicity and popularity, the converging part is often ignored completely. All the ideas, no matter how insane or impossible, end up in the backlog, and no one knows what to do next. While this problem is the flip side of the previous issue, the remedy is the same.

Running a brainstorm is easy. Running a good one requires just a bit more effort and practice.

[1] Funny thing though, you see plenty of cross-functional teams voting on product decisions but very few on technical ones



Elena Borisova

Combining data and psychology for product and design decision-making | Head of Design at DeepL |