As a solution designer or marketer, tuning into the context and experience of a person in a predicament is fundamental. There is no side-stepping around these questions:

• Who is experiencing the problem?
• ​When and under what circumstances does the problem happen?
• How would they describe it in their own words?     (super important)
• How does it make them feel?     (also super important)
• How does it affect their quality of life?

​A cogent, well-crafted problem statement answers these questions and provides clarity of context to solution designers and product marketers.

A problem involves a person in the context of a specific predicament. The problem is the raison d'être for any solution under consideration and, by extension, the gold for which the solution designer is mining.

A person experiencing a problem expresses it through emotion. Describing the circumstances causing their feelings in their words, however strong or subtle, provides a foundation of empathy to design an ideal solution. It is essential to recognize the emotion because it produces the personal resonance of the problem context, effectively influencing the thinking about the solution design.

​A problem statement depicts the moment of opportunity when a transformational solution would make all the difference in a person's quality of life.

From a marketing perspective, borrowing a concept from Pragmatic Institute, a “market” is a group of people who share the same problem. Therefore, observing, understanding, and clearly describing a problem with resonance is the cornerstone of any solution, making a highly refined problem statement, or set of statements, all the more valuable.

Who needs or uses problem statements?

• Solution designers and architects
  They need to understand the context under which a problem occurs. The more empathy the designer or architect has for the person's experience with the problem, the better.
• A product manager 
  ​They need to identify which problems are urgent and pervasive. That subset of problem statements represents the high-potential candidate problems to research, assess, verify, and build a business case for solving.

A problem statement is a sentence or a small set of sentences that includes these descriptive elements:

1. A description of the person 
   Name or describe the contextual role of the person.
2. When or under what conditions the problem occurs
   Describe the goal they are trying to achieve or when the problem happens.
3. An emotion they experience
   Describe this in words they would use or that you have observed to establish an empathetic connection with the person experiencing the problem.
4. A description of the effect the problem has on their quality of life
   ​Use wording that the person would use in their business or life context.​​

​
​Actual Statements and Mad-Lib Styled Templates
You may be fortunate and can describe the problem statement by simply transcribing what you have observed people say in the context of experiencing an issue. That's a preferable way in which to produce a problem statement.

But, if you don't have that form of recall handy or need some help constructing a statement, then some fill-in-the-blank templates help demonstrate what this looks like.​

To that end, here are some Mad-Lib-styled templates:​
​

• As a       (1)      , when       (2)      , I am       (3)        because       (4)      .
  
  
• As a       (1)      , I am       (2)      , when       (3)        because       (4)      .

​Examples
Here are two examples of problems statements based on conversations I've had and observations I've had in just the past day:

• As an iPhone user, when I can't find my AirPods case, I panic and scramble, looking all over the place, retracing my steps because the darned thing is so easy to lose and would cost me a fortune for me to have to replace.
• As a coach, in a live practice or game setting, when tensions are already high, to begin with, someone lets something denigrating fly out of their mouth to one of the players. At that moment, I’m flustered because I’m supposed to lead here, and I draw a blank on what to say or do. I’m unsure of what to do in response because I’m not experienced in how to handle something like this. Over the long haul, letting this kind of communication go unchallenged affects the team, our institution, our relationships, and our friendships.

Best Practices and Pitfalls to Avoid

• Do use the first person.
• Do use descriptive statements that you have actually observed people saying.
• Do create multiple statements rather than trying to blend various problems into one.
• Do not describe the solution or use solution jargon.
• Do not embellish using false emotion or projection (do keep your BS detector on).

A common pitfall when designing a solution is rushing too quickly into describing how providers should implement the solution. A way to avoid that pitfall is to describe the solution's effect on the person instead of explaining how to solve the problem. 

An ideal solution statement avoids this pitfall by informing and influencing solution designers and architects on what is needed while respecting their role in designing how to solve the solution.​

​An ideal solution statement is a sentence or two that:

• Begins with the phrase, "The ideal solution would..."
• May contain the phrase "so that" or "the ability to"

​Examples
Here are ideal solution statements based on the aforementioned problem statements:

• The ideal solution would provide me the ability to know where my AirPod case is located right now so that I can find it easily.
• The ideal solution would give me the know-how and confidence to respond appropriately in the moment and over the long haul so that values of personal respect and dignity are established and reinforced in our team and in our institution.

​Best Practices to Use and Pitfalls to Avoid

• Do use the first person.
• Do describe the business or quality-of-life improvement delivered.
• Do write the first draft of the statement soon after producing the problem statement because it so naturally flows afterward.
• Do create one ideal solution statement per problem statement.
• Do not describe components of the solution or use solution jargon.

​An ideal solution statement can easily feed into agile development practices in the form of a user story. Developers use user stories in agile solution development to create a backlog for product development.

The user story that is widely practiced in agile communities reads like this:

• As a              I want              so that             .

