Explained Explained

How to Solve Problems Better: A Practical Framework for Work

Learn how to solve problems by defining the real issue, testing assumptions, comparing options, measuring results and adapting when conditions change.

Team defining a work problem and comparing evidence before choosing a solution
AI-generated editorial image — Editors Outlook
Text size

How to Solve Problems Better: A Practical Framework for Work

A fast answer can sometimes be evidence that the problem was defined too quickly. Sales are falling, so launch another campaign. A project is late, so add more people. Customers are complaining, so retrain the service team. A machine has failed, so replace the part. Any of those responses might eventually prove correct, but each can also attack the most visible symptom while leaving the mechanism producing it untouched.

Strong problem solving therefore begins before solution generation. The first task is to understand what is actually happening, what outcome is required and what information is still missing. This becomes especially important when situations are changing while people are trying to solve them.

The OECD's 2023 Survey of Adult Skills assesses what it calls adaptive problem solving: the capacity to achieve a goal in a dynamic situation when the method for reaching that goal is not immediately available. Its framework emphasises cognitive and metacognitive processes involved in defining the problem, searching for relevant information and applying a solution while adjusting as conditions change. (oecd.org)

That description resembles real workplace problems more closely than the neat exercises found in textbooks. The information may be incomplete, several explanations may fit the evidence, constraints can change and an intervention can alter the system being managed. Good problem solvers are therefore not simply people who produce answers quickly. They are people who can progressively reduce uncertainty without confusing confidence with evidence.

Problem Solving Is a Process, Not One Skill

Problem solving is often discussed as though someone either possesses the skill or does not. In practice, it depends on several capabilities that can vary independently. A person may be excellent at analysing data but poor at defining what decision the analysis is supposed to support. Another may generate creative solutions but fail to evaluate risk. Someone else may choose well but never check whether the intervention actually worked.

The process begins with problem representation: accurately describing the current situation, desired outcome and relevant constraints. It then requires information search and diagnosis, followed by generating possible actions, evaluating trade-offs, implementing the chosen response and monitoring what happens afterward. When circumstances change, the solver may need to revise both the solution and the original understanding of the problem.

The OECD's adaptive problem-solving framework reflects this dynamic structure. Rather than limiting problem solving to a digital environment or a fixed puzzle, the current assessment focuses on people's ability to define, search and apply solutions flexibly as information and circumstances evolve. (oecd.org)

This also explains why expertise in one stage does not guarantee success across the whole process. Analysis without action can become paralysis. Action without diagnosis creates rework. Creativity without evaluation creates attractive but unsuitable ideas. Execution without monitoring turns implementation into an assumption that the problem must now be solved.

Define the Problem Before You Embed a Solution

One of the easiest ways to narrow thinking prematurely is to put the proposed solution inside the problem statement. “We need a new CRM” sounds like a problem, but it is already a recommendation. The actual problem might be that sales representatives cannot see current customer status, duplicate follow-ups are being sent and important opportunities are being missed.

That distinction creates space for diagnosis. Perhaps a new CRM really is required. But perhaps the existing system is poorly configured, data are not synchronised, ownership is unclear or employees have developed parallel spreadsheets because the official workflow does not meet their needs. The correct intervention depends on which mechanism is producing the observed failures.

A useful problem statement therefore describes the gap rather than prescribing the remedy. It should identify what is happening now, what should be happening instead and why the difference matters. “Customer applications currently take nine days to process, while the service commitment is four days, and most additional time appears between verification and approval” is more useful than “we need automation.”

This discipline is simple but powerful because solution ideas influence what evidence people notice. Once a team becomes committed to buying software, information supporting software adoption can receive disproportionate attention while evidence pointing toward a process or ownership problem is ignored.

Good problem definition keeps the search open long enough for the diagnosis to earn the solution.

Separate the Visible Symptom From the Mechanism Producing It

A symptom tells you that something is wrong. It does not necessarily explain why.

Repeated late deliveries are a symptom. Possible causes include unrealistic scheduling, unpredictable suppliers, rework caused by quality failures, approval delays, insufficient capacity, poor prioritisation or incorrect order data. Several may operate simultaneously.

The same distinction appears across professions. Falling sales do not prove that marketing is weak. Customer complaints do not prove that employees need retraining. High staff turnover does not prove that compensation is the only issue. A broken component does not prove the component itself caused the failure.

This is where evidence becomes important. Useful sources may include process timestamps, error categories, workload data, service records, customer reports, direct observation and interviews with people performing the work. Process mapping can also reveal where waiting, rework and handoffs actually occur rather than where managers assume they occur.

The objective is not to search forever for one perfect “root cause.” Complex systems often contain interacting causes. A late project may combine optimistic estimating, late customer feedback and weak escalation. Fixing only one factor may improve performance without eliminating the problem completely.

The better question is often: Which mechanisms contribute materially enough that changing them could improve the outcome?

That keeps causal analysis practical.

Define Success and Constraints Before Comparing Solutions

A technically effective solution can still be the wrong decision.

Suppose a company wants to reduce customer waiting time. One option could cut the delay dramatically but require twice the available budget. Another could be fast to implement but create unacceptable security risk. A third might provide a smaller improvement while using existing systems and remaining easily reversible.

Without explicit criteria, teams tend to evaluate options using whatever characteristic is most salient at the moment. The cheapest proposal wins one meeting; the fastest wins another; the most technologically impressive wins the next.

Problem solving becomes more disciplined when the objective and constraints are defined first. What result is needed? By when? What level of improvement would justify intervention? Which budget, safety, legal, ethical, quality or operational boundaries cannot be crossed?

Constraints are not necessarily obstacles to good reasoning. They define the actual decision environment. A theoretical solution requiring authority, money or time that the organisation does not possess is not automatically better because it would perform perfectly under imaginary conditions.

This also prevents optimisation around the wrong metric. Reducing call-handling time might appear successful until customer repeat calls rise. Increasing production speed may reduce unit cost while defect rates increase. Good objectives therefore capture the outcome that matters rather than one convenient intermediate measure.

Search for Evidence That Could Prove Your Current Explanation Wrong

People naturally form hypotheses early. Once a plausible explanation exists, they can begin collecting evidence that confirms it.

Better problem solving deliberately searches for information capable of changing the diagnosis.

If you think a project is late because one team lacks capacity, ask what evidence would demonstrate that capacity is not the main problem. Compare workload with periods when deadlines were met. Examine whether work is actually waiting for approvals rather than labour. Ask another team where delays enter the process. Look for cases that contradict the general pattern.

This is not about mechanically “arguing both sides” of every issue. Some explanations are much better supported than others. The goal is to prevent early confidence from stopping useful investigation.

A few questions are particularly powerful: What would I expect to observe if this explanation were correct? What should I observe if an alternative explanation were true? Which important variable has not yet been measured? Who experiences a different part of the process and may therefore see something I cannot?

This turns opinions into testable hypotheses.

The ability to revise an initial model is central to adaptive problem solving. The OECD assessment specifically emphasises flexible adjustment in dynamic situations rather than repeatedly applying a fixed strategy after conditions change. (oecd.org)

Generate More Than One Credible Option

Once the problem is reasonably understood, teams often become attached to the first plausible solution. This is especially likely when one idea arrives from a senior person, fits an existing technology or sounds intuitively obvious.

Generating alternatives creates comparison.

For a workflow problem, one option might remove an unnecessary step. Another could change ownership. A third could improve information available at the handoff. A fourth might automate part of the process. A fifth could change the sequence in which work occurs. The purpose is not to invent dozens of unrealistic ideas but to prevent the decision from becoming a choice between one proposal and doing nothing.

Creative thinking matters here, but it should remain connected to evidence. The World Economic Forum's Future of Jobs Report 2025 found analytical thinking was the most frequently identified core skill among surveyed employers, considered essential by roughly seven in ten respondents, while creative thinking ranked fourth. Employers also expected both analytical and creative thinking to remain increasingly important as work changes. (weforum.org)

Those skills are complementary. Analysis helps determine what the problem is and what constraints matter. Creativity broadens the set of possible responses. Neither is enough by itself.

One option is not really a decision.

It is a proposal waiting for comparison.

Compare Options Explicitly and Test When Uncertainty Is High

Once several plausible actions exist, compare them against criteria defined earlier. Expected impact, implementation cost, speed, reversibility, safety, legal exposure, stakeholder effects and uncertainty are common dimensions. The right criteria depend on the problem.

The comparison does not need artificial mathematical precision. If the evidence only supports broad estimates, use ranges or qualitative confidence rather than pretending to know that one option is exactly 17% better. False precision can make weak evidence appear stronger than it is.

Uncertainty also determines whether experimentation makes sense. When an intervention is reversible and the downside is limited, a pilot may produce better evidence than another week of meetings. A team might test a revised checklist in one location, use a new sales script for a small customer segment, run an automation on historical data or change one scheduling rule before altering the entire operation.

The pilot should answer a defined question. Did the new checklist reduce missing information without adding unacceptable processing time? Did the customer script increase conversions or merely increase call duration? Did the automation identify the same cases as experienced staff?

Without a learning question, experimentation can become activity rather than evidence.

Small tests are valuable partly because they make being wrong cheaper. Instead of requiring people to defend an idea because the organisation has already invested heavily in it, a pilot creates permission to stop when the evidence is poor.

Measure Whether the Problem Improved, Not Whether the Solution Was Launched

Implementation is often mistaken for success.

A company launches a new system and describes the project as complete. A training programme reaches 500 employees and is declared successful. A redesigned workflow goes live on schedule and the implementation team celebrates.

Those achievements matter operationally, but they do not answer the original question.

Did the error rate fall? Did delivery become faster? Did customers stop encountering the original problem? Did productivity improve? Did the bottleneck simply move downstream? Did the intervention create a side effect that now requires attention?

Measurement should therefore return to the outcome defined at the beginning.

This is particularly important because systems react. When one bottleneck is removed, another may become visible. Employees may create workarounds around a poorly designed process. Customers may respond differently to a changed service. Competitors may alter their behaviour.

The solution itself can therefore change the environment in which the original problem existed.

Strong problem solving includes monitoring and adaptation after implementation rather than treating the decision as the end of reasoning.

Some Problems Need Management Rather Than Permanent Solutions

Not every problem behaves like a puzzle with a final correct answer.

Demand fluctuates. Markets change. Employees learn. Competitors respond. Supply chains encounter disruptions. Regulations evolve. Technologies create new possibilities and new vulnerabilities.

In such environments, the objective may not be to solve the problem once and permanently. It may be to maintain performance within an acceptable range while continuing to adapt.

A hospital cannot permanently solve patient demand. A supply-chain team cannot eliminate uncertainty from global logistics. A cybersecurity function cannot identify one defence and consider the problem finished. Strategy is especially dynamic because competitors respond to decisions made by other organisations.

This does not make structured problem solving useless. It changes the expected outcome. Instead of searching for permanent closure, teams create feedback systems capable of detecting change and adjusting decisions.

This is one reason the OECD shifted its adult-skills assessment toward adaptive problem solving. The framework is designed around complex and changing situations rather than tasks in which a single fixed sequence will always work. (oecd.org)

The valuable capability is not simply reaching an answer.

It is knowing when the answer needs to change.

Frameworks Cannot Replace Domain Expertise

General problem-solving methods are useful because they organise reasoning across many fields. They cannot substitute for specialised knowledge.

An experienced engineer recognises failure modes that a generic checklist may never suggest. A lawyer knows distinctions in statute and precedent that a non-specialist may not realise exist. A clinician can interpret a collection of symptoms using knowledge of physiology, disease probability and treatment risk. An accountant recognises control problems that an outsider might mistake for administrative inconvenience.

Domain expertise changes the quality of the hypotheses people can generate.

A novice can follow every step of a problem-solving framework and still overlook the most important explanation because they do not know enough to consider it.

General reasoning and specialised knowledge therefore work together. A framework helps experts structure diagnosis, challenge assumptions and compare options. Expertise supplies the mechanisms, constraints and patterns that make those stages meaningful.

This is particularly important in safety-critical, medical, legal, financial and technical environments, where enthusiastic generalists should not mistake confidence with a framework for professional competence.

Strong Problem Solving Is Disciplined Adaptation

A practical problem-solving loop can be remembered through seven actions: define the gap, diagnose the mechanisms, design credible options, decide against explicit criteria, do the intervention at an appropriate scale, detect what happened and develop the next response from the new evidence.

The labels matter less than the sequence.

Define before prescribing. Search before assuming. Generate alternatives before becoming attached to one. Compare trade-offs before committing resources. Test when uncertainty is high and failure is reversible. Measure the original outcome after implementation. Change the plan when new evidence changes the problem.

The World Economic Forum's employer survey helps explain why these capabilities remain professionally important even as technology becomes more capable. Analytical thinking continues to rank at the top of employers' reported core skills, while creative thinking, technological literacy, resilience and lifelong learning also remain important. (weforum.org)

Faster tools can generate proposed answers, analyse large datasets and automate parts of implementation. They do not eliminate the need to decide whether the right question was asked, whether the evidence supports the diagnosis, which trade-offs matter or whether the environment has changed enough to invalidate yesterday's answer.

Strong problem solvers are therefore not defined by always knowing what to do immediately.

They are defined by what happens when the answer is not obvious.

They turn vague frustration into a specific gap, symptoms into testable explanations and ideas into comparable options. They act when evidence is sufficient, monitor reality afterward and revise their reasoning without treating a changed plan as a personal defeat.

That combination of representation, evidence, judgement, experimentation and adaptation is what turns problem solving from quick answer generation into a durable professional skill.

Sources & further reading

B
By Brijesh Dwivedi

Founder and Editor-in-Chief of Editors Outlook, responsible for editorial standards, publishing operations and transparent corrections.

Was this article helpful?

Spotted an error or want to suggest a clarification? Report a correction.

Comments (0)

Please login to post a comment.

No comments yet — be the first!