Agile Design Methods
  • Blog
  • Methods
  • Resources
    • Online Course
    • Mobile App
    • Public Course
  • Contact Chuck
  • Search

What's the Problem? Exactly.

10/13/2017

0 Comments

 
Picture
A problem statement depicts the moment of opportunity when a transformational solution would make all the difference in a particular person's quality of life.
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.

Why a Problem Statement Is Important

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.

Problems Lead to Solutions

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.

How To Create a Problem Statement

Here is an effective way to create a statement that expresses an understanding of the context and the problem so that it informs and influences solution designers and architects. 
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).

How To Create an Ideal Solution Statement

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.

Practical Application

​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.

Want More?

​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.
0 Comments

The Open-Ended Question That Opens People Up

7/21/2017

0 Comments

 
Picture
When asked authentically, this three-syllable question creates connectedness, trust and understanding with anyone, even a person you have just met.

This matters because empathy, the ability to understand and share the feelings of others, is an essential ingredient in the process of designing solutions for people.

How can we understand how others are feeling unless we ask? Asking the question unlocks the potential to observe problems that would otherwise go unobserved. This is a gold mine of understanding for solutions designers.


"How's Your Day?"

So, I routinely ask this question of people because:
  • It comes from a place inside of me that truly cares about people
  • It informs my understanding of how people in the world around me are experiencing the world around me

​So often, our daily existence and interactions are framed by disconnectedness and distrust. Asking this question to someone else is so counter-cultural. Consequently, it produces a measurable shift in the environment and it creates a sense of trust and connectedness.

One of my favorite contexts to ask the question is while getting things done on the phone, standing in line or chatting online.
In the past week I can recall asking the question of people in the following contexts:
  • while waiting for a seat at a restaurant
  • while interacting with a benefits coordinator for my health care company
  • while chatting with a tech support staff member online
  • while going through the check-out line at the grocery store
  • while talking with relatives who live far away from me
  • while transacting business over the phone
We exist in a world characterized by disconnectedness and distrust.

Consequently, introducing a countercultural question produces a measurable shift in the environment and it builds trust and connectedness.

Try It and See

Understanding how people in the world are feeling is easy. Just ask them. They'll tell you. Listen to them and learn what problems they are experiencing. It will inform your design decisions.

When the woman you are talking with senses that you care enough about her to ask how her day is going, it breathes fresh life into the conversation, even if she is having a bad day. Somehow when you care enough to ask, it reaffirms her humanity and causes her to reflect on how she's feeling.

If we, as solutions designers, practice this kind of authentic caring, listening and learning on an ongoing basis, we tap into a limitless supply of priceless insight for free by simply exercising a common courtesy towards another person.

Your empathy for people and willingness to be vulnerable enough to go there immensely affect your solution design.

- Chuck


Subscribe to my free blog updates that contain 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 get a lot of benefit from it.
Learn the Secrets of Successful Agile Designers
0 Comments

The Downside of How Geeks Describe the World

6/9/2017

0 Comments

 
Picture
"Start with Why" is widely espoused as the ultimate stake-in-the-ground for designing any solution or any change. Who can argue with this? It's a great place to start.

Describing why leads to describing what is needed and for whom. Ultimately, describing what leads to describing how it will be designed. Why leads to What, Who and How.

Starting this discovery conversation quickly leads to a predictable set of statements that are helpful in describing what is ultimately motivating the change and for whom:
  • We need [some notion of a solution described here] so that we [experience a benefit described here]
  • I want [some notion of a solution described here] so that I [experience a benefit described here]​
Nestled in each of these statements is a description of the motivation for the envisioned change or needed solution. The envisioned end result exists to bring about some desired future state.

Captain Obvious stuff, for sure. However, my guidance is directed at the more fledgling officers who so easily and routinely fall into the following easily avoidable pitfall.

Beware: The Pitfall of Using Solution Language

How this works out practically is easily described by way of example.

Consider the following statements:
  1. We need a new iPhone app so that we engage our mobile market better.

  2. We need a way of interacting with our potential and existing customers so that we have the opportunity to be connected with them anywhere at any time.
When motivation statements are framed in design elements (e.g., iPhone, mobile, buttons) the solution design effort risks veering into a pitfall because describing "how" is not the same as understanding "why".
Now, consider the following cross-checking questions as it pertains to these statements:
  • Which statement is more durable?
  • Which would be just as valid ten years from now as it is today?
  • Which one assumes a solution?
  • Which one has a clearer statement of benefit?

Now, imagine you are a solutions designer trying to solve for one statement or the other.

Exactly.

A designer's choices are severely limited by statement #1 whereas statement #2 leads to further exploration in discovering important notions that drive design clarity:
  • Who are the people in the market?
  • What are some representative personas we can create so that we can design for them?
  • What would the ideal solution look like for each of those personas?​

Understanding "Why" Matters More Than Describing "How"

When motivation statements are framed in design elements (e.g., iPhone, mobile, buttons) the solution design effort risks veering into a pitfall because describing "how" is not the same as understanding "why". 
​

Describing "how the solution is to be built" in the early stages of learning and discovery disrespects two critically important voices in the solution conversation;
  • Users
  • Solution Designers
Don't disrespect users and solution designers by leading them by their respective noses to your envisioned solutions.
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.
Free Updates by Email
0 Comments

    Learn the Art of
    ​Successful Agile Design

    Picture

    About Chuck Boudreau

    (boo'-dro) - I help people design solutions collaboratively using agile design methods. I have 30+ years of experience in designing software solutions and business processes, leading cross-functional process improvement teams as a business analyst, and helping product managers define and position products using Pragmatic Marketing. I am passionate about user experience design, dog training, beating drums in musical ensembles and collaboratively creating solutions with people.

    Chuck's Resume
    File Size: 67 kb
    File Type: pdf
    Download File



    Archives

    April 2018
    March 2018
    February 2018
    January 2018
    November 2017
    October 2017
    September 2017
    August 2017
    July 2017
    June 2017
    May 2017

    Categories

    All
    Agile Design
    Boredom
    Collaboration
    Connecteness
    Conversational Framework
    Design Insights
    Design Specification
    Design The "What"
    Documentation
    Empathy
    Environment
    Facilitation
    Feature Lists
    Future State Design
    Glossary
    Ideal Solution Statement
    Leadership
    Learning And Discovery
    Marketing
    Meetings
    Observation
    Pitfalls
    Problem Statement
    Requirements
    Scribe
    Solution Design
    Solution Designers
    Solution Development
    Solution Marketers
    Success Criteria
    Tips And Techniques
    Trust
    Use Cases
    Users
    User Stories
    Velocity

    RSS Feed

© 2016-2023 Chuck Boudreau | Privacy Policy

Photo used under Creative Commons from Sasquatch I
  • Blog
  • Methods
  • Resources
    • Online Course
    • Mobile App
    • Public Course
  • Contact Chuck
  • Search