Here is how our example ideal solution statements can be transformed into a user story that can be used by an agile development team:

• As an AirPods user, I want to know where my AirPods case is right now so that I can find it easily.
• As a sports coach, I want the know-how and confidence to respond appropriately in the moment and over the long haul so that values of personal respect and dignity are established and reinforced in our team and our institution.

In addition to user stories, the problem statement described herein offers a richer contextual insight for solution designers to understand how their envisioned solution user experiences the problem.​

Combining a problem statement with the ideal solution statement increases the potential for designers and architects to empathize with the problem. This insight improves their ability to design a solution that resonates with the intended user.

​It also enhances the ability of a product manager to strategically position the solution in the market, communicating with resonance through marketing channels and sales efforts.

​Subscribe to my free blog updates to receive content that vividly describes the techniques and leadership skills that embody the practice of agile design methods. The blog contains not only my ideas on the topic but the insight of others who actively work and thrive wholeheartedly in the realms of collaborative creativity and solution design.

​I love this classic scene from The Office where the office staff are called into a compulsory meeting to hear the latest blah, blah, blah..

Nobody is paying attention to what is being said. Everybody is so disaffected and bored by these meetings that they gamify them by intently watching the DVD screen saver, all the while anticipating it's perfect landing in one of the corners.

As meeting facilitators, the obligation and challenge is on us to create meetings that are purposeful, well-directed and worthy of the engagement and attention of the attendees.

For further suggestions on effectively scheduling meetings, consider Meyer's Rules of Order

However, in my experience, having a glossary available to collaborators is worth the effort because it serves as an accelerator an work effort accelerator whereas the absence of a glossary causes delays and other negative side-effects.

Here is an approach I use and recommend while facilitating collaborative meetings;  

1. Prepare: Make sure that someone (you or a designated person in the meeting) serves as a scribe to record words and their meanings. When meeting in a room, I suggest having 8" x 6" Post-it Super Sticky Notes and a Sharpie permanent marker available at all times. When meeting virtually online or over the phone, I suggest having the Evernote application open at all times.
   
   
2. Listen: While facilitating the collaborative conversation, listen for concepts or notions that might not be easily understood by others not as invested in the conversation. When the you hear a word or phrase, stop the conversation briefly, "Let's capture that idea as a glossary term."
   
   
3. Record:  Typically there is one person in the conversation who can authoritatively verbalize the glossary term. Have that person state it while the scribe records it.
   
   
4. Confirm: Have the scribe read it back to the group to get confirmation. Record any refinements and then move on with the meeting.
   
   For example, in a recent cross-functional human resources effort, our team came up with these terms. One of them had a single meaning. Another had multiple meanings stated in separate sentenced.
   
   exit interview – A final meeting to collect specific assets from the employee. A survey conducted with an individual who is separating from employment.
   
   involuntary – The condition upon which separation occurs that is not initiated by the employee.
   
   line management – A set of managers in the lower layers of the management hierarchy (e.g., team leader, supervisor) that manage employees who have no supervisory responsibilities.
   
   
5. Publish: Long after the meeting, because you were intentional you now have the corporate memory to reconstruct what was said by publishing the recorded glossary terms in whatever form is appropriate (e.g., appendix in a published document, page on a collaborative website or wiki).

Making your glossary accessible to all stakeholders provides a clarifying reference resource that accelerates understanding and positively affect the progress of your collaborative work effort. I hope this has been a helpful perspective for you.

​- Chuck

Subscribe to my free blog updates to receive content that vividly describes the techniques and leadership skills that embody the practice of agile design methods. The blog contains not only my ideas on the topic, but the insight of others who actively work and thrive wholeheartedly in the realms of collaborative creativity.

​I look forward to you joining us.
​

Designing a solution without knowing what problem you're solving leads to this.

This is classic. I'll let the statement made stand on its own.

​I've been there, done that! How about you?

- Chuck

Subscribe to my free blog updates to receive content that vividly describes the techniques and leadership skills that embody the practice of agile design methods. The blog contains not only my ideas on the topic, but the insight of others who actively work and thrive wholeheartedly in the realms of collaborative creativity.

You just might benefit from joining us.

Users want solutions that cater to them. If you bring them a solution that does not respect who they are, it will not resonate with them and will ultimately not be a viable solution to their problem.

Solution designers want a clear description regarding the problem, who it affects and what the envisioned benefits of the ideal solution entail. Thy need this so that they can define a solution with respect for who it is for and how it affects them. If you bring them a solution statement, you have disrespected their opinion.

Don't disrespect users and solution designers by leading them by the nose to your envisioned solutions.

- Chuck

Subscribe to my free blog updates to receive content that vividly describes the techniques and leadership skills that embody the practice of agile design methods. The blog contains not only my ideas on the topic, but the insight of others who actively work and thrive wholeheartedly in the realms of collaborative creativity.

I hope you'll join us.