Stop Brainstorming!
In the DSD course it was time to think about solving the problem at hand. The obvious knee-reflex is to brainstorm. We decided not to.
Brainstorming is great, and it has its place as a collaborative ritual in design work (see an old blog post of mine about brainstormings as wedding rituals). However, brainstorming is often done without proper preparation, without a clear objective, and without paying attention to the mindset of the participants.
Even if brainstorming is “done right”, there is one major problem with it.
Brainstorming steers for social cohesion
And the problem with that is that a group of people most often tend to end up with a consensus rather than the best alternative.
In other words, brainstorming is intense group work where the social cohesion of the group is key. “Don’t criticise”, “stay positive”, “build on top of other people’s ideas” are fundamentals of brainstorming. This tends to steer the results towards a solution that everyone is happy with… assuming that this consensus is also the best solution. And this is not necessarily the case.
To make things even worse, a good long brainstorming session strengthens the social ties within the group, and the end result becomes a symbol of this valuable and lovely social bonding. To criticise or throw away the solution easily becomes psychologically an act of tearing apart the closeness and togetherness within the group.
If you think I’m slightly too dramatic or over-reacting, think about one of the main thesis of Lean Startup: validate hypotheses objectively and make sure you are not fooling yourselves. Why is the Lean Startup canon emphasising the problem of falling in love with one’s own ideas? Because group consensus is dangerous if not kept in check.
Falling in love with one’s own ideas as a group is the same as falling in love with something “we created together and bonded like close friends”. This love makes a great workplace and is important in team work, but it distracts the group from objectivity.
Enter the Google Sprint
Therefore, in the DSD course this week, we decided not to brainstorm for ideas. We decided to adapt Google Sprint’s method (Day 2)of letting people come up with a solution individually (via sketching with pretty strict time-boxing and clear steps to follow) and then criticise, discuss & comment them effectively.
People seemed to really appreciate the method, and here are my best guesses why:
- At this stage there was lots of data, information, and knowledge. Letting the participants digest it and create a solution in everyone’s own speed felt really good.
- The briefing (“Describe a service that combines your business goals with what your customers want to become”) and the method forced to think broadly in terms of a full service and customer journey. Typically brainstorming produces individual features or isolated parts of a solution.
- The quiet individual working gave equal ground for everyone. In brainstorming the most extrovert and socially talented can easily dominate the discussions, and especially, the clustering of the work. The individual working and almost anonymous speed critique let the results speak for themselves.
- Simply: the participants had done brainstorming so often that change was welcome :)
Whatever you do, do the homework
All in all, brainstorming is generally speaking ok. The challenge is that the facilitator and the team need to be well aware of the groundwork required to have a good session. And even if everything is done by the book and the team is an experienced one, there is the danger of falling in love with the end result. A good team must be aware of this danger as well, and thankfully the Lean Startup literature reminds us all of this.
However, I recommend trying out the “Google Sprint method”. I have now tried and applied it at least three times in very different ideation sessions, and it works really well. Of course, similar preparation and home work is required to “set the table”, but I feel there is less danger of groupthink and biased results.
