Problem Solving: How To Define The Real Issue And Choose Better Actions

Problem solving is not the same as rushing toward a solution. The first solution is often a reaction to the visible symptom, not an answer to the real issue. Better problem solving starts by slowing down enough to understand what is happening, what matters, and what would count as progress.

This matters because many personal and professional problems are solved at the wrong level. A team adds another meeting when the real problem is unclear ownership. A person buys another productivity tool when the real problem is too many commitments. A business changes tactics when the real problem is a weak offer. A leader asks for motivation when the real problem is friction in the system.

This article explains problem solving as a practical human-performance skill: defining the problem, separating symptoms from causes, understanding constraints, generating options, testing assumptions, choosing tradeoffs, acting, and learning from feedback.

Short Answer

Problem solving is the process of turning a messy situation into a clearer decision and action path. It requires defining the real problem, understanding causes and constraints, generating options, testing assumptions, making a tradeoff, and learning from results.

Weak problem solving	Better problem solving
Start with a favourite solution	Start by defining the real problem
Treat symptoms as causes	Separate symptoms, root causes, and constraints
Look for one perfect answer	Compare options and tradeoffs
Debate endlessly	Run small tests where uncertainty is high
Move on after acting	Review feedback and update the system

The practical rule is simple: if the problem is poorly defined, the solution will usually be expensive, fragile, or misdirected.

What Problem Solving Really Means

Problem solving begins when reality and desired reality do not match. Something is not working, not clear, not efficient, not healthy, not profitable, not fair, not safe, or not aligned with the goal.

A problem may be technical, emotional, social, financial, operational, strategic, or behavioural. Many real problems are mixed. That is why one method rarely solves everything. Some problems need analysis. Some need empathy. Some need negotiation. Some need experimentation. Some need a decision with incomplete information.

The OECD’s work on complex problem-solving skills emphasises that meaningful problem solving is contextual and adaptive, not just following a fixed procedure. That is the right mindset. A framework helps, but the solver still has to notice the situation.

Good problem solving is therefore not a five-step performance. It is disciplined adaptation.

The Cost Of Solving The Wrong Problem

Solving the wrong problem is costly because it creates motion without improvement.

If a company has a retention problem and treats it only as a recruiting problem, it keeps hiring into a leaking system. If a person has an energy problem and treats it only as a motivation problem, they may push harder while ignoring sleep, workload, nutrition, or stress. If a team has a quality problem and treats it only as an individual performance problem, it may miss unclear standards or broken handoffs.

Solving the wrong problem can feel satisfying because action is visible. But visible action is not the same as useful action.

A useful question is: if this solution worked perfectly, would the real pain disappear? If not, you may be solving a symptom.

Define The Problem Before Solving It

Design thinking places strong emphasis on understanding and defining the problem before ideating solutions. Stanford teaching material describes stages such as empathise, define, ideate, prototype, and test. The exact labels matter less than the discipline: understand before solving.

A good problem definition includes the current state, desired state, affected people, constraints, evidence, and the cost of doing nothing.

Weak definition: “Our meetings are bad.”

Better definition: “Our weekly project meeting takes 90 minutes, but decisions are still unclear afterward because agenda items are not tied to decision owners, required inputs, or next actions.”

The second definition gives you something to solve. It points toward agenda design, decision rights, preparation, and follow-up. The first only creates frustration.

How To Write A Better Problem Statement

A useful problem statement is specific enough to guide action but not so narrow that it hides the cause.

Use this structure: current state, desired state, affected people, evidence, constraints, and why now.

Element	Question
Current state	What is happening now?
Desired state	What should be happening instead?
Affected people	Who experiences the problem or must change behaviour?
Evidence	What proves this is happening?
Constraints	What limits time, budget, risk, authority, or capacity?
Urgency	Why does this need attention now?

This prevents a common mistake: writing the solution into the problem. “We need a new app” is not a problem statement. The problem may be slow communication, missing data, unclear ownership, or a workflow that needs redesign. The app is only one possible answer.

Symptoms, Causes And Constraints

Problems usually have symptoms, causes, and constraints.

A symptom is what you notice: missed deadlines, fatigue, conflict, low sales, high churn, poor focus, recurring errors. A cause is what produces the symptom: unclear ownership, insufficient skill, poor incentives, missing data, unrealistic workload, broken process, weak positioning, or emotional avoidance. A constraint is a real limit: budget, time, legal rules, health, capacity, technology, or stakeholder needs.

Do not confuse these categories. If you treat a constraint as a cause, you may waste time fighting reality. If you treat a symptom as a cause, you may apply surface fixes. If you ignore constraints, you may design a solution that cannot survive.

A simple root-cause question is: what would have to be true for this problem to keep happening? Keep asking until the answer points to a system, decision, behaviour, or missing capability you can actually address.

Generate Options Before Choosing One

People often choose too early. They grab the first plausible solution because action feels better than uncertainty.

Better problem solving creates options first. The goal is not to generate endless ideas. The goal is to avoid locking onto one answer before the problem is understood. Design thinking uses ideation to widen the solution space before narrowing it.

For most practical problems, generate at least three options: a low-cost fix, a structural fix, and an experimental fix. The low-cost fix helps now. The structural fix addresses the system. The experimental fix tests uncertainty before a bigger commitment.

For example, if a team misses deadlines, a low-cost fix may be a clearer weekly planning ritual. A structural fix may be reducing active projects. An experimental fix may be testing a new handoff process for two weeks.

Tradeoffs And Decision Quality

Every solution has tradeoffs. A faster solution may be less robust. A cheaper solution may require more manual work. A simple solution may not handle every edge case. A comprehensive solution may take too long.

Decision quality improves when tradeoffs are named before action. What are we optimising for: speed, cost, quality, learning, safety, morale, reversibility, or long-term resilience? If the team does not agree on the priority, disagreement will continue under the surface.

Good problem solving also separates reversible and irreversible decisions. Reversible choices can often be tested quickly. High-risk or hard-to-reverse choices need more evidence, stakeholder review, or phased rollout.

The question is not “What is the perfect answer?” It is “What is the best next action given the evidence, risk, constraints, and learning value?”

Prioritise Uncertainty

Not every unknown deserves equal attention. Some unknowns are interesting but irrelevant. Others decide whether the whole solution works.

Before taking a large action, identify the critical uncertainty. Will users adopt it? Can we deliver it? Is the problem painful enough? Is the cost acceptable? Will this habit survive a normal week? Does the stakeholder actually have authority? Is the bottleneck technical, behavioural, or political?

Then design the smallest test that answers that uncertainty. If adoption is the risk, test with users. If feasibility is the risk, build a prototype. If behaviour is the risk, run a one-week trial. If alignment is the risk, hold the decision conversation before building anything.

This protects energy. You stop trying to solve every unknown and focus on the unknown that could make the solution fail.

Choose Which Problem To Solve First

Good problem solvers do not treat every problem as equally urgent. They choose the problem that unlocks the most value, removes the most repeated friction, or reduces the biggest risk.

Use four questions. How often does this problem repeat? How costly is it when it happens? How much control do we have over it? What other problems would become easier if this one improved?

A recurring small problem can be more important than a dramatic one-time problem because repetition compounds. A small handoff error that happens every week may deserve attention before a rare inconvenience. A personal energy problem that affects every decision may deserve attention before another productivity technique.

Prioritisation prevents problem solving from becoming scattered repair work. You solve the constraint that makes the system easier to run next week, month, and quarter.

Prototype, Test And Learn

When uncertainty is high, testing beats arguing. Stanford design thinking material treats prototyping and testing as ways to learn from contact with reality. A prototype does not need to be polished. It needs to reveal something useful.

In personal life, a prototype might be a one-week routine. In business, it might be a landing page, a small pilot, a script, a manual service, a draft process, or a customer interview. In operations, it might be one team using a new handoff before rolling it out everywhere.

The test should be tied to a question. Are people willing to use this? Does this reduce errors? Does this save time? Does this habit survive normal days? Does this offer create demand? Does this communication reduce confusion?

A test without a learning question is just activity. A test with a learning question improves the next decision.

Problem Solving With People

Many problems are not solved alone because they involve stakeholders, users, customers, partners, teams, or family members. Technical correctness is not enough if the solution does not fit the people who must live with it.

Human-centred problem solving starts by understanding the experience of the people affected. What do they need? What are they trying to do? What blocks them? What incentives shape behaviour? What do they fear? What would make the solution easier to adopt?

