“Talk to me about solutions, not problems”
– Every business executive at some point.
Humans don’t like problems. We want problems to be fixed as quickly and easily as possible. We like solutions. A story about a problem that does not end with a solution is a boring story. Because of this, we tend to focus more on solutions than we do on problems and we reward solutions not problems.
But. For us to have good solutions, we need to battle everything inside of us that just wants to jump to the first solution, and be ok with the problem. We have to make friends with the problem, take it to dinner, and learn about its deepest secrets.
“It is a capital mistake to theorise before one has data. Insensibly one begins to twist facts to suit theories, instead of theories to suit facts.”― Sir Arthur Conan Doyle, Sherlock Holmes
New features or products (or updates to old ones) should start with the problem to be solved. Starting a project with problem-thinking gets you closer to a build that fits your customers needs. Setting aside solutions early helps us avoid the trap of proving that something works (even if it doesn’t), rather than exploring why something might not work in the first place. By reaching for your solution-hat, you risk missing out on finding underlying issues or building something that may not be used as intended.
🕵️♀️ Rather write problems so that the data leads you to a solution instead of fitting the facts to suit your theory.
Building digital products is expensive
Building the most cost effective, on-brand or downright simplest solution (insert ‘thinnest slice’ or ‘MM-MVP’ here) is tempting. But, without exploring the problem and the data first, we risk building a solution that’s not a good fit. When a solution doesn’t align with a user need, people won’t use it. At least not to its full potential. This can pose an issue if significant time and money has been invested in creating a product that isn’t being used.
The worst case scenario is that you are stuck with a built solution that was:
- Expensive
- Took a long time to make (thereby roadblocking product pipelines)
- Isn’t being used at all and must be changed to make it fit the target market (costing more time and money)
- May have to be scrapped entirely (the worst case scenario)
🔍 Conduct research early on to really explore your problem before reaching for the team ideation session.
Use the mighty Problem Statement
Now that you’ve met your problem, you’ve explored each other’s personalities and movie preferences, it’s time to build it a house and outline your 5 year plan together. We call this defining a problem statement.
Norman Nielsen describes the problem statement as “a helpful scoping device, focusing the team on the problem it needs to explore and subsequently solve.”
Taking it back to Human Centred Design theory, defining a solution comes after exploring the breadth of the idea (called the Discovery Phase). This is done using your problem statement to guide the areas that need the most research.
By exploring a problem and throwing away ideas as you do the research in this phase you get closer to a solution that is actually going to fit your problem. If the idea or hypothesis is wrong, it won’t stand up against the data you’ve collected. An idea can be cheaper to throw out than a fully built feature! Narrowing down to the one problem also helps to define a scope and keeps the focus of the research and the solution on track. This is where you may have to wear more than one hat by being an inquisitive researcher and a pragmatic, business-minded contributor.
Research and problem statements go hand-in-hand
Research can be done any time in the design to development cycle. But we’ve seen that researching sooner rather than later can expose underlying problems that you may not have known about and validate early thoughts. As you collect data in your research, bounce those insights off your problem statement. Ask yourself; “Does this add value?”. This process can help you figure out if your data supports your problem statement or if it just adds noise. When your data supports the problem, viable solutions can then be defined and tested.
So, next time you jump to a solution, or find yourself not wanting to face problems, think to yourself, “The problems are not scary, they are my friends. They will help me make a better solution”.