Paul Henderson asked me to put together a blog post on a "recipe" for a Reverse Brainstorming session. At this point I assume that you already know that the purpose of the session is to generate lots problems, not solve them. That is, we are NOT interested in solutions, only problems matter: the more, the better.
Depending on project goals, the session can range from spontaneous and simple to carefully planned and strategically oriented. The session should have two distinct parts: problem generation (divergent action) and problem selection (convergent action).
Today's post is about the first part.
1. Core concepts.
The two key principles of regular brainstorming (as developed by Alex Osborn in the 1930-50s and refined in the 1980-90s by Tom Kelly of IDEO, apply here:
- 1.1. Quantity beats quality, i.e. the number of problems generated is more important than their perceived quality. The target for the session is 100 problems in one hour. I'll talk about how to state a problem later in the post. You'll be surprised how many people don't know how to formulate a problem statement.
- 1.2. No criticism allowed during the session. None at all. Statements like, "Oh, this is not important", or "We can't do that" are strictly prohibited. For just one hour, all judgments are suspended.
In addition to these, Reverse Brainstorming adds two more:
- 1.3. No solutions are allowed during this stage. Since the quality of problems is unknown, it's not worth everybody's time to discuss solutions.
- 1.4. Commonly accepted trade-offs are treated as primary sources of problems. A trade-off is a a good indicator of "in-the-box" thinking, i.e. a set of unstated assumptions and imitations, which must be exposed and questioned. Exaggerate typical situations to see how and when the trade-offs begin to fail.
General comments for moderators:
a) As a Reverse Brainstorming moderator or a group lead, you should help the group to move forward by applying improvisation techniques. For example, rather than stopping to ponder a newly stated problem or dismiss its bad wording, write it down, say, Yes, and ask the group to expand and/or exaggerate the situation (see 1.4. above). Keep moving. Remember, you have no more than 30-45 seconds per problem statement.
b) Assume that participants may not know how to formulate a problem statement. One reason is our background education: we are taught to come up with solutions, not problems. Another reason might be one's poor communications skills, especially among technical staff. Technologists often know their subject inside out, but have trouble expressing their understanding in common terms.
In addition to that, you need to be aware that in certain cultures, both corporate and ethnic/regional, one is not supposed to point to a problem directly, but rather describe it in a roundabout way.
Finally, having lots of problems may make participants feel insecure and they can try to avoid mentioning problems altogether.
To address these issues, help your group to move from vague, generic statements about the world, to more specific "bad" situations and unfulfilled functions. Explore the consequences. Often, a vague feeling of discomfort is an indication of a host of problems. Don't let vagueness proliferate further.
A bad problem statement: Money (as in "We don't have money") or Traffic ( as in, "The traffic is bad").
A slightly better problem statement: We don't have enough money to buy a helicopter to fly to work in the morning.
An even better problem statement: My morning commute
sucks takes a lot of time.
Related problem statement: I can't do anything useful while driving the car.
Related problem statement: Phone conversations, reading, and texting are useful, but they distract from driving and increase the probability of an accident.
Related problem statement: Even a small accident on the freeway clogs traffic for miles.
etc.
Not knowing something is also a good source of problems. For example, acknowledging "We don't know what our customers need" ( a real case from one of my consulting engagements) is an important step for a sales and marketing organization. Often, these problems go unstated and therefore unresolved.
c) [Optional] You can improve the quality of the session, by exploring higher level trends prior to it. Sending materials the day before and a 5-10-minute summary before the session is ideal. The goal is help participants see the world in the background and pull them a little bit out of their specialization boxes. Ask your participants (ideally, they should be a multi-disciplinary bunch) to put together a one(!) slide summary for each trend. If this is impossible, prepare the slides yourself or mention striking examples of change in different areas before the session.
Example trends to explore:
- Technology [e.g. projections for storage and processing power in cloud computing services].
- Demographic [e.g. an increasing number of retirees in the developed countries].
- Market/Economic [e.g. post-recession consumer spending patterns].
- Financial [e.g. availability of loans for business expansion; IPO prospects].
- Geographic [e.g. regional preferences for mobile applications in North America vs Europe vs Asia]
- Business [e.g. increasing/declining competition; shifts in corporate culture; changing availability/pricing of a key resource].
- Environmental [e.g. global warming, global cooling, pollution, loss of privacy, etc.].
d) [Optional] Familiarize yourself and, if possible, your participants with De Bono's Six Thinking Hats. The key is to realize that problems can come from different sources and in different flavors: Analytical (White), Emotional(Red), Negative(Black), Positive(Yellow), Counter-factual(Green), Combo/Orchestration(Blue).
People tend to be strong in one or two thinking styles. You should help them increase their creative flexibility by asking questions under various "colors". Sometimes, if it's not too much work, you may assign a specific color to a person or the whole group.
2. Logistics
2.1. Group composition.
- Multi-disciplinary groups of five to seven people are ideal. Even when you do a session for engineers, try to bring a person from marketing, or support, or find engineers who are involved in different aspects of the product/servce. Groups of more than 8-10 people don't work. If you have to have 12 participants split them in two groups (at least for problem generation). Bigger groups generate fewer problems per person. Remember principle number 1 stage: Quantity beats Quality.
- Unless it is really inappropriate or disruptive, having a mixed gender group helps. Try to avoid all-male or all-female situations.
2.2. Session duration.
- Problem generation: no more than one hour. As I said before, 100 +/- 15 problems with 30-40 seconds per problem statement is a good target.
- 10-minute break
- Problem selection: 30 minutes for evaluation, e.g. the betting game; 30 minutes for ranking and discussion.
- [Optional] Problem clustering: 30 minutes.
- Wrap-up, next steps: 15 minutes.
2.3. Supplies
- Two flipcharts, either a tabletop or with a stand, per group.
- A room with enough wall (window) space to hang 10-15 flipcharts sheets.
- Permanent markers to write on flipcharts
- Masking or scotch tape to hang flowchart sheets on the wall(s).
- Two (different colors, e.g. red and yellow) 2x2 sticky notes per participant.
- A pen and/or pencil per participant.
- Projector, whiteboard, etc. for a joint discussion (per group).
- [Recommended] Spreadsheet software to tabulate the results.
- [Recommended] Fruits, red and yellow colors preferable, and drinks.
To be continued...
