Photo Credit: Brandon Nelson
The Power of the Problem Part 2: A Framework for Effective Problem Statements
    December 6, 2018
    In my previous post I wrote about the importance of becoming problem-obsessed in the quest to develop great solutions. Knowing that the power is in the problem is, after all, half the battle. But what about the other half? How exactly should we go about unpacking the problem, and what do we do once we have? My last post discussed why we should invest in the problem; now, I'd like to explore how.

    LET'S TALK DIAGNOSIS

    I was recently at the flagship Lean Startup Conference in Las Vegas. It was an inspiring and rejuvenating experience and I've reflected on it often since returning home to Orlando. During the conference I attended a workshop led by an entrepreneurial leader from the DoD aptly titled "Fall in Love with the Problem, Not the Solution: Writing Effective Problem and Outcome Statements". I'll share the presented framework in the following sections as we dive into diagnosis through problem statement development.

    The Scenario

    Let's position the framework within a real-world context that you just might experience from time to time. Imagine it's 7:15am and you're heading out your front door, coffee in hand, and an early presentation on your mind. As you back out of your driveway and cruise down the street, you're immersed in the key points of your presentation, how you'll deliver the most important content, and how you'll engage the group right off the bat. "I've got this," you assure yourself. It's going to be a great day.

    And then you merge onto the highway.

    All of the sudden your focused and productive thoughts are replaced by visions of brake lights, as far as the eye can see. You know now that it's unlikely you'll arrive early and get the added prep time you were banking on. With the way things are looking, you'll be lucky to even get to your meeting on time. And even if you do, there's no guarantee that the anxiety and frustration you feel won't show up during your presentation.

    Buckle up folks, we've got a problem.

    The Problem Statement Framework

    The development of an accurate, poignant problem statement is an incredibly effective diagnostic tool. The crafting process allows us to peel down the problem like layers of an onion and, when done effectively, allows us to take something abstract, ambiguous, and complex and disaggregate it into actionable, concrete parts. The recommended framework identifies 3 distinct components:

    • Customer (who)
    • Pain/Problem (what)
    • Impact (why

    The Customer:
    The first step to diagnosing a problem accurately is the incisive identification of the person or group experiencing the pain that the problem is causing. This is not a natural first step, but it's our first gate for risk mitigation; if we miss it, we wind up designing in the wrong direction and developing elegant but unusable solutions. At times this step is clear as a bell, but others might require additional discussion or research to determine who the true customer is. This may be especially true if, for example, only one consumer segment is reporting a problem, or if you are developing a tool for multiple internal clients.

    It's worth noting here that referring to internal teams or team members as "customers" may not be a current practice or framework. If you do not already do this, I would encourage you to test out this framework and observe its impact to internal communication and operations. I have found it to be similar to a new glasses prescription – it doesn't necessarily change my day to day activities, but wow, do I see more clearly! Now back to our problem.

    Reframing everyone you solve for as a "customer" is like a new glasses prescription - it doesn't necessarily change my day to day activities, wow, do I see more clearly!

    In our scenario, who is the person or persons experiencing the pain or problem? Certainly, we could quickly say, "Me!" - but for the sake of this exercise, let's consider the whole landscape. Who else is experiencing the same pain? People on the road? Well, not all people on the road. If you're in a bike-friendly city, you might see cyclists cruising, carefree, toward their destination. Emergency vehicles are still able to travel mostly unhindered. The customers in our scenario are drivers of (non-emergency) motor vehicles. We could split hairs a bit more, but we won't for now.

    The Pain/Problem: Identification of the pain or problem can be even murkier, and might require a good amount of digging. The first guiding question here is, "What is the pain or problem that the customer is experiencing?" For some problems this question might be enough. But for others - even our current scenario - additional questions are needed. Let's think through it.

    A few different "pains" or "problems" could be identified here. We might say that drivers are frustrated, or that there's congestion on the road, or that traffic is causing delays. All are true. So which is the pain/problem for the purpose of our statement? It's helpful for me to ask the additional question, "What is the customer encountering?" This helps me begin to distinguish the pain/problem element of my statement from the impact element; framing it situationally helps to clarify. When I ask what the customer is encountering, I am able to determine that the pain or problem for my statement is morning rush-hour traffic congestion.

    There are three important things to note here.

    • First, there are more layers in that onion. Rush-hour traffic clearly has underlying root causes, and if we needed to, we could continue to dig until we uncovered them. If your problem needs additional digging, the 5 Why's (stating the presenting pain/problem and then asking "why?" five times, or as many times as needed) can be a very effective tool. For our exercise, we've simplified far enough to be useful.
    • Second, deeper digging may uncover a root problem that realistically falls outside your scope of control or responsibility. If we continued digging here, we might find that a deeper root is the standardization of work schedules or business operations, which may be out of our control or ability to address. It's important to know when you've reached your pain/problem, and stop there.
    • The third item to note is that the pain/problem is only the second component of the problem statement and cannot be sufficiently understood without the final component - the impact.

    The pain/problem is only the second component of the problem statement and cannot be sufficiently understood without the final component - the impact.


    The Impact: The third component of our problem statement identifies the impact that the pain/problem is having on the customer. It tells us why the thing that is happening is a problem at all.

    I'll illustrate. We've just identified rush-hour traffic congestion as the pain or problem for the drivers stuck in it - but why is this a problem? It's not the sitting still, as a friend of mine recently pointed out. "We love sitting on our couches," after all. Maybe this even gives us time to catch up on our podcasts. The traffic congestion isn't truly a problem until we know the impact that it's having. In the scenario I described, the impact of the traffic congestion was driving delays that caused feelings of frustration and anxiety about missed deadlines.

    Now, if you're still with me, you're thinking "Wait, we don't know how all the drivers experienced the traffic congestion..." And you're right. In an actual problem-solving scenario, we would never assume the experience of a group of customers based on the known experience of one or two. We'd have to conduct interviews or observation to be confident in the impact.

    A key consideration in identifying the impact of a problem is the degree to which it is measurable, or at least observable. After all, the purpose of developing the problem statement is to leverage our understanding toward strong outcome statements, and ultimately, great solutions. We can only do this when we can measure. For our scenario, both missed appointments/deadlines and feelings of frustration and anxiety are able to be measured, or at least observed. (More on that considerable "can of worms" in a future post.)

    After all, the purpose of developing the problem statement is to leverage our understanding toward strong outcome statements, and ultimately, great solutions.

    The Problem Statement

    Now that we've worked through the framework and identified the who, the what, and the why of our problem scenario, we're ready to put it all together. Here's what we found when we dug into the scenario:

    • Customer (who) - Drivers of (non-emergency) motor vehicles
    • Pain/Problem (what) - Morning rush-hour traffic congestion
    • Impact (why) - Driving delays cause frustration and anxiety over missed deadlines
    Altogether now.

    Motor vehicle drivers are are delayed by morning traffic congestion, causing them to feel frustrated and anxious about missed deadlines.

    There we have it. A clear, actionable, accurate diagnosis.

    So What's Next?

    The power of the problem is that it enables us to expertly envision the outcomes (what's the "Promised Land"?) we want for our customers, and then build the best solution to take them there.
    Made on
    Tilda