Figuring out the problem before jumping into solutions
My last blog post was about the steps to overcoming challenges and exploring ideas. In short, the premise of the post is to define the problem, look for inspiration and remix it to come up with a novel solution.
When I posted it on Twitter I got this reply from Josh:
In Josh's experience, most design processes are triggered by a solution, not the problem.
To be fair, at times you have a problem and no solution:
- "It's too hard to find things on the home screen. It looks like a mess."
Other times, you start with a solution or a set of solutions:
- "We should add a search bar on the home screen."
- "How about we categorise items so that they're scannable?"
- "Would switching between tile and list views help?"
Where more than one solution is applicable, it would suggest that we are trying to spray and pray with the hope that we might hit the target of solving it.
But not to worry, it just means that you haven't worked backwards to the problem yet.
But why do it?
The suggested solution(s) appears to fit? Why figure out the problem?
When you start with solutions before working backwards to the problem, the creator ends up building more than what is expected by the customer. Or they build something that doesn't get it right for what customers are seeking to actually get done.
Building extra parts add to the complexity of the solution and could mean an increased scope or time budget. A waste of precious resources in an evolving product landscape. Something most small businesses can't afford to do.
The loser here then becomes the customer. When customers don't get what they want, they'll end up firing your solution and hire another one that does their job well. And you can't blame them, nobody wants to feel like a loser.
When you have a problem and no solution, you spend a lot of time accruing enough detail to come up with a solution. But when we start with solutions, it's important to do some investigating as to why that solution makes sense and whether the problem being solved is fundamental.
The reason to do this because you're trying to understand the circumstances the customers are in and the outcome they seek. It means to integrate what we have learned about real behaviour to synthesise an understanding of the problem that constrains the solution.
Defining constraints means identifying what should be included and more importantly what should not be included in the scope of the solution. This act of figuring out what's important (and not) allows you to think creatively about the solution. They say that you should "think outside the box" but nobody tells you that you should define the box before you attempt to think outside it.
So, how do we work backwards to the problem from the solution and define the constraints? Let's look at some examples:
This is an excerpt from the head of product strategy at Basecamp, Ryan Singer's Shape Up Book:
"We (Basecamp) once had a customer ask us for more complex permission rules. It could easily have taken six weeks to build the change she wanted. Instead of taking the request at face value, we dug deeper. It turned out that someone had archived the file without knowing the file would disappear for everyone else using the system. Instead of creating a rule to prevent some people from archiving, we realised we could put a warning on the archive action itself that explains the impact. That's a one-day change instead of a six-week project."
The important perspective here is to understand what's really going wrong than asking what you could build.
What's driving the request?
At what point do the customer's workflow breakdown without what they're asking for?
In this instance, since it's a customer request, you could talk to them to figure out when their workflow broke down. Understanding causation and their circumstances behind the decision for a customer to ask for that solution will help you understand where they're trying to get.
In other instances, you can rely on data and asking yourself questions to figure out the problem from the solution.
This excerpt is from Ryan Singer's newsletter #2.
"It started with an idea to offer folders. But then this led to some questioning, which led to some research, which led to a different conclusion about what to pursue on the supply side."
Think of "demand-side" as the problem in the real world and "supply-side" as the solution to the problem.
"... when I suspected the home screen was cluttered from out-of-date projects, I ran data to see what proportion of projects on our own company Basecamp account was shown on the home screen but hadn't been touched in months. I discovered it was a huge issue for us. That research wasn't random curiosity. The back and forth between the supply side and demand-side defined a context that made it clear at each step what the question was, why I was asking it, and how the answer affected the work-in-progress solution."
In both instances, however, context is king. A problem well stated is half solved.
A creator is an investigator. Einstein said if had an hour to save the world, he would spend 55 minutes defining the problem and five minutes solving it. Henry Ford said that if he had asked for what customers wanted they would've said: "faster horses". If you combine the two quotes together you'd take away the fact that as a creator, it's much better to be an investigator that takes their time, looking into what customers say or do to figure out the real problem to help them progress effectively.
Thanks for reading!
This post wouldn't have been possible without these assets:
- The Shape Up Book. Basecamp solves problems relative to time constraints (6-week cycles) that guide much of the decisions around what they build. The time constraint also forces them to think deeply about whether they're building the right solution for the customer.
- This Twitter thread from Josh Pitzalis (@joshpitzalis). It served as the seed for the ideas shared here.
- Ryan Singer's newsletters. He rarely sends one, but the 8 that he has shared so far have been immensely insightful to our product journey.