Three Methods For Solving The Right Problems

Tackling a thorny creative challenge and keep getting stuck?

It never fails. You’re in a meeting, circling around an idea, but can’t quite get the group to land on a plan of action. At least one – if not most – of the meeting attendees came in with an end solution in mind, before you even defined what the actual goal was. Then, once everyone else heard one path, they jumped in with two more – because it’s way more fun to play “what if” than do real work. Now you’re stuck wondering how you’re going to herd these cats into something resembling a direction, so your team can actually get to work designing it. What’s a creative leader to do?

In practice, I’ve found that this “circling the runway” analysis paralysis happens the most often when: People focus on solutions before everyone’s really sure what the actual goal is. You don’t have enough information up front to be able to define a full solution. The problem you’re addressing is just a symptom rather than a root cause. There are dozens of different methodologies for starting or defining projects.

Here are three that I’ve found the most helpful for getting unstuck in these situations:

Think like a journalist

Empathize and experiment

Channel your inner three-year-old

Method 1: Think Like a Journalist.

You probably don’t need a degree in Journalism to have heard about the 5W+H formula: Who, What, When, Where, Why, and How. This storytelling outline is a good one for getting the full picture out of your project stakeholders as well.

Who is your audience? Who is actually having the problem you’re trying to define? Also, who are your stakeholders: who needs actual input into your eventual solution, who has approval power, and who just needs to be kept informed of the process?

What is your audience trying to do? Don’t fall into the trap of trying to define what your solution will be – for now, just define what their problem or challenge is.

When – and how often – does your audience face this problem? Is it a small annoyance that happens every time, or a catastrophic system failure that only happens when certain other criteria are met?

Where is your audience when they face this problem? It may seem basic, but this can help you with scope definition and figuring out what platform your final solution needs to be on.

Why should the audience choose you over the competition? What sort of differentiators can you uniquely offer that they can’t get anywhere else? Why are you the right team to be solving this problem?

How are you going to know you’ve succeeded? What are your success metrics for the project?

Finally, once everyone is aligned on these, you can start to brainstorm potential solutions to the problem that fit the parameters you’ve defined. This method works well when you really aren’t sure where to start, whether that’s because your team has a ton of different ideas or because nobody’s really taken the time to define a true goal yet. I’ve used this method to lead meeting discussions in front of a whiteboard, as a personal checklist to make sure all the bases are covered, and even as the basis of a simple creative brief template that stakeholders can fairly easily fill out on their own, because most people are already familiar with the concept.

It’s also a good one to use with groups that like to jump directly to the fun part of thinking of solutions, but who may not necessarily know all the constraints that your team has. Use your time with this group to define the 5W+H’s and get alignment on them. Then, you can get your designers or other stakeholders who will be involved in implementation together to come up with creative solutions that are actually feasible.

Method 2: Empathize and Experiment.

If you’re designing a big, complex, expensive system or product, you need to make sure up front you’re solving the right problem for the right audience, and put time and effort into making sure you’ve identified all of your requirements, documented your processes, codified your solutions, etc.

But what if you’re doing something so completely new (or new to you) that you don’t even have enough data to figure out what you don’t know?

Enter the Design Thinking process. When your primary goal is innovation, sometimes it can be more productive in the long run to get out something (if you’re developing new software, for example, it’s called a Minimum Viable Product or MVP), see how it does, and then fix problems as they arise or add features as they are needed.

This methodology closely follows actual users to determine what the next best improvement will be – or, basically, to learn by doing.

The general steps are:

Empathize. There are a number of research methodologies to do this, but in general, watch your user to understand their pain points.

Define. Identify which pain point will have the most user impact or makes the most sense next in your product cycle.

Ideate. Bring your team together to brainstorm possible solutions, ways to solve the problem, or hypotheses to test.

Prototype. Often this involves building a rough schematic or wireframe with just enough detail to test your idea.

Test. Again, there are multiple ways of doing this, but it’s important to test with real users, even just a few of them.

Iterate. Keep creating quick prototypes and testing with users. You can uncover more issues running several rounds of tests with fewer users (even just three rounds with 3-5 users per round) than running one large scale test where everyone gets stuck on the same problem.

Implement. Be sure to set up a method of measuring your outcomes, so you can be sure that you’re actually improving the experience.

A simpler way of remembering of this method is to boil it down to three steps: Think, Make, and Check. Think about what your user needs, make a solution to test, then check your solution with actual users. This method obviously works best in situations where making updates is relatively easy and inexpensive – generally digital solutions. You probably wouldn’t be able to run enough iterations to get to any reasonable improvements in a publication that only prints once a year, for example.

Method 3: Channel Your Inner Three-Year-Old.

If you’ve ever been around a three-year-old for more than a few hours, you know that one of their favorite questions to ask is “Why?” Why are you doing that? Why is the sky blue? Why can’t we go play in that elephant graveyard? And on. And on. And on. And on.

But if you have the patience to go that far, something happens about the fifth or sixth, Why? – the kid stumps you. By that point for me the answers are getting very sciencey, and I have to start googling because now I’m curious about how the world works.

Decades ago, Toyota Motor Corporation codified this curiosity and developed the “Five Why’s” system as the basis of their problem-solving process. The idea is to keep asking Why? Until you get to a root cause that you can actually fix or a broken process you can actually address. In other words, the key is not to stop at the classic reasons of not enough time, budget, or resources. This method also keeps everyone focused on fixing problems and ensuring it doesn’t happen again, not just assigning blame (and then having it happen again to someone else).

The Five Why’s is a great strategy for when you already have a “thing” out there, but have recurring problems, and you aren’t exactly sure how to fix the actual root cause. This method works best when you can engage with the people who identify the problems most often, as well as those who understand the technical aspects enough to actually answer the Why? Questions. In other words, if you don’t know the answer to a question, go find someone who does, or pause to go find out the answer – guessing won’t help you here.

Asking Why? 5 times is a general guideline; it may take you more or less to practice. The method has been around long enough that there are numerous applications and methods for how to deploy it. You may need a bit of practice to ensure you’re asking the right Why? Questions, but keep it in mind for times when your other methods of problem solving are getting answers like “human error” or “not enough resources” – in other words, things you can’t actually fix.

Whether you need to get unstuck at the beginning of a project, while trying to figure out your next step, or while fixing a problem with your existing product, one of these methods will help you and your team work through the mess. All of them cut to the heart of making sure you’ve clearly defined the right problem – because a beautiful solution to the wrong problem is still, unfortunately, the wrong solution.


Related Posts