Solve The Right Problem

Finding the right problem is just a few questions away.

Oct 23, 2025

“Hi Michał! Can you implement a button in the admin panel so we can export emails of new users?” — my clients asked.

“Of course I can!” — I answered without asking any questions and jumped to the implementation. It was early in my career, and I delivered it. It worked as they wanted.

But should it have been done in the first place?

One simple “Why?” was the question I forgot to ask. Clients were manually importing exported emails into the external mailing system. Instead of blindly following their request, I could have asked what they wanted to achieve and coded a proper solution.

“If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.”
― Albert Einstein

Outcomes will tell if we tackled the right problem, but there are ways we can try to dive deeper into it before starting to craft the solution.

The difference between experienced and inexperienced engineers is the ability to find the right problem to solve. Experience helps, but frameworks like Five Whys can shortcut the painful learning process.

Ask Better Questions

The closer we are to the baseline depth of the issue, the closer we are to finding the right solution.

Five Whys

Ask five times “Why?”, going deeper with each iteration.

Example:

Problem: The server is responding slowly to certain API requests.

Why? The server is experiencing a higher load due to excessive CPU and memory usage.

It may seem like a simple fix: replacing the server with a more powerful machine should resolve the issue, right?

Not quite. We haven’t gone deep enough. We are only scratching the surface of the problem. Without asking more “whys?”, our solution will add additional costs and provide only a temporary fix.

Problem: The server is responding slowly to certain API requests.

Why? The server is experiencing a higher load due to excessive CPU and memory usage.
Why? Database queries are taking a long time and consuming significant CPU power.
Why? The database queries are not optimised.
Why? The code retrieving data from the database performs unnecessary joins and the data is not properly indexed.
Why? The team that worked on the feature lacked the necessary knowledge to design a query that would be optimal and efficient for databases.

By fixing queries, adding monitoring to benchmark queries, training our team, and spreading best practices within the organisation, we can address both the current and future problems related to database performance.

The main critique of this method focuses on depth, as for most of cases, just five iterations might not be enough. It was coined by Toyota’s engineers in their production lines, where five steps were enough to determine the source of defects.

Do you think that the provided database example is fully resolved?

No. We didn’t uncover the root cause. It misses the sixth: “Why did database issues appear in the first place?”

Why did the team lack knowledge? (No learning budget?)
Why wasn’t the code reviewed? (Gaps in the process?)
Why no database expert on the team or in the company? (Team composition issue?)

The closer to the real issue we get, the better, as it allows us to find better solutions. Don’t feel obliged to finish at the 5th “Why” if you need more depth.

5E Framework

The 5E framework provides us with five steps to ensure that we don’t jump to solutions. It was described by Julia Binder and Michael D. Watkins, in their HBR article.

“A study by Paul Nutt of Ohio State University, looked at 350 decision-making processes at medium to large companies and found that more than half failed to achieve desired results, often because perceived time pressure caused people to pay insufficient attention to examining problems from all angles and exploring their complexities.” — "To Solve a Tough Problem, Reframe It"

5E for examining the root cause, in a nutshell:

Expand: Ask “What if...?” questions to challenge how the problem is defined. What if we’re defining this problem too narrowly? What if different stakeholders see this differently?

Examine: Dive deeper to find the cause. Are we looking at the right data? Is there true causation? Five Whys might help here, too

Empathise: Go through stakeholders and map their perspectives. What is the pain of our customers? Why are users leaving?

Elevate: Examine the problem from a broader perspective. Does it influence long-term goals? How will it matter in a few years?

Envision: Define your desired future state, but remember to make it specific and measurable. Then work backwards from it to map out milestones and action steps. What needs to happen in the short term? What about long-term? Build your plan using everything learned from previous stages.

Five Whys vs 5E Framework?

Five Whys works best for engineering problems, like our database example. The 5E framework is broader, and it includes root cause analysis plus stakeholder mapping. Use Five Whys when you’ve grasped the first level of an issue. Use 5E when even the initial problem is unclear or involves multiple stakeholders.

Summary

I’m solution-oriented, so I often jump straight into solutions, and it’s difficult to control it. But try to pause and ask relevant questions. Challenge assumptions, and go deeper.

The next time someone asks you to implement a button, pause. Ask “Why?”. Maybe they don’t need a button, but something else which solves their problem.

Are you solving the right problem?

Thanks for reading!

— Michał

Share Perspectiveship