So, you are about to pull together a team of eight to twelve people into a brainstorming session; do not make the mistake that 90% of us make…no area of focus.  Most teams will be given the challenge of to “quickly come up with a product idea.” The results can be predicted; poor to none when it comes to creating any form of disruptive ideas.  This week on Killer Innovations, we will talk about four steps to better brainstorm problem statements.

Brainstorming

When you pull together a team for brainstorming, creating focus is critical.  When I say “creating focus” I mean that you need to tell the brainstorm team:

Who has the problem?

What exactly is the problem?

Why is it important to solve?

In full or multi-day brainstorms, I have the teams develop their own problem statement.  I set aside between four to eight hours to create a proper problem statement. Do no scrimp on this; spend the time!  A well-defined focus via a well thought out problem statement will generate more and radically better ideas when you are ideating. The core elements have to address one of the following:

Solve a problem.

Remove a barrier.

Improve an experience.

And while you try to answer all of this remember:

Need to be concise.

Does not state or imply a solution.

Specific enough to be solvable in the given time frame and with available resources or competencies.

Sounds hard doesn’t it?  Thus, why I spend four to eight hours crafting, testing and validating a problem statement before I bring the team together.  

Good and Bad Problem Statements

I have a few different templates I use for creating problem statements:

The (what/problem) affects (who/customer) the result of which (why/importance).

(Who/customer) is affected by (what/problem), the result of which (why/importance).

So, what are the steps that would allow you to create a well-defined problem statement?  The first step is to brainstorm the problem!  Ask for people to list problems, challenges, friction in the system, barriers and unmet needs.  The second step is to have each individual answer the “who, what, and why” we talked about earlier in the show.  Step three is to then take the answers and start to draft problem statements using the templates. Then repeat the “who, what, and why”, drafting multiple versions of the problem statements.  Step four is to test it with the “who”, the target segment.

Testing Your Problem Statement

Once you have a version of the problem statement that you think works, you need to test it with others.  Never use yourself as a proxy; you are too close to it. You test it by writing it out, editing it, simplifying it, and making it tight and concise.  Then find and talk to the people who you believe have the problem. Then ask them a set of questions to validate the problem and problem statement:

Is this (team’s hypothesis) a problem for you?  Why or why not?

What problem would be solved for you if the problem was fixed?

How frequently does the problem cause a problem for you?

What value would you gain if this problem was solved?

Now that you have a problem statement, I would recommend sharing it with the team for the brainstorm as “homework.”  Have the think about the problem statement and ask them to answer the validation questions from the perspective of the individuals who would receive the benefit from the brainstorm.  If you would like your team to learn how to run radically better brainstorms by writing better problem statements then I would suggest you host a one-day