I've heard it said, "To learn a new truth read an old book." Today I want to tell you about an essential conversational skill that I learned from an out-of-print book that I absorbed many years ago. What I learned positively impacts my design leadership work to this day.
The skill described in this book is a proven game-changer for me as I face the predictable challenges that occur in leading groups of people on the journey of product and solution design. It also measurably improves my ability to connect with people in my personal life.
Anyone can learn this skill. Mastering it is a lifelong and worthy pursuit. It provides a clearer understanding of issues and what to do about them. As a result, design conversations stay on track when issues occur. They get identified with greater understanding...and they get resolved.
If you want more confidence in how to handle issues when they occur, the life skill taught in an out-of-print book, and that I introduce in this video, will absolutely help you in your work and throughout your life.
The big takeaways
Design work is enabled by conversation with various stakeholders. Agile design methods focus on discussing and describing WHAT is to be produced before describing HOW it is to be developed.
Here is a quick primer on agile design methods, where they fit in solution development lifecycle and how they differ from agile development methods like Scrum.
The big takeaways:
Good design conversations don't happen by accident. Facilitators who understand where people are coming from and where they are taking them have a markedly improved chance of getting great contributions and producing good conceptual design work.
Here are a few ideas to help facilitate learning and discovery design conversations with busy people.
The big takeaways:
Good design conversations don't happen by accident.
They are started and sustained by capturing ideas in the moment and in a way that people can perceive.
Here are some ideas to help you lead the design conversation and to capture the learning and discovery that occurs in a collaborative meeting.
The big takeaways:
Getting people to collaborate creatively in meetings is easier and more effective when it is done in a pleasurable, fun and trusting environment.
I know from experience how hard this can be.
So here are a few tips for leading a creative, collaborative meeting...
The big takeaways:
These artifacts represent our attempt to completely capture what the user needs. We fill out forms and declare that our work at capturing what is needed is complete. Milestone achieved. Check to box. Move forward in building the product.
Not so fast. Documentation by itself is inadequate.
It is in adequate because it represents a one-size-fits-all approach for connecting what is needed to the person or team who will be responsible for designing and building it.
A sagely colleague of mine recently opined, "It is a rare person who can look at a list of requirements an fully understand the context of the user."
Think about how commonplace it is to misunderstand someone else's words or intentions in our daily lives and interactions with people. This reality is also true in the world of product design and development.
Thus, the necessity of collaborative conversation reintroduces itself into our product management reality. When solution designers and architects begin to consume these documents, they rarely seek more specificity, Rather, they almost always seek increased understanding and clarity regarding the context of the person experiencing the problem.
That clarity comes most efficiently and effectively through collaborative dialog, a series of questions raised by designers and architects who have consumed the documentation and the people who have the answers. Only when an adequate level of understanding is obtained can they proceed with confidence with their product design and development activities.
By way of example, Scrum (the agile development framework) recognizes that a critical function that a Product Owner performs is to answer questions that Developers have regarding user stories. In other words, Scrum assumes that it is normal for requirements to not be fully understood by those who read them.
The handoff between those writing documentation of needs and those consuming them represents a predictable speed bump in the process of designing and developing solutions. The shock absorber that is best suited to absorb that bump is a collaborative conversation between those in the know and those who need to know in order to proceed.
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:
Mad-Lib Style Templates
To help demonstrate what this might look like in the abstract, her are some templates:
Here are two examples of problems statements based on conversations I've or observations I've had in just the past day:
Best Practices and Pitfalls to Avoid
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:
Here are ideal solution statements based on the aforementioned problem statements:
Best Practices and Pitfalls to Avoid
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:
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.
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.
It passes so quickly that you’ll miss the opportunity if you’re not paying attention.
It’s that initial moment in the process when a person introduces themselves, shares who they are and what and their organization does.
That moment is rich with potential and it goes by quickly.
What To Listen For
Be prepared for the moment in advance by having your co-facilitor serve as a scribe, recording the person’s name on a single sheet of paper or in a note-taking tool like Evernote.
Then your scribe should listen for and record any of the following items that the person mentions:
Pain Points / Opportunities
“I’m Juanita and I work for the Finance Department. We use Dynamics to produce final paychecks when an employee departs and work with Legal and Procurement and Travel to ensure that any garnishments are taken out prior to their final paycheck and that any reimbursements for travel expenses are also included in their last paycheck. We also produce W-2s for departed employees at the end of the year. It’s a challenge and a very manual process to get all of this done thoroughly in a short timeframe, particularly when an employee departure occurs quickly.”
Pain Points / Opportunities
What To Do With This
Hold on to them. They will come in handy in the structured conversation that will unfold in the hours and days that lie ahead.
Nearly every one of these nouns are added to a Glossary. Many of them will eventually be placed around a Circle of Interaction (COIN) diagram that clearly summarizes the process, collaborators and deliverables on a single page.
Why This Matters
When it comes to facilitating and producing a clear understanding of a domain under discussion, if it hasn’t been written then it hasn’t been said. To say it another way, if it’s been said, but hasn’t been recorded, then it will not have the potential to be added to design documentation.
Being intentional to listen for and record things that a stakeholder mentions serves the stakeholder and the conversational process well. It keeps things agile. It serves the stakeholder well by respecting their contribution to the conversation. It serves the process by maintaining velocity, by creating a corporate memory of what was mentioned and by listening for those things which will be part of the future-state design documentation.
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 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
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.
Learn the Art of
Successful Agile Design
(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 with a variety of people.