Brainstorming Problem Statements as a Team

Let's say your organization tasks your team to generate a new product or service idea. You gather your team together and get ready to brainstorm, thinking you can't go wrong. Contrary to common thought, when brainstorming problem statements, things can go wrong. Often, teams will jump into brainstorming sessions, forgetting a vital step of the process. This step is known as the area of focus.

When it comes to assembling your team to brainstorm problem statements, developing the area of focus is beyond critical. As a team leader, it is essential to explain a few key things to your team. Firstly, you need to explain who has the problem. Secondly, it is crucial to lay out what the problem is. Lastly, you explain why the problem is essential to solve.

Elements of A Good Problem Statement

When brainstorming problem statements, a set timeframe will help a team put all their energy and attention into creating that area of focus. This time is vital because a well-defined focus from a solid problem statement will generate more and better ideas. A well-thought-out problem statement either solves a problem, removes a barrier, or improves an experience. Don't forget that problem statements need to be concise without implying or stating a solution.

It is also crucial that they are specific enough to the point where they are solvable by your organization within that timeframe. This process is not easy. As a result, I spend four to eight hours crafting, testing, and validating a problem statement.

Generating As A Team

There are a few key steps needed when successfully brainstorming problem statements. Firstly, you need to get together and brainstorm the problem. This step includes gathering a list of problems and challenges, any organizational friction or barriers, and unmet needs within the organization. The second step is to have your team answer the "what, who, and why." Thirdly, you need to take the gathered data and plug it into one of the templates to generate the problem statement.

Next, repeat the "who, what, and why," drafting multiple versions of the problem statement. Lastly, test it with the "who," or your organization's target segment. Once you have a version of the problem statement you think works, test it with others. The test is best done by writing it out and making it concise. Like I always say, never use yourself as a proxy. Next, ask your organization some questions to validate the problem and problem statement. Once validated, you are ready to present your problem statement to your team so they can begin brainstorming.