Zoom Out to Solve the Right Problem
Are you truly addressing the real need, or are you merely patching up an issue within an existing solution?
Sometimes, we come up with impressive solutions to problems but often focus on fixing a problem within the current solution instead of addressing the original need and missing an opportunity to create a better, creative and usually more efficient solution to a bigger problem.
By taking a step back and zooming out, we can identify the real pain points and develop much better, more creative and innovative solutions.
This approach requires a different state of mind. This article will try to instate this state of mind in you. Or at least raise some awareness.
Let’s start with an example…
The Garden Hose
Whether you have a garden or not, you can relate to this problem. A typical garden hose is long, ranging from 10 to 15 meters, and made of some kind of tough rubber. Even when empty, a 15-meter hose weighs around 3 to 4 kilograms and takes up a lot of space.
What do you do with it when you’re not using it? In most cases, it ends up thrown in a corner of the garden or shed, or simply left lying around. The next time you need it, you’re likely to encounter knots and tangles. Why? It’s the force of nature.
Is there a solution? Absolutely!
Solution #1 — The Reel
Keeping the hose on a reel you are exempted from dealing with (most) knots, but it introduces another annoyance. When you want to use the hose, you need to unreel it by pulling or using a handle to unwind it. Similarly, when you’re finished, you have to spin the handle on the side, like starting an old car, all while ensuring the hose is evenly arranged on the reel.
So we solved one problem and created a new annoyance.
Is there a better solution? Of course!
Solution #2 — The Self-Retracting Reel
The self-retracting reel solves the annoyance and takes the concept further by adding a spring mechanism. With this reel, you can simply pull out the hose when you need it and press a button to retract it.
Sounds like a great solution. All problems solved, right?
I say no.
Does the self-retracting reel fully address this need? Yes, but at a high cost. The self-retracting reel is expensive, heavy, takes up more space, and if you want to move the hose to another tap (say to wash your car), good luck with that.
Let’s ask ourselves, what is the real need of the user? The real need is to easily carry flowing water between the tap and the flowers or any other target with minimal hassle.
I was a tad close to buying the self-retracting reel. Really!
And then I stumbled upon this one:
Solution #3 — The Expanding Hose
This hose starts off at 5 meters in length but expands to 15 meters when connected to a water tap.
It is thin and flexible. When it is empty you can practically hold the entire hose in the palm of your hand and it weighs less than a soda can so you can easily carry it between taps. It takes up minimal space, and there are no entanglement issues. As a bonus, when you turn off the water supply, it automatically expels and drains all the water, returning to its original small and lightweight form without wasting any water.
Does it solve the user’s real need? Definitely with flying colors!
(and the best part is, it costs much less than the other solutions)
Genius, isn't it?
Such products give you awe. right?
Why? Because they, instead of trying to solve a problem with the existing solutions (or “patch it”), aim to solve the real need.
Someone zoomed out and ask herself, hmm… what is the real need? and came up with a better idea.
These are revolutions and not evolutions.
Let’s see how this concept can be useful in your work — let’s look at three examples — developer, product manager, and entrepreneur.
Product Managers: Zoom Out! Less Is More
As a product manager, you’re flooded with numerous customer requirements (it’s better to have a flood of customer requirements than no customers at all, right?).
Your aim is to ensure customer satisfaction (after all, that’s how you’re measured), so you start adding buttons, options, menus, and screens to accommodate their demands. Unfortunately, this often results in a cluttered and unusable user interface.
But hey, the customers are happy because they got what they wanted, right? Well, not necessarily.
Sometimes, you may receive conflicting or similar-but-not-identical requirements from different customers. How do you make them all happy?
You’ll often find that customers will tell you what they want and precisely HOW they expect it to be done, rather than explaining WHAT they truly need. Sometimes, they struggle to articulate their needs, or they simply want to demonstrate that they’ve thought about the solution.
But you are the product manager and you know the product better. Don't succumb to their requirements blindly. listen to all and then zoom out.
Need an example?
Let’s say you’re a product manager for a task management product that allows users to manage hierarchical task lists. A customer asks you to add a context menu with “Copy/Paste” and “Delete” options when they right-click on a task (the 80s called to say “hi”).
At first glance, this request seems reasonable, right?
However, if you probe deeper and ask, “What would you use these options for? Why are you asking for them?” you may discover that the customer actually just wants to be able to move tasks around.
Now, wouldn’t it be more reasonable to implement drag-and-drop functionality for moving tasks? This would make the user happier and provide a more intuitive and useful tool. But how could you have arrived at this solution without asking “why”?
Key takeout: It is not about one feature
Your life as a product manager is far more complicated. You receive countless feature requests from users. By understanding the requests and their motivations, you can develop better solutions that address multiple needs with less effort, leading to happier customers. Remember, less is more.
Remember, you do not want to create a retractable reel for the hose. You want to create a product that addresses all requirements in an elegant way.
In order to do so, your job is to listen to all your customers and understand their motivations. Then can zoom out, and gain a comprehensive understanding of your customers’ needs in the context of the full picture of your product and its vision. Only then, you can come up with the right product features for the right needs.
Developers: Are You Just Patching?
(You don’t have to be a developer to understand this part but feel free to skip to the next section if you want)
How often do you zoom out and truly examine the entire picture?
Let’s consider a simple (and perhaps naive) example:
Imagine someone on your team wrote this code that performs one action during the daytime and another at night:
if (isDayTime(now)) {
// do something
} else {
// do something else
}For simplicity’s sake, let’s assume daytime is defined as 6 AM to 6 PM. However, for some reason, the `isDayTime` function does not consider 6:00 AM as daytime. You’ve been asked to fix it
You have two options:
A. Change the condition to something like (excuse my syntax)
isDayTime(now) || now == “06:00”B. Go to the definition of the function `isDayTime` and rewrite it to make it inclusive.
Ask yourself honestly, which approach would you choose?
Most people would opt for option A. You too. Why?
I am sure you can come up with many reasons (excuses?) (such as uncertainty about who else is using this function and whether it relies on 6:00 AM not being considered daytime), but the real excuse is “if it isn’t broken, don’t fix it”, or in other word laziness (not in a bad sense!)
We are often too lazy to zoom out and improve the entire solution.
Be honest with yourself. Do you always look at the relevant code in its entirety to ensure you’re doing the right thing? Are you sometimes tempted to make the “minimal change”?
I admit, I’m not always immune to this temptation either.
Real-Life Example: To Cache or Not to Cache?
As an architect, I once attended a meeting where the team leader described how they addressed a problem raised by one of the customer engineers. In short, the system had exposed some APIs, and the customer engineer used them to test certain use cases. The problem arose because, due to the system’s caching mechanism (as designed), the engineer received the same results repeatedly for one of the API endpoints.
Our team leader’s proposed solution was to expose a new API that would allow the engineer to clear the cache.
To say the least, I didn’t like this approach at all.
The cache was a business requirement, and if used correctly, it should not have caused any issues. So why did it bother the customer engineer? We decided to zoom out and understand the engineer’s exact goals. I’ll spare you the details of the answers and analysis and skip to the end.
After understanding the engineer’s true intentions, we realized that they were not running real-life scenarios; instead, they were testing in the customer’s test environment and repeatedly used different data with the same key (hence the caching issue).
Now, should we have added new code and exposed a new API just to accommodate these unnatural use cases? Hell no!
But now that we understand the engineer’s true needs, we simply changed the time-to-live (TTL) configuration of the cache to 0 in the customer’s test environment. No additional code was necessary. Zero effort.
Key takeout: To Patch or Not to Patch?
I understand that sometimes time constraints force us to patch.
I am sure you’ve seen this before — a small patch causes another bug in another place. When fixed, it creates another bug, and so on…
There are so many systems built patch over patch (over patch, over patch…) — Let’s strive to avoid that.
So… when dealing with a bug or a new requirement, try to zoom out. Attempt to understand the new requirement within the context of past requirements and existing code. It might take a little more time, but ultimately, you’ll contribute to the code’s coherence, readability, and simplicity, while reducing the workload for those who come after you.
Please note that I haven’t mentioned refactoring in this discussion. Although I encourage you to refactor whenever possible, that topic deserves another post entirely.
Entrepreneurs: Are You Zooming Out Enough? Are You Solving the Right Problem?
Sometimes, what we believe to be the problem is merely a symptom of a larger issue or a problem in the existing state-of-the-art solution. While it might be a 1.5X or 2X better solution, it also probably means we are not addressing the true underlying need.
Most innovations are evolutionary, building upon previous innovations. While there’s nothing wrong with such progress, the greatest breakthroughs and disruptions occur when innovators understand the genuine needs of users and take a totally different approach, deviating from common sense.
Let’s consider some examples:
The Car Isn’t Just a Faster Horse
Henry Ford is often quoted as saying, “If I had asked people what they wanted, they would have said faster horses” (although he likely never actually said this).
People didn’t need a better horse; they needed a faster and safer way to travel from point A to point B.
By the way, have you noticed that since the introduction of the Ford Model T in 1908, the driving experience hasn’t changed much? Autonomous cars may bring a different aspect, but it’s still an evolution rather than a revolution.
So, if I want to travel from point A to point B, what about teleportation or some Floo powder?
Feeling up for some challenges?
Shirts That Don’t Require Ironing
I hate ironing, although I don’t have to do it very often anymore. I don’t know anyone who enjoys it. Over the years, many inventions have been made to address this chore.
The iron has evolved from a box filled with burning coal to electric irons with steam or without, designed for horizontal or vertical use, with coffee brewer or without (I just made it up). The advancements are numerous (someone even wrote about them a web page. Each solution created over the years solves a problem created by the previous one, such as introducing anti-calc mechanisms to prevent steam nozzle clogging in earlier models. However, no matter how it’s done, I still need to iron shirts!
But none of these solutions have addressed the real need — I need a shirt that comes out of the cleaning without any wrinkles. Please invent a shirt that doesn’t require ironing. That’s what I’m talking about!
Hate Putting Dishes in and Out of the Dishwasher?
A creative friend of mine once mentioned that he wanted to solve the annoying task of loading and unloading dishes from the dishwasher. We started discussing integrating the kitchen sink, dishwasher, and cabinet.
Sounds great, right? You probably already know where I’m going with this. (No, we shouldn’t resort to single-use plastic dishes. We have a planet to save!)
Please invent dishes that clean themselves or some kind of fairy dust that can be sprayed over them to make them clean.
Where Does It Apply to You?
Everywhere. All the time.
Whether you’re a developer, entrepreneur, product manager, QA, store owner, gardener, cook, or anything else, when you encounter a problem or a challenge, don’t take the current state of the art for granted. Zoom out, ask yourself what the real problem is that you need to solve, and then unleash your creativity.
I highly recommend the book “Fifty Inventions That Shaped the Modern Economy” for numerous examples of inspiration.
I urge you to share examples from your daily work — things you believe cannot be zoomed out (challenge me) or instances where you successfully applied this concept (so I can feel proud of you).
Good luck!
