A problem is a gap between a current condition and a desired condition when the path from one to the other is blocked, uncertain, costly or not yet known. If you are asking “what is a problem?”, the strongest definition includes four elements: a present state, a goal or standard, an obstacle, and a need for action or understanding. Problems appear in mathematics, science, engineering, medicine, education, software, business, public policy and everyday life. What makes something a problem is not simply that it is unpleasant; it is that an important objective is not being met and some form of reasoning, decision or intervention is required.
A complete explanation of problems must separate a problem from a symptom, cause, risk, constraint, issue and question. A symptom is an observable sign that something may be wrong. A cause contributes to why the condition exists. A risk is an uncertain future effect. A constraint limits possible action. An issue is a broad matter requiring attention. A question seeks information. These can all occur inside one problem, but treating them as interchangeable leads to poor diagnosis. “Sales are falling” may be the symptom; the problem could be loss of customer fit, distribution failure or inaccurate measurement.
This guide explains problems from first principles: goals, gaps, symptoms, root causes, constraints, stakeholders, scope, boundaries, problem framing, well-defined and ill-defined problems, complexity, uncertainty, bottlenecks, feedback loops, mathematical and engineering problems, diagnostic and decision problems, software and business problems, social and educational problems, decomposition, models, root-cause analysis, experimentation, prioritisation, AI and problem-solving. The goal is a durable operating model: define the desired state, verify the current state, distinguish symptoms from causes, map constraints and dependencies, test explanations, compare interventions and keep monitoring until the underlying gap is genuinely reduced.
What Is a Problem? A Short Definition
A problem exists when reality differs from a desired or required state and there is no immediate, certain or costless path to close the gap. A broken pipe is a problem when water must remain contained. A mathematical exercise is a problem when a result must be derived from given conditions. A scientific problem may be an unexplained observation. The common structure is a goal plus an obstacle.
Why Problems Need Goals
A condition becomes a problem relative to an objective. Rain is not inherently a problem; it becomes one for an outdoor event that requires dry conditions and can be a benefit for a reservoir needing water. Without a goal, “problem” becomes a vague label for dislike. Stating the objective clarifies why the condition matters and prevents teams from solving something that is merely unusual rather than consequential.
Current State and Desired State
One of the simplest problem models compares the current state with the desired state. If a service currently takes ten days and the requirement is three, the gap is seven days. Real problems may have several dimensions—speed, cost, quality and safety—and improvement in one can worsen another. Still, explicitly describing both states converts vague dissatisfaction into something that can be measured and discussed.
Problems Versus Symptoms
A symptom is evidence that a problem may exist; it is not necessarily the problem itself. Repeated late deliveries are a symptom. Causes could include forecasting error, picking delays, route design or supplier unreliability. Treating the symptom as the whole problem often creates temporary fixes. Diagnosis asks what mechanism produces the symptom and which change would prevent recurrence.
Problems Versus Causes
A cause explains why a problem occurs. The problem statement should describe the gap without prematurely asserting a cause that has not been established. “Customers are leaving because prices are too high” combines observation and hypothesis. A safer starting point is “Retention fell from X to Y,” followed by tests of price, product experience, competition and other plausible mechanisms.
Problems Versus Risks
A problem is normally an existing gap or obstacle; a risk concerns uncertain future outcomes. A server that has failed is a problem. A server that could fail during peak demand is a risk. The distinction changes action: problems require repair or resolution, while risks require prevention, mitigation, transfer or acceptance. Some events move from risk to problem when they occur.
Problems Versus Constraints
A constraint limits the solution space but is not automatically the problem. A fixed budget, legal rule or physical law can constrain what can be done. Good problem-solving incorporates real constraints early. Imagined constraints should be challenged, because teams often inherit rules from previous processes that no longer apply and then treat them as immutable facts.
Problems Versus Issues
“Issue” is often used broadly for a topic requiring attention, disagreement or active difficulty. A problem is usually more structured because it contains an unmet objective. Calling something an issue can be useful before the goal or cause is understood. The next step is to translate the issue into a clearer statement of what condition is unacceptable and why.
Problems Versus Questions
A question requests information; a problem requires a change, resolution or proof. Questions are tools for solving problems because they expose unknowns. “Why is the motor overheating?” is a diagnostic question inside the problem that the motor cannot operate within its safe temperature range. Separating the question from the problem prevents information gathering from becoming an end in itself.
Problem Framing
Problem framing decides which gap is being solved and which factors are inside the boundary. A city can frame congestion as insufficient road capacity or as excessive delay in moving people. The second frame admits a wider range of solutions. Frames are necessary simplifications, but they should be treated as choices rather than invisible facts.
Problem Statements
A good problem statement identifies the affected system, current evidence, desired condition, consequence and important constraints without smuggling in an untested solution. “Install new software” is not a problem statement. “Order processing requires three manual reconciliations, producing a median delay of two days” creates a measurable target while leaving the solution open.
Scope
Scope determines how much of the system the problem includes. Too narrow a scope can optimise one step while moving cost elsewhere. Too broad a scope can make action impossible. Start with the smallest boundary that contains the mechanism and the important consequences, then expand if evidence shows that critical causes lie outside it.
Boundaries
Problem boundaries separate the focal system from its environment. A factory defect problem might include suppliers if incoming material quality contributes to failures. Boundaries can be organisational, geographic, temporal or conceptual. They should be revisited when analysis repeatedly finds external dependencies that determine internal outcomes.
Stakeholders
Different stakeholders can experience the same system differently. A process optimised for managers may create extra work for frontline staff; a policy that lowers average cost may reduce access for a small group. Mapping stakeholders helps reveal whose desired state defines the problem and who bears the effects of proposed changes.
Well-Defined Problems
A well-defined problem has clear starting conditions, allowable operations and a criterion for a correct solution. Many textbook mathematics problems have this form. Their difficulty can still be high, but the solver knows what counts as success. Well-defined problems are suitable for algorithms when the rules and search space can be represented formally.
Ill-Defined Problems
An ill-defined problem has ambiguous goals, incomplete information or contested criteria. “Improve education” is ill-defined until the population, outcomes, constraints and time horizon are specified. Real-world policy and design problems often begin this way. Solving them requires framing and negotiation before optimisation is meaningful.
Tame Problems
A tame problem is difficult but can be bounded and solved using established methods. Designing a beam to carry a specified load is complex engineering, yet requirements and physical laws can make the task tractable. Tame does not mean easy; it means the problem definition remains relatively stable while work proceeds.
Wicked Problems
Wicked problems have contested goals, interacting causes and solutions that change the system being solved. Urban poverty, climate adaptation and healthcare reform can have this character. There may be no final solution, only better or worse interventions. Stakeholders disagree not just about answers but about what the problem is. Iteration, participation and monitoring matter more than one permanent fix.
Simple Problems
Simple problems have stable cause-and-effect relationships and repeatable solutions. Replacing a standard fuse after confirming the fault can be simple. The danger is applying simple-problem habits to systems with hidden interactions. A checklist works when the situation truly repeats; it fails when context changes the mechanism.
Complicated Problems
Complicated problems contain many parts but can still be analysed through expertise, models and decomposition. Designing an aircraft is complicated. Components interact, but engineering knowledge can specify much of the behaviour. Complicated systems reward planning and specialisation, provided interfaces among components are well managed.
Complex Problems
Complex problems involve interactions that create adaptation, feedback and emergent behaviour. Outcomes may change when participants respond to the intervention itself. Managing an ecosystem or large organisation often has this property. Small experiments, monitoring and adaptive strategies can outperform detailed plans based on assumptions that will not remain stable.
Chaotic Problems
In a chaotic situation, immediate stabilisation may matter more than complete diagnosis. A severe incident can require stopping harm, restoring basic function and creating enough order to investigate. Once conditions stabilise, the problem can often be reframed into more analysable parts. Action and learning therefore occur in a different sequence from ordinary troubleshooting.
Root Causes
A root cause is a contributing cause whose removal or control can materially reduce recurrence. Complex events rarely have only one. Calling the last human action “the root cause” can hide design, training, workload and incentive conditions that made the error likely. Root-cause analysis should search for useful intervention points, not simply a person to blame.
Mechanisms
A mechanism is the process through which causes produce the observed problem. Knowing the mechanism helps predict when a fix will work. If overheating is caused by blocked airflow, cleaning the vent targets the mechanism. If the same temperature is caused by excessive electrical load, the same action will not solve it. Similar symptoms can arise from different mechanisms.
Dependencies
Problems often persist because one component depends on another. A delayed project may appear to be a scheduling problem while the real constraint is approval from an external regulator. Dependency maps show which inputs, services or decisions must occur before others can proceed. Hidden dependencies create surprises because local teams cannot directly control them.
Bottlenecks
A bottleneck is the limiting step that constrains overall throughput. Improving non-bottleneck steps can create little system benefit if work still accumulates at the constraint. Identifying the bottleneck requires measuring flow rather than guessing which activity looks busiest. Once the constraint moves, the problem must be reassessed because another step can become limiting.
Feedback Loops
Feedback loops make problems self-reinforcing or self-correcting. Congestion can create delays that cause drivers to change routes, redistributing traffic. Financial distress can increase borrowing cost, which worsens distress. Solving a feedback-driven problem requires understanding how an intervention changes future behaviour, not just the immediate state.
Trade-Offs
Many problems have no solution that maximises every desirable outcome. Faster service may cost more; stronger security may add friction; higher redundancy may reduce efficiency. Trade-offs should be made explicit so a team does not describe one criterion as “the problem” while silently sacrificing another. The desired state is usually a balanced region, not an impossible point where every metric is best.
Uncertainty
Problem-solving often begins before causes or future conditions are known. Uncertainty can concern measurements, mechanisms, stakeholder behaviour or external events. The correct response is not always more analysis. Sometimes a reversible experiment has greater information value than another meeting because it reveals how the system actually responds.
Unknown Unknowns
Some failures emerge from conditions not included in the original model. Robust systems therefore need monitoring, slack and recovery capacity. It is impossible to list every surprise, but it is possible to avoid brittle designs that work only when every assumption is correct. Resilience is part of problem-solving when uncertainty is deep.
Evidence
Evidence establishes whether the problem exists at the claimed scale and which explanations remain plausible. Baselines, logs, measurements, interviews and experiments can all contribute. Evidence should be selected to discriminate among hypotheses. Collecting whatever data are easiest can produce dashboards that describe activity without illuminating the mechanism.
Diagnosis
Diagnosis is the process of identifying which underlying condition best explains observed evidence. Medicine, engineering and software all use diagnostic reasoning. The strongest approach generates several plausible causes, chooses tests that separate them and updates confidence as results arrive. Jumping to the first familiar cause encourages confirmation bias.
Hypotheses
A hypothesis proposes a mechanism or cause that can be examined. “The system slows because memory usage grows over time” is stronger than “the system is old” because it suggests observable predictions. Good hypotheses generate tests and can be rejected. A list of unfalsifiable explanations creates the appearance of analysis without narrowing uncertainty.
Problem Decomposition
Decomposition divides a large problem into smaller parts. A school-attendance problem can be separated into transport, health, motivation, family constraints and administrative recording. The parts should be useful and recombined later, because interactions can matter. Decomposition is a thinking aid, not proof that the system itself is independent.
Abstraction
Abstraction removes detail to reveal structure. A logistics problem can be represented as nodes, routes, capacities and costs rather than individual streets and vehicles. Good abstraction makes reasoning easier while preserving the features that control the outcome. Bad abstraction removes exactly the detail responsible for failure.
Models
A model represents selected aspects of a problem so alternatives can be analysed. Models can be diagrams, equations, simulations or verbal causal maps. Every model omits something. The question is whether the omissions matter for the decision. Model validation compares predictions with relevant observations and checks performance outside the examples used to build it.
Mathematical Problems
Mathematical problems specify objects, constraints and a required result. They may ask for calculation, proof, construction, existence or optimisation. The main challenge is often representation: translating words into equations, diagrams or logical relationships. A solver who chooses the wrong model can calculate flawlessly and still answer the wrong problem.
Engineering Problems
Engineering problems seek designs that satisfy requirements under constraints. Strength, cost, safety, manufacturability, maintenance and environmental conditions can all matter. There may be many feasible solutions rather than one correct answer. Engineering therefore combines analysis with trade-off decisions and verification that the chosen design performs in real conditions.
Scientific Problems
A scientific problem can be an unexplained pattern, inconsistent observation or missing mechanism. The objective is understanding rather than immediate repair. Experiments and models narrow explanations. The history of science contains many cases where an anomaly initially treated as measurement error eventually exposed a deeper process, so unexplained observations should not be discarded merely because they are inconvenient.
Software Problems
Software problems range from isolated bugs to architectural failures. Reproducing the error, identifying inputs, examining logs and reducing the case are core diagnostic moves. A patch can stop one symptom while leaving the underlying design fragile. Strong debugging asks why the system allowed the invalid state and whether nearby paths share the same failure mode.
Business Problems
Business problems involve value, customers, operations, finance, people and strategy. Revenue decline, for example, can arise from fewer customers, lower frequency, lower price, mix changes or measurement. Decomposing the outcome prevents generic solutions such as “increase marketing” from being applied before the source of change is known.
Operational Problems
Operational problems affect flow, quality, reliability or cost in recurring processes. Process maps and time-series data can reveal where delay or defects enter. Because operations repeat, small improvements can compound substantially. The danger is local optimisation: reducing one team’s workload can increase queues or rework elsewhere.
Social Problems
Social problems involve groups, institutions, incentives and contested values. They cannot be diagnosed like a broken machine because participants adapt and disagree about objectives. Evidence remains essential, but problem definition also requires public reasoning about fairness, rights and distribution. Interventions can shift costs among groups even when aggregate indicators improve.
Public Policy Problems
Policy problems are framed through public objectives such as safety, access, growth or environmental protection. Measurement choices influence what becomes visible. A housing problem framed only as unit supply may overlook location, affordability or quality. Policy design therefore begins with a problem definition that reflects the public outcome, not merely the administrative variable easiest to count.
Educational Problems
An educational problem should be diagnosed at the level of learning mechanism. “Low marks” are an outcome, not a sufficient diagnosis. The cause may involve missing knowledge, weak retrieval, question interpretation, time allocation or anxiety. Different mechanisms require different interventions. More practice helps only when the practice targets the actual gap.
Medical Problems
Medical problems begin with symptoms, signs or abnormal measurements and proceed through differential diagnosis. Similar symptoms can arise from different diseases, while one disease can produce different presentations. Clinical problem-solving integrates base rates, patient history, tests and response to treatment while recognising uncertainty and the cost of missed alternatives.
Legal Problems
Legal problems combine facts with rules, jurisdiction and procedure. The same factual dispute can produce different legal questions depending on the governing law and remedy sought. Good legal problem definition identifies the relevant issue without assuming the conclusion, then connects evidence to elements that must be established.
Optimisation Problems
An optimisation problem seeks the best feasible value of an objective subject to constraints. Scheduling, routing, portfolio allocation and engineering design often take this form. The mathematical optimum is only useful when the objective function represents what actually matters. Optimising the wrong metric can produce an impressively efficient bad outcome.
Constraint-Satisfaction Problems
Constraint-satisfaction problems seek any assignment that satisfies a set of rules. Timetabling is a common example: rooms, teachers and classes must be arranged without conflicts. Some problems ask only for feasibility; others rank feasible solutions. Recognising the difference prevents unnecessary optimisation when any valid solution would suffice.
Decision Problems
In computer science, a decision problem asks for a yes-or-no answer under formal rules. More broadly, decision problems ask which action to choose under uncertainty and competing objectives. Good decision framing separates prediction—what is likely to happen—from preference—how desirable each outcome is.
Search Problems
A search problem requires finding a path, configuration or object satisfying criteria. Route finding, puzzle solving and planning can be represented this way. Search becomes difficult when the number of possible states grows rapidly. Heuristics guide attention toward promising regions without examining every possibility.
Computational Complexity
Some formally clear problems become practically hard because the resources required grow rapidly with input size. Computational complexity studies these limits. A problem can be solvable in principle yet infeasible for realistic scale. This distinction matters because “we have an algorithm” does not automatically mean “we have a usable solution.”
Solvability
Before seeking a solution, ask whether the problem is solvable under current constraints. Some goals conflict with physical laws, available resources or each other. Others are solvable only approximately. Recognising infeasibility early prevents endless optimisation of an impossible target and encourages reformulation of the goal or constraints.
Problem Ownership
A problem without an owner can remain visible yet unresolved. Ownership means responsibility for coordinating diagnosis and action, not necessarily personal blame. The owner needs enough authority or escalation access to influence the relevant system. Assigning responsibility to someone who cannot affect the causes creates accountability without control.
Priority
Not every problem deserves immediate action. Priority depends on consequence, urgency, reversibility, strategic value and effort. Small recurring problems can accumulate greater total cost than dramatic rare ones. Prioritisation should compare problems against a shared set of criteria rather than letting visibility alone determine attention.
Urgency Versus Importance
Urgency concerns time pressure; importance concerns consequence or value. Some problems are urgent but minor, while others are important but slow-moving. Maintenance, capability building and climate adaptation can be deferred precisely because they do not always feel urgent until the accumulated gap becomes expensive. Strong planning protects important work from being crowded out by constant immediate demands.
Five Whys
Repeatedly asking why can move from symptom toward deeper causes. The technique is useful when each answer is supported by evidence. It becomes weak when teams invent a linear story and stop at a preferred explanation. Complex systems often need branching causal analysis rather than exactly five steps or one root cause.
Fishbone Diagrams
A fishbone or cause-and-effect diagram organises possible causes into families such as people, methods, materials, equipment and environment. It helps broaden hypothesis generation before evidence narrows the field. The diagram is not proof. Each branch still requires measurement or investigation to determine whether it actually contributed.
Fault Trees
Fault-tree analysis starts with an unwanted event and works backward through combinations of failures that could produce it. Logical gates show whether failures must occur together or whether any one is sufficient. The method is useful in safety engineering because it reveals shared dependencies and combinations that ordinary lists can miss.
Problem Trees
A problem tree places a central problem between contributing causes and downstream effects. It helps distinguish what produces the problem from what the problem produces. This matters because interventions aimed at an effect may reduce visible harm without changing the central mechanism, while upstream interventions may prevent several effects at once.
Experiments
Experiments test whether changing a factor changes the outcome under controlled conditions. In operational settings, small pilots can serve as practical experiments. The best experiment is not always the largest; it is the smallest safe intervention capable of discriminating among important hypotheses and informing the next decision.
Prototypes
A prototype makes a possible solution concrete enough to test. It can be a sketch, simulation, mock service or partial product. Prototypes reveal misunderstandings that discussion cannot. Their purpose is learning, so teams should avoid polishing early prototypes so much that they become psychologically difficult to discard.
Iteration
Many problems are solved through cycles rather than one analysis. Each intervention changes the system and reveals new information. Iteration works when teams preserve measurements, compare against a baseline and update the problem definition. Repetition without learning is not iteration; it is simply doing the same thing again.
Unintended Consequences
A solution can create a new problem by changing incentives or shifting burdens. A policy that reduces one queue may create another downstream. A security rule can cause users to adopt unsafe workarounds. Anticipating unintended consequences requires mapping how people and connected systems will respond, then monitoring after implementation rather than declaring victory at launch.
Local Versus System Problems
A local problem belongs mainly to one component; a system problem emerges from interactions among components. Replacing one faulty sensor can solve a local failure. Repeated sensor failures across sites may indicate procurement, installation or environmental problems. Patterns across cases are evidence that the problem boundary should expand.
Local and Global Optima
A local optimum improves one part or nearby region of a problem space but may be worse than alternatives farther away. Organisations often optimise departmental metrics while reducing total system performance. Global thinking asks whether a local improvement advances the overall objective rather than simply moving cost, delay or risk elsewhere.
Problem-Solution Fit
A solution can be elegant and still fail because it addresses the wrong problem. Problem-solution fit asks whether the intervention changes the mechanism responsible for the target gap. This is why diagnosis precedes implementation in mature systems. A technically impressive product has little value if the user’s constraint was something else.
Problems and Incentives
Persistent problems can be produced by incentives rather than ignorance. If a metric rewards speed without quality, predictable shortcuts may appear. Training people to “be careful” will not resolve a system that rewards the opposite behaviour. Diagnosis should ask what actions the current rules make rational for participants.
Problems and Culture
Organisational culture affects which problems become visible. If staff are punished for reporting mistakes, data will understate failure until consequences become severe. Psychological safety does not eliminate accountability; it allows weak signals to surface early enough for repair. A system that cannot hear bad news cannot diagnose itself reliably.
Problems and Measurement
Measurement determines whether the gap is real, how large it is and whether it is improving. Measures should align with the desired state. If a customer-service team measures only call duration, it may solve the metric by ending calls quickly while leaving customers’ problems unresolved. Proxy measures need validation against the underlying outcome.
Problems and Time
Some problems are transient disturbances; others are trends. Time-series evidence distinguishes one unusual week from structural decline. The time horizon also changes priorities: a short-term fix can be rational during an emergency and harmful if it becomes permanent. Good problem statements specify when the gap began and over what period success will be judged.
Problems and Scale
What appears at one scale can be caused at another. A student may struggle because of one concept, a curriculum sequence or a broader attendance pattern. A city’s housing shortage may reflect neighbourhood rules or national finance. Moving between scales prevents overpersonalising systemic problems and overgeneralising local ones.
Problems and Artificial Intelligence
AI can help summarise evidence, generate hypotheses, search large spaces and simulate alternatives. It can also confidently solve the wrong problem if the prompt embeds a false assumption. Human oversight is especially important in framing, because defining the objective, constraints and acceptable trade-offs often requires values and contextual knowledge not contained in the model.
AI as a Problem Solver
An AI system solves a represented problem, not reality in the abstract. Its objective function, training data and tools define what it can optimise. If the representation omits an important stakeholder or consequence, high performance can still create harm. Evaluating AI therefore requires inspecting the problem formulation as carefully as model accuracy.
Problems in Education and Learning
Learning improves when students learn to identify what kind of problem they face. Is the obstacle missing knowledge, misunderstanding, retrieval failure, method selection or execution? This diagnostic habit prevents indiscriminate practice. The same wrong answer can require different repair depending on which stage failed.
Problem-Solving as Transfer
Real problem-solving requires transfer: using knowledge when surface features differ from familiar examples. Students who memorise one solution pattern can succeed on near copies and fail on structurally identical unfamiliar problems. Teaching should therefore vary contexts and ask learners to explain why a method applies, not merely recognise a template.
When Not to Solve the Problem
Some problems disappear when the goal changes, the process is removed or the activity is no longer valuable. Before optimising a difficult task, ask whether it needs to exist. Eliminating unnecessary work can outperform automating it. Problem-solving should include the possibility that the best solution is to stop producing the problem.
Common Misconceptions About Problems
- The visible symptom is not automatically the underlying problem.
- A problem does not always have one root cause.
- More data do not help if they do not distinguish explanations.
- A solution chosen before diagnosis can narrow thinking prematurely.
- A local improvement can worsen the total system.
- Complex problems may need management and adaptation rather than final resolution.
- Urgent problems are not always the most important.
- An elegant model does not guarantee that the problem was framed correctly.
A Practical Problem Checklist
State the current condition and desired condition. Quantify the gap where possible. Identify who is affected and why it matters. Separate symptoms from hypothesised causes. Map constraints, dependencies and time horizon. Generate several plausible explanations and choose evidence that discriminates among them. Test reversible interventions, measure results and check whether improvement persists without creating a larger problem elsewhere.
How to Solve Problems Better
Begin by resisting the urge to propose solutions. Verify the problem, define success and inspect the system. Ask what changed, where the gap appears, who experiences it and what differs between good and bad cases. Build hypotheses, test the cheapest informative ones first and preserve reversibility. Once an intervention works, standardise the useful change, continue monitoring and be prepared to reopen the diagnosis if conditions shift.
Frequently Asked Questions About Problems
What is a problem in simple terms?
A problem is a gap between what is happening and what needs to happen when the path to close that gap is not immediate or obvious.
What is the difference between a problem and a symptom?
A symptom is observable evidence of difficulty; the problem is the underlying gap and may be produced by several causes.
What is problem framing?
Problem framing is the choice of how to define the goal, boundary, variables and stakeholders before solving. Different frames can open different solution spaces.
Can a problem have more than one solution?
Yes. Many real problems have several feasible solutions with different trade-offs in cost, speed, risk and value.
Can a problem be unsolvable?
Yes. Some goals are infeasible under current constraints, some problems are undecidable in formal systems and some complex conditions can only be managed rather than permanently eliminated.
Authoritative Starting Points
Problem-solving draws on mathematics, operations research, systems engineering, cognitive psychology, design, quality improvement and decision science. Engineering offers fault analysis and requirements methods; mathematics formalises optimisation and feasibility; psychology studies representation and transfer; systems thinking examines feedback and unintended effects. Across disciplines, the recurring lesson is the same: the quality of a solution depends heavily on the quality of the problem definition.
What Is a Problem? The Complete Idea
A problem is not merely something bad. It is a structured gap between a present condition and an objective, shaped by obstacles, constraints and uncertainty. To understand a problem, separate evidence from explanation, symptoms from causes and local effects from system behaviour. Then identify which parts are known, which are uncertain and which can be changed.
The deepest problem-solving skill is diagnosis before intervention. Define the goal, inspect reality, frame the boundary, generate alternatives, test mechanisms and measure consequences. A good solution does more than make the visible symptom disappear. It reduces the underlying gap without creating a worse one somewhere else, and it leaves enough monitoring in place to show whether the problem is actually solved.