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

What's the Problem? Exactly.

10/13/2017

0 Comments

 
Picture
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 these questions:

  • Who is experiencing the problem?
  • What problem are they experiencing?
  • When and under what circumstances does the problem happen?
  • How does it make them feel?
  • 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 target, the raison d'être, for any solution and, by extension, solution designer/marketer.

A person experiencing a problem expresses it through an emotion. Describing the circumstances that are causing that emotion, in words a user would use however strong or subtle, provides a foundation of empathy through which to envision an ideal solution. It is important to not overlook the emotion because it creates personal resonance with the problem and with the solution being marketed.

From a marketing perspective, borrowing a concept from Pragmatic Marketing, a “market” is a group of people who share the same problem. Therefore, understanding and clearly defining the problem is the cornerstone of any solution to be created and/or marketed. This makes a highly refined problem statement all the more valuable.

Who needs a solution statement? Solution designers need to understand the context under which a problem occurs. The more empathy the designer has for the person experiencing the problem the better. Product managers need to know out of all the problem statements that exist, which ones are urgent and pervasive. That set represents the high potency candidate problems for which to design and market solutions.

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 two that contains these descriptive elements:
  1. A description of the person 
    Name or describe the business role or life role of the person.
  2. When or under what conditions the problem occurs
    Describe what goal they are trying to achieve or when does it happen?
  3. An emotion they experience
    Describe this so that an empathetic sense of connection to the person experiencing the problem is established.
  4. A description of the affect the problem has on their quality of life
    Use language that the person would use in their business or life context.​​
​
​Mad-Lib Style Templates
To help demonstrate what this might look like in the abstract, her are some 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 or observations I've had in just the past day:
  • As an iPhone user, when I can't find my AirPod case I panic and scramble looking all over and retracing my steps because they are so hard to locate and costly 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. In 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 first person
  • Do use descriptive statements that you have actually observed people saying
  • Do create multiple statements rather than trying to blend multiple problems into one
  • Don't describe the solution or use solution jargon
  • Don't embellish using false emotion or projection (do keep your BS detector on)

Problems Lead to Solutions

Not all problems have solutions. But every problem has a resolution that can be framed, conversationally speaking, in an ideal solution statement, Any marketing conversation naturally goes towards the solution.

Ideal Solution Statement
An ideal solution statement is an aspirational statement expressed in the language of the person experiencing the problem. It provides a target to aim for in terms of value delivered by a solution.

This typically describes an improvement in the quality of life of the person experiencing the problem who employs the solution. It describes the affect of the solution (what it does) without describing the solution (how it does it).

Who needs an ideal solution statement? This description is very useful target for a solutions designer. It influences product design as they develop candidate solutions that aspire to the expressed value. It provides a marketer with clarity of context and guidance to influence product positioning, persona development, user stories, messaging and other product management deliverables.

How To Create an Ideal Solution Statement

An ideal solution statement is a sentence or two that:
  • Begins with the phrase, "The ideal solution would..."
  • May contains 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 and Pitfalls to Avoid
  • Do use 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 afterwards
  • Do create one ideal solution statement per problem statement
  • Don't 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. User stories are used in agile application development solutions to as a means of creating backlog for product development.

The canonical form of a user story is: As a _____ I want ____ so that ____.

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

  • As an AirPod user, I want the ability to know where my AirPod case is located 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 in our institution.

In addition to user stories, the problem statement described herein offers a richer contextual insight for solution designers to understand how the problem is experienced by an envisioned solution user. The combination of a problem statement and an ideal solution statement creates the potential of designers really connecting with the problem and with an understanding of how to design a solution that resonates with the intended user.

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

Agile Design Notions

9/1/2017

2 Comments

 
A practitioner of agile design maintains a productive environment characterized by high velocity, collaborative engagement and clarity of ideation.

Creating this environment requires intentionality. For your consideration, I offer these notions that I use to influence my practice of leading and facilitating teams using agile design methods.
  • Design "What" before designing "How".
  • Describe "What" using only domain terminology not solution terminology.
  • Defer designing the "How" to solution designers and architects.*
  • Never call a meeting without defining an objective and deliverables.
  • Leave your organizational hat at the door in design meetings.
  • Make design meetings collaborative, kinesthetic, non-digital and visual.
  • We make progress as we write things down. 
  • An idea not captured is an idea lost.
  • Having multiple whiteboards in a meeting room enhances flow.
  • Your smartphone camera is your friend for capturing whiteboard work and moving forward.
  • When the hive stops buzzing, it is time to take a break.****
  • Trust is an accelerator. Fear is an inhibitor.
  • Trust modeled by leaders begets trust in the meeting room.
  • A conversational framework is more important to have during design meetings than a having solution framework.
  • It takes less time to be approximately right than it does to be precisely wrong.
  • Friends develop solutions. Enemies only deliver documentation.*
  • "Tell me more" is a magic phrase that leads to the discovery of real issues/problems.*
  • A market problem always has a significant emotional component to address.*
  • Never ask a question with the answer in mind.
  • As a facilitator, stating what you see is as effective as asking a question of the group.
  • "I don't know" is a safe first response that ultimately must be assigned and answered.
  • Always have a scribe working in the room.
  • People routinely fail at following a process. However almost anyone can immediately perceive when something is out of alignment.**
  • Confusion is costly.***
  • Clarity puts a stop to confusion.

* Pragmatic Marketing
** Paraphrase inspired by Alistair Cockburn
*** Jeff Jones of Bild
**** Gary Evans of Evanetics
2 Comments

Agile Design Methods: A Conversational Approach

8/18/2017

0 Comments

 
Picture
Agile design methods are those techniques and leadership skills that enable a future state design process characterized by high velocity, collaborative engagement and clarity of ideation.

The resulting design is typically produced at a lower cost than traditional methods with a high degree of precision and improved stakeholder engagement and satisfaction.

When considering how to get from understanding a problem to designing and delivering a solution, the process is a predictable set of conversations that inform every step along the way from ideation to delivery.

​Getting "from-concept-to-market" faster and more effectively yields competitive advantage as well as a solution more likely to resonate with the people who will ultimately buy or use it.

The concepts described herein apply whether your field of endeavor is operational excellence or product development.


As an organizational leader facilitating efforts to improve a process or product manager engaging your design team, you face predictable challenges when moving from some vague notion of a concept to actually designing the solution.

Here are some aspects that affect your future state design process:

  • Clarity
    Why are we doing this?
    ​Why does it matter?
    What problems are we trying to solve for and who will buy/use our solution?
    How do the problems materialize in the quality of life of those affected?
    How else does the problem materialize?
    What are the qualities of the ideal solution?
​
  • Velocity
    How do we get the design flywheel started?
    What does progress look like in the early stages of the process?
    How do we create a "fast path" to produce high-quality design deliverables that will inform the designers and architects of the envisioned solution?

  • Engagement
    How do we develop trust and confidence within the design team?
    How do we acquire the whole-hearted participation of the people tasked with designing the solution?
    How do we vet the impact of the envisioned solution with potential buyers/users?

A Solution-Oriented Conversational Framework

So just how does one get from concept to delivery? 

The process for getting there is easily represented as a series of conversations.
"We've got a long way to go and a short time to get there." 

- Jerry Reed
​Early conversations focus on Why and What: 
  • Understanding what the problem is and why it matters, and designing by describing what the ideal qualities of the solution entail, in just enough essential detail.
  • These conversations are enabled via agile design methods that produce specific deliverables intended for decision-makers, stakeholders as well as solutions designers and architects.

Latter conversations focus on How:
  • Designing and delivering the solution.
  • These conversations are enabled by agile development methods that produce specific deliverables intended for decision-makers as well as solutions developers and delivery channel stakeholders.

This approach lends itself to introducing the right conversation at the right time.
Conversation #1: Learning and Discovery

The scope of this conversation pertains to the understanding of the problem. ​This conversation is in scope of agile design methods.​

Allow the voice of the people who are experiencing the problem(s) to inform this conversation. Listen and learn and document that learning to describe what each problem looks like and summarize them in problem statements in addition to statements of what is working well.

Document this learning and discovery conversation to inform the future state design conversation. Decide whether or not to proceed to a future state design conversation.

Conversation #2: Future State Design

The scope of this conversation pertains to the describing the ideal solution. This conversation is in scope of agile design methods.

Allow a dedicated and accountable group of contributors to inform a conversation around describing "what" the ideal solution looks without describing "how" the solution will be implemented. The descriptive language is free from any implementation jargon and focuses on delivering a clear description of the envisioned solution that may include process definitions, key solution deliverables, user experience criteria, risks, issues and opportunities.

Document this future state design conversation to inform the solution development conversation. Decide whether or not to continue to a solution development conversation.

Conversation #3: Solution Development

The scope of this conversation pertains to designing and developing the solution. This conversation is out of scope of agile design methods. 

Allow a dedicated and accountable group of designers and architects to inform a conversation that describes "how" the ideal solution will be implemented. The descriptive language is rich in implementation detail. It may provide design alternatives that provide varying degrees of cost, risk, time, return on investment, etc. Decisions are made regarding design alternatives and leading to the actual development of a solution.

Document this solutions development to inform the solution delivery conversation. This conversation is out of scope of agile design methods.

Conversation #4: Solution Delivery

The scope of this conversation pertains to the delivery and support of the solution. This conversation is out of scope of agile design methods.

Allow a dedicated and accountable group to inform a conversation that oversees the delivery of the solution. This includes launching and promoting the solution as well as supporting it and providing user experience feedback to inform solution improvement efforts.

Agile Design Methods Describe What Not How

Agile design methods are those techniques and leadership skills that enable a future state design process characterized by high velocity, collaborative engagement and clarity of ideation. The resulting design is typically produced at a lower cost than traditional methods with a high degree of precision and improved stakeholder engagement and satisfaction.

The outputs of these conversations intentionally stop short of designing the implementation, They describe what the problems are and what the ideal solution qualities look like. This informs solutions architects and designers who are responsible for determining how to design the solution and the production/development teams that will deliver it.
Picture
Agile Design Methods: The What Perspective
Agile design methods, as quickly as practically possible, describe what is envisioned to be an ideal process or solution. They produce ideation deliverables that describe what the problems are and what the ideal solution qualities look like.

Exercising this type of "Design the What" discipline respects a separation of concerns between the market problem definition and the solution design definition. It informs the solution designers and architects who are responsible to "Design the How" of the solution under discussion.

​At the time of this writing, the phrase "agile design methods" is not widely used or understood.
Agile Development Methods: The How Perspective
In contrast, agile development methods, as quickly as practically possible, define how to architect the solution and then proceed in building and delivering that solution. They ​produce deliverables that describe how the solution is to be implemented and they produce the actual solution. ​

At the time of this writing, the phrase "agile software development" is commonplace and is routinely associated with the word "agile".

Agile Design Methods: Subscribe for "How To"

The purpose of this primer has been to establish a foundation of a conversational framework that provides context as to where agile design methods fit in an overall solution development life cycle.

It sets the stage for further elaboration on topics related to agile design methods, collaborative creativity, product development and user experience.

- 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. It's going to be quite a journey.
Learn the Secrets of Successful Agile Designers
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-2019 Chuck Boudreau | Privacy Policy

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