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 the 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 sage friend of mine recently opined, "It is a rare person who can look at a list of requirements and 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.
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 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 solution designer and marketer engaged in addressing it.
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.
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 or set of statements all the more valuable.
Who needs or uses a problem statement? Solution designers and architects need to understand the context under which a problem occurs. The more empathy the designer or architect has for the person experiencing the problem the better. A product manager needs to know out of all the problem statements that exist, which ones are urgent and pervasive. That set 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 two that contains 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:
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
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 as a means of creating a 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 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.
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
Agile design methods make process design conversations flow with better collaboration and results.
Making this happen requires intentionality. Here are some notions that influence how to lead and facilitate a group of people 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 solutions with people.