How to resist jumping to solutions
And why all of us need a reminder.
When I started making travel videos, one problem I faced early on was color correction. My greens definitely did not look right, but I could not figure out how to fix them. Even successive shots sometimes ended up with very different tones!
I’ve tried all the knobs and sliders and spent hours searching “how to color correct forest footage.” Then I stumbled upon this advice from photographer Andy Mumford:
Before we start any processing, we should always have a relatively clear idea of what direction we want to take the processing in. It’s rarely a good idea to just start pushing sliders left and right to see what looks good because that’s almost never gonna give you anything worthwhile.
Well, that made sense. I needed to learn to see first. To ask myself, “What is it exactly that I don’t like about the image?” Is it too warm, too cold, too green, too purple, too saturated, too bland? This made a difference. I did not just start finding the right sliders faster — I saw the bigger picture. My drone footage was consistently warm. My camera footage was colder than usual in forests. I realized I could tweak the colors in the camera settings and spend less time correcting them.
Why didn’t I have this breakthrough sooner? My mistake was that I did not separate my problem-finding self from my problem-solving self. I jumped straight to solutions without understanding what was wrong… Wait a second, where have I seen this before?
Problem, not solution
“Focus on the problem, not the solution” is a mantra familiar to most product managers. Before thinking about solutions, we should define the problem and establish why it’s important. Contrast these examples:
Perhaps you’ve noticed the beauty of it: most problems have multiple solutions. If you start by defining the problem, you and your team can brainstorm and pick the best one. But starting with a specific solution does not have this benefit — you reap what you sow. In the words of Hans Zimmer, the famous film composer, it “robs you of the possibility of being surprised.” I don’t know about you, but I was definitely surprised to learn that mirrors can make elevators faster (well, sort of), and I cherish that.
The slippery slope
So everyone agrees that starting with the problem is the way to go. It’s in all product books, talks, and blog posts. Discovering, clarifying, and prioritizing problems is one of the product manager’s main responsibilities. But the thing is, time and again, I see myself and others jumping to solutions against our better judgment, just like in the opening story. How does this happen?
Getting attached to an idea
If you are a product manager, chances are you come from an adjacent field, like marketing, engineering, or UX. You’ve worked with tech before. Surely you have an idea about how to address the problem! (Blockchain!) That’s how it starts. In your head, the problem and the idea become synonymous. You know the problem is important, but the idea is so elegant, refreshing, and easy to explain. It takes over — you get so carried away you forget to tell everyone else what the problem was. Excited, the CEO tweets, “We are doing [your idea]!” Will you take a step back now?
Settling on prob…lutions
Other times you start with something like “our application is too monolithic” — too much of anything sure sounds like a problem. But is it really? Actually, no. I mean, it could be if you dig deeper. But notice how it’s phrased. Does it leave much wiggle room as to what needs to be done? It’s a solution masquerading as a problem, just a dressed-up version of “we need to break up our monolithic application.” To solve what, though? Similarly, “we don’t have X” is just a lazy way of saying “we need to do X.” You don’t get points if you have not uncovered and clarified the underlying problem.
Being inconsistent
Even if you have the right mindset, you might not apply it consistently in different situations. For example, in The Failure of Risk Management, Douglas Hubbard tells the story of a drug manufacturer that used proven, scientific methods in one important context (testing drugs) and unproven, pseudo-scientific methods in another (evaluating risks of outsourcing production). Likewise, you might focus on problems in one context (product discovery) but inadvertently drop your guard and jump to solutions in others (presenting roadmaps, reacting to urgent support tickets, or… correcting colors in a video). It’s especially tempting to cut corners when problems seem small or solutions obvious.
So what can you do?
I hope at this point I’ve established the issue:
We know we should not jump to solutions, but often we do because we get carried away, settle on vague definitions, or think it does not hurt in our situation (it does).
Let’s talk about solving this?
Write the problem down
I’ve long avoided writing, preferring to talk, but after my first six-pagers, I became a convert. Note, writing is not a substitute for talking. Some people will “forget” to read your memo. Some will read diagonally, missing the point. Some will misread it (documents are not shared understanding). Some will be skeptical because “narratives can make any argument sound compelling.” No, the real benefit of writing is your own clarity. And sequencing.
Writing the problem down forces you to put often disconnected thoughts in order and to properly define what needs solving before you proceed.
Stick with the story
What do movie directors talk about with composers writing the soundtrack? It’s not the notes. And not the chords. And not which synth to use. It’s the story! Your product is like a movie, and its story — your story — is not about widgets but the users and the business. If neither appears in the supposed problem statement, something is amiss. Don’t despair just yet, though!
A problem worth solving can always be traced back to its user or business impact (ideally, both). Use the “5 WHYs” or the “5 SO WHATs” technique to dig deeper.
Keep digging until the story comes through. (Note that some problems impact multiple things at once, so you might want to rinse and repeat to uncover that. And no, this is not supposed to be easy.)
Sweat the small stuff
There is no reason why you shouldn’t apply the same approach to smaller problems. For example, I wrote down which cuts I would need to make before choosing and buying a wood saw. In particular, smaller problems often arise while you are solving the big problem. Say the work is underway, and you feel the design is slightly off…
However easy the fix (“just make this bigger”), resist the temptation to suggest it. Instead, share why it’s necessary.
Is it because that’s not how the product is used in the wild? Oh, you haven’t explained how it’s used yet?..
I hope you found this helpful. If you are curious about my battle with the color green, here’s the latest installment. It’s not perfect, but I think I am getting more consistent. 😊
