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:
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 ImportantA 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 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. 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 SolutionsFrom 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 or set of statements all the more valuable. Who needs or uses problem statements?
How To Create a Problem StatementHere 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:
Actual Statements and Mad-Lib Styled Templates You may be fortunate and have the ability to describe the problem statement by simply transcribing what you have actually observed people say in the context of experiencing a problem. That's a preferable way in which to produce a problem statement. But, if you don't have that form of recall handy, or if you need some help constructing a statement that can be easily understood, then some fill-in-the-blank templates might prove helpful to help demonstrate what this looks like. To that end, here are some Mad-Lib styled templates:
Examples Here are two examples of problems statements based on conversations I've had and observations I've had in just the past day:
Best Practices and Pitfalls to Avoid
How To Create an Ideal Solution StatementAn ideal solution statement is a sentence or two that:
Examples Here are ideal solution statements based on the aforementioned problem statements:
Best Practices to Use and Pitfalls to Avoid
Practical ApplicationAn 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 as a means of creating a backlog for product development. The user story that is widely practiced in agile communities reads like this:
Here is how our example statements can be transformed into a user story that can be used by an agile development team:
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 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 improves the ability for 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
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  As a facilitator leading a collaborative group in pursuit of a solution, the misunderstanding of words surfaces time and again as a velocity-killing pitfall. Ambiguity and uncertainty impede progress, whereas clarity and sureness accelerate it. Here is a simple and effective technique that I use to help avoid this predictable pitfall in the collaborative process. Risks and Delays Result from a Lack of ClarityTo describe this pitfall, imagine that you are leading a series of working meetings comprised of a dedicated group of people who meet regularly. You all are tasked with designing a solution to a problem and communicating it to stakeholders at specific points in time to vet and approve your design. Here are a few examples of what the pitfall might look like:
Be Intentional: Build a Glossary
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;
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.
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
Now, consider the following cross-checking questions as it pertains to these statements:
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:
Understanding "Why" Matters More Than Describing "How"
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. |
Learn the Art of
Successful Agile Design
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. 
Archives
April 2018
Categories
All
|
||||||||||||||
RSS Feed