The Problem Springboard
Taking the time to break down problems gives you better ways to discover opportunities, solve your problem faster, and deliver more value
When you’re presented with a problem how do you go about solving it?
From an early age, we’re told by our teachers to read the question, write down the problem, show our workings and explain the steps we took to find an answer. But this doesn’t stop us wanting to jump into writing down the solution, especially when the answer seems obvious.
Outside of the classroom, however, problems and answers tend to be less obvious and are often considerably more complex. It’s not unusual to be presented with a problem where there are several “correct” answers, and it’s not always clear which is the best one.
It often surprises me then, when I see people in the business world, especially execs, rushing into making business decisions to navigate around complex and knotty problems without following at least some of the steps we’re taught at school.
Something in how our brains are wired is convincing us that there is a more reliable way to find better answers.
Something is telling us to rely on a mixture of intuition, gut instinct and mental calculus.
I find that a better way to break down problems is to use a Problem Statement.
Problem Statements
Writing your problem down in the form of a problem statement is not a new concept or technique. You’ve probably written one, or something like one, many times yourself. But have you ever considered the value you’re getting out of writing one? Could it work a little harder?
Jeff Paton’s post “Read this first” talks about the importance of building a collective understanding of a problem by looking at and agreeing on what’s happening “Now and Later”. More specifically, he breaks this down into an understanding of what people are trying to do right now, what’s stopping them and the impact it has on the business. Then he flips this on its head to design the “later” — the outcomes people are looking for and the impact in terms of the benefits for the business that will flow from this happening.
I often refer back to this to establish if a group of people really understand the problem in front of them, because if you can’t describe this, you’re really guessing what people want and need, and you’ll end up designing something that people probably won’t want and won’t use.
Depending on what school of thought you come from, I typically see people using problem statements as a way to better understand what’s happening now and later by looking at the 5 W’s surrounding their problem — the Who, What, Why, When and Where.
It’s the practice of breaking down and understanding the various dimensions of a problem that makes this technique so useful, as the process helps you set out what you currently believe about the problem and the people involved. It also starts the process of how you might address the problem and if you do solve it, what people will be able to do that they can’t right now.
Crucially it gives you a springboard into breaking down the dimensions of the problem even further to the point that you can uncover insights — the secret ingredient to cracking complex problems.
In practice though, whenever I introduce people to using Problem Statements, I see the same problem come up time and time again — People don’t like to show their working and prefer instead to jump straight to what they think is the answer, ignoring the power of the springboard and the opportunity right in front of them to find insights.
Solution Bias
Rather than getting the most out of using a problem statement, I often see people with the answer in their heads trying to squeeze their solution in at every possible opportunity.
Let’s look at an example…
I worked with a team last year whose license for a software solution was coming to an end. They wanted to use a more human-centred approach to working out a way to address this gap and were looking for guidance on how to get started, so I began by introducing them to the Problem Statement and encouraged them to use it to start breaking down the problem.
This was their first attempt (note: I’ve used some artistic license on the precise wording for illustration purposes)
Checking homework
Hopefully, it’s pretty obvious how (unintentionally) one-track-minded the team was being when they wrote this.
They wanted this new solution, and they hadn’t yet considered that it might be worthwhile spending time understanding the dimensions of the problem and what people might actually need to be able to do with it. You can see this in almost every part of the statement, which could have been problematic had they left it at this point.
If the team had run with this, they would have painted themselves into a corner by choosing a shiny new tool straight away, and risked switching to a “solution” that might have failed to address the needs of the people they were seeking to serve.
I find it’s always good to let people have a go at writing down the problem, with just a little guidance, as it tells me a lot about how they are thinking, and where there are gaps that need to be addressed.
It tells me if someone has started to consider the people involved, or tried to understand what they’re struggling with right now. Without this, it’s impossible to know what outcomes those people are looking to achieve or what might be getting in their way without guessing. This makes it hard to know what underlying problems we are designing for, which makes it hard to design a decent solution.
It tells me if someone has measured the size of the problem for those people, and what this means in commercial terms for the business. Without this, it’s impossible to calculate the potential return on investment to fix the problem without guessing, which makes it hard to justify spending time and effort on fixing the problem.
Most importantly though, it tells me that this group of people are not yet equipped to work autonomously because they are not setting themselves up to find answers to the 5W’s — the Who, What, Why, When and Where — the evidence they need to design better solutions.
Creating Springboards
By talking through the value of these prompts and reiterating how they could help uncover insights, we were able to create a series of springboards for them to dive into the details they were missing to about the 5W’s.
In each instance, we spent time widening the frame of reference, trying to understand more about the people involved, more about their experiences and where they encountered problems.
We dug deeper into the commercial aspects of the problem, and how resolving this problem might benefit the business and play into wider strategy and a bigger picture.
Most importantly though is that it gave the group a solid basis on which to discuss what questions they had and which areas they needed to focus on testing out next.
Here’s where we got to…
Now the problem statement is providing us with 4 springboards to delve deeper into the problem and start asking questions that will help us uncover insights that we can use to create a differentiated and valuable experience.
The team were able to collect questions up and agree which of them were the most critical to answer to understand the best opportunities and outcomes.
These were some of the kinds of questions they considered…
- We currently — by stating their assumptions around the problem in more detail they started asking questions to validate their view of the current experience people have. What software were people using and why did they use them? Some might be non-negotiable, whilst others are choices that they could reconsider. Some might cause huge amounts of operational overheads, whilst others might be super-efficient and not need replacing. What caused the most frustration and overheads? How did we measure that? What did it cost the business?
- How might we — rather than focus on the solution here, the team instead thought about what they needed to learn to build their knowledge of the problem space. What were people trying to achieve? What gains were people looking for? What was getting in their way? Which of these was the biggest obstacle? Why did that happen? Understanding this could give clues as to what the best opportunities are to address
- For the — who were the people that we needed to talk to? Who is the customer? Who serves them? Who plays a role in the background who might be able to provide insight? Who could tell us how to measure customer or colleague satisfaction? Who could tell us the cost for the business of not fixing this or what the benefits might be? Who did we need to work with and who do we need to keep informed of progress?
- So that — what will people be able to do in the future if we solve this problem? What does that mean for the business? How does this align with our strategy? What are the measures of success that tell us that we’ve delivered the value we intend to?
With the springboard ready to go, the team was now armed with a prioritised list of the most important questions to build a solid foundation on which to research and design from.
They were ready to use their springboard and dive in and find answers.
Once they had found these answers, they were able to agree on the best opportunities to add value, and from there, work autonomously to address those opportunities, safe in the knowledge that they could test solutions and prove that they were delivering the most valuable outcomes for their customers and their business.
Ready? Spring, Go!
So next time you come across a problem, take a pause and consider if you’ve got your springboards ready to go, ones that help you start asking the right questions and uncovering insights.
Like this story? If so, please give a clap, it only takes a second!
Want to hear more from me? follow me with one click via @robinow.medium.com/follow