This does not mean every stakeholder gets everything they want. It means the solution is designed with reality in mind.

A good people-centred question is: whose behaviour must change for this solution to work, and why would they actually change?

A Practical Example

Imagine a person who keeps saying, “I need better discipline.” They want to write consistently but keep missing sessions.

A weak solution is to buy another productivity app. A better problem-solving process starts with the current state: writing happens only once a week, usually after deadlines create pressure. Desired state: four focused writing sessions per week. Evidence: calendar history, unfinished drafts, and repeated missed sessions. Constraints: childcare, work fatigue, and no quiet place in the evening.

The root issue may not be discipline. It may be that writing is scheduled after the person is already depleted. Options include morning writing before messages, a shorter daily session, a weekly writing block outside the house, or reducing other commitments.

The experiment could be simple: write for 25 minutes before checking messages on Monday, Wednesday, and Friday for two weeks. The feedback signal is not whether the person feels inspired. It is whether the session happens and whether draft output improves.

This example shows the value of problem solving: the answer becomes less moral and more operational.

Common Problem-Solving Mistakes

The first mistake is solving before defining. This creates fast motion and slow learning.

The second mistake is confusing symptoms with causes. The visible issue is not always the source.

The third mistake is overcomplicating. Some problems need a simpler standard, fewer active priorities, or a clearer next action.

The fourth mistake is undercomplicating. Some problems involve people, incentives, history, risk, and constraints. Treating them as simple can make them worse.

The fifth mistake is debating when testing is possible. If a small experiment can answer the question, run it.

The sixth mistake is failing to review. A solution is not complete until you know whether it changed the system.

A Practical Problem-Solving Framework

Use this framework for personal, team, or business problems.

1. Describe The Current State

What is happening now? Use observable evidence, not only frustration.

2. Define The Desired State

What would be different if the problem were solved? Define success clearly enough to recognise it.

3. Separate Symptoms, Causes And Constraints

List what you notice, what may be producing it, and what limits the possible solution.

4. Identify Stakeholders

Who is affected, who decides, who implements, and who can block or support the solution?

5. Generate Multiple Options

Create at least three plausible paths before choosing. Include a quick fix, structural fix, and testable experiment.

6. Choose The Next Best Action

Compare tradeoffs. Choose the action that fits the evidence, risk, constraints, and learning value.

7. Test And Review

Decide what signal will show whether the solution is working. Review the outcome and adjust.

Where This Fits In Human Performance

This article belongs in the Human Performance pillar because problem solving affects decision quality, work, learning, resilience, leadership, and personal agency.

Human performance is not only effort. It is the ability to see clearly under pressure, define the right issue, avoid wasted motion, and turn uncertainty into learning. Strong problem solving reduces stress because the next action becomes visible.

A practical next step is to take one problem you keep revisiting and rewrite it as a problem statement: current state, desired state, affected people, constraints, and evidence. Do that before choosing another solution.

Better problem solving starts when you stop asking for the answer too early.

FAQ

What is problem solving?

Problem solving is the process of defining a gap between current reality and desired reality, identifying causes and constraints, generating options, choosing an action, and learning from the result.

What is the first step in problem solving?

The first step is defining the real problem. A clear problem statement prevents wasted effort on symptoms or favourite solutions.

Why do people solve the wrong problem?

People often react to visible symptoms, pressure, emotion, or familiar solutions before understanding causes, constraints, and stakeholders.

How do I find the root cause of a problem?

Ask what would have to be true for the problem to keep happening. Look for system conditions, incentives, missing skills, unclear ownership, or repeated constraints.

How many solutions should I consider?

Consider at least three: a low-cost fix, a structural fix, and a testable experiment. This reduces the risk of choosing too early.

When should I test instead of debate?

Test when a small, low-risk experiment can answer a key uncertainty faster than discussion can.

What makes someone good at problem solving?

Strong problem solvers define clearly, listen well, separate symptoms from causes, compare tradeoffs, test assumptions, and update based on feedback.

Source anchors: Stanford design thinking teaching material; Stanford d.school design thinking facilitator guide; OECD on complex problem-solving skills; PMC on cognitive load theory and working memory; APA on multitasking and switching costs.