Problem-Solving Skills: Definition + 50 Examples

1. What Are Problem-Solving Skills?

Problem-solving skills are the behaviors involved in moving from "something is not working as expected" to a response that is appropriate for the situation. That response is not always a fix. Depending on the problem, it may be containment while more is learned, a recommendation to someone who holds the decision, a formal escalation, a process change, or a deliberate decision to monitor and do nothing for now.

In practice the work tends to run through a recognizable sequence, even when nobody names it:

• • Noticing that something is not as expected
• • Describing the problem in observable terms
• • Gathering the information that is relevant and available
• • Separating what is known from what is assumed
• • Investigating what may be causing it
• • Identifying constraints and who has authority
• • Generating more than one possible response
• • Comparing options, trade-offs and risks
• • Acting, recommending or escalating
• • Checking what actually happened afterwards

How much of that sequence belongs to you varies by role. A support agent may own recognition, definition and escalation while a specialist team owns the investigation. A maintenance technician may own nearly all of it for a class of equipment and none of it for anything electrical. An analyst may spend most of their effort on definition and evidence and never make the decision at all. All of these are problem solving; the distribution differs.

It is also worth being precise about what strengthening these skills does and does not do. Better problem solving does not guarantee a promotion, a higher salary, a better review or a lighter workload, and nothing on this page should be read as promising improved business performance. What it can reasonably support is more accurate problem statements, fewer responses aimed at the wrong thing and clearer conversations with the people who hold the decisions. Problem solving sits alongside a broader set of workplace abilities — see our guides to soft skills and transferable skills for how it fits into that wider picture.

2. Problem-Solving Skills Definition

A few distinctions make the definition more usable. A technique or framework is not a skill: process mapping and a question sequence organize thinking, and neither supplies evidence nor guarantees a correct conclusion. Speed is not evidence of skill either — a fast answer may be the product of experience or of a guess, and from the outside the two look similar until the issue returns. And experience with similar problems is not automatic proof of ability; it helps, and it can also anchor you to an explanation that fitted the last situation and does not fit this one.

3. 50+ Problem-Solving Skills Examples

73 distinct skills, grouped into ten areas. They are deliberately separate abilities rather than synonyms for each other — defining a problem, checking an assumption and evaluating an outcome are different activities that people are good at to different degrees. Few roles need all of them, and most people are noticeably stronger in some groups than others.

4. Why Problem-Solving Skills Matter at Work

Almost every role includes situations where the expected outcome does not occur. What follows is a list of things these skills can help with, phrased carefully: these are plausible benefits, not measured outcomes, and none of them is guaranteed by better personal practice in an organization that will not act on what is found.

There is a limit worth naming. Some problems are structural: understaffing, conflicting targets, unclear ownership, tooling that does not support the work. Individual problem solving can describe those accurately and route them to the people who can act, which is genuinely useful. It cannot resolve them from below, and treating a resourcing problem as a personal one tends to produce effort rather than change. Where a problem sits with how work is planned and coordinated, our guide to management skills covers that side of it.

5. Types of Problem-Solving Skills

Problem solving is often split into types. These labels are descriptive conveniences rather than a scientific taxonomy, and most real situations involve several at once.

The useful thing about the list is not the categories themselves but noticing which ones your role actually calls for. A role dominated by reactive problem solving under time pressure rewards containment and escalation judgment. A role with more analysis time rewards definition, evidence and comparison. Applying the habits of one to the other tends to go badly in both directions.

6. Recognizing and Defining a Problem

Recognition comes first, and it is less automatic than it sounds. Problems announce themselves through a gap between expected and actual results, through recurring friction that everyone has stopped mentioning, through requirements that are quietly not being met, through unusual patterns in routine work, through reports from colleagues or customers, and through process signals such as growing queues, rework or repeated questions about the same step.

Two cautions. Not every deviation is a problem — processes vary, and reacting to normal variation generates work without improving anything. And noticing patterns in how work is going is not a licence to monitor individuals; the signals worth watching are about the process, not about tracking people.

Definition is where most of the value is, and where most problem solving goes wrong. A good problem statement describes what is happening, what was expected instead, where and when it occurs, how widespread it is, who or what it affects, what is known and what is not yet known. It deliberately stops short of explaining the cause, because an explanation embedded in the statement quietly closes off the investigation.

These examples are illustrative. Note what the stronger versions have in common: they are checkable, they are bounded in time and scope, and they do not attribute motive to anyone. Describing a person's intent — careless, lazy, resistant — is an interpretation presented as an observation, and it reliably sends the investigation toward people rather than toward how the work is set up.

Problem definition

What is happening (observable):
What was expected instead:
Where it occurs:
When it started / how often:
Scope (how many cases, who is affected):
Impact:
Known facts:
Unknown / not yet checked:
My current assumption (flagged as an assumption):

7. Separating Symptoms From Causes

A symptom is an observable effect or indication that something is wrong. A cause is a factor contributing to why it occurred. The two get conflated constantly, usually because the symptom is visible and the cause is not, and acting on the visible thing feels like progress.

Three things are worth holding onto. One issue may have several causes acting together. Those causes may interact, so removing one changes how much the others matter. And some causes stay uncertain — you may end up with a well-supported hypothesis rather than a confirmed explanation, and saying so is more useful than manufacturing certainty. The phrase "root cause" is convenient, but it is not true that every problem has exactly one.

8. Gathering Information and Asking Better Questions

Useful sources include records and logs, timelines of events, direct observation of the work as it actually happens, input from the people closest to it, system or process data you are authorized to access, and existing documentation. The test for each is not whether it is available but whether it could change your conclusion. Collecting everything accessible is a common way to spend a week and learn nothing.

Authorization matters as much as relevance. Personal data, medical information, financial records, HR files and security logs are usually restricted for good reasons. If answering a question requires access you do not have, the correct move is to involve someone who does, not to find a way around the restriction.

Questions do the narrowing. The list below is a starting point, and the tone matters: these are questions asked of a situation, not of a suspect. Asking colleagues what they see works when it reads as information gathering and stops working entirely when it reads as an investigation into them. Our guide to communication skills covers questioning and clarifying in more depth.

Problem investigation questions

1. What exactly is happening, in observable terms?
2. What was expected instead?
3. When did it start, and is it constant or intermittent?
4. Where does it occur, and where does it not occur?
5. What changed around the time it appeared?
6. What evidence do we already have?
7. What don't we know yet?
8. Who has relevant expertise or authority here?
9. What constraints apply (policy, safety, legal, resources, access)?
10. What happens if no action is taken for now?

9. Checking Assumptions and Identifying Constraints

Every investigation runs on assumptions. The problem is not that they exist but that they are usually invisible, so they never get checked. The ones specific to problem solving are worth listing explicitly, along with how you might test each.

Constraints are the other half of the picture, and identifying them early prevents work on options that were never available. The ones that matter most often are authority (what you can decide versus recommend), time, resources, policy, technical limits, legal and regulatory boundaries, safety requirements and dependencies on other teams.

On legal and regulatory constraints specifically: nothing here is legal advice, and where a problem touches employment law, contracts, regulated processes, data protection or safety obligations, appropriate specialist input may be needed. Recognizing that boundary is itself a problem-solving skill.

10. Finding Possible Causes

Cause investigation is mostly comparison. Where does the issue occur and where does it not? What is different between those cases? A timeline shows what happened before the issue appeared. Process mapping shows where work waits or branches. Dependency analysis shows what the step relies on. Change analysis asks what was introduced or removed recently — new tooling, new staff, higher volume, a different supplier, a procedure update. Recurring patterns by shift, location, product or time of month narrow the field further. Where a hypothesis can be tested safely and with permission, testing beats arguing about it.

Named techniques can help structure this. The 5 Whys prompt pushes past a first explanation by asking why repeatedly; a cause-and-effect diagram groups candidate factors so fewer get overlooked. Both are useful and both have the same limitation, which is worth stating directly: a technique can generate hypotheses, but it does not guarantee that it has identified the true cause. A chain of five answers produced in a meeting is a chain of five opinions unless each link is supported by something. The full comparison of techniques and their limits is in section 25.

Some causes require expertise you do not have. Equipment faults, clinical questions, security incidents, structural issues and regulated processes are areas where an informed guess is worse than no answer, because it can be acted on. Bringing in qualified input is part of the investigation, not an interruption to it.

11. Generating Possible Solutions

Once you have a defensible view of what is happening and what may be behind it, the task is to produce responses that are genuinely different from one another. Options usually fall into recognizable families:

A brief structured brainstorm helps here, particularly with colleagues who see the process from a different position. But more options are not automatically better options. Five variations on the same idea is one option written five times, and a long list can delay action while the issue continues. Two or three meaningfully different responses, one of which is usually "do less than proposed", is often the useful output.

12. Comparing Solutions, Trade-Offs and Risk

Comparison is where preferences hide. Most people arrive with a favored option and then evaluate the others against it. The defense against that is to write down the same dimensions for each: expected benefit, main downside, risk, resources and time required, reversibility, dependencies, stakeholder impact, how uncertain the assessment is, and what authority the option would need.

Option comparison

Option:
What it would change:
Expected benefit:
Main downside:
Risk / who could be affected:
Resources and time required:
Reversible? (yes / partly / no):
Dependencies:
Authority or approval required:
Level of uncertainty in this assessment:

Qualitative comparison is usually more honest than scoring. If you do use a decision matrix, treat the weights and scores as your own judgments made explicit, not as measurements — numbers you assigned yourself can make a preference look like an analysis. Where uncertainty is high, reversibility deserves more weight than it usually gets: an option you can undo lets you learn from being wrong cheaply.

Risk thinking at this stage can stay general and qualitative: how severe would the downside be, how plausible is it, can it be reversed, who or what would be affected, and what happens downstream. That is a reasonable level of care for everyday workplace problems. It is not a substitute for specialist risk assessment — clinical, safety engineering, financial control, legal and security risks are assessed by qualified people using methods this guide does not cover, and high-stakes problems should be routed to them.

13. Knowing When to Escalate

Escalation has an undeserved reputation. It is often treated as an admission that you could not handle something, which is why issues sit in the wrong place until they get worse. In reality, correctly routing a problem to someone with the authority, expertise or mandate to deal with it is frequently the best available problem-solving action.

Escalating well is its own skill. Hand over the problem statement, what you have already checked, what remains unknown, the options you can see and — specifically — what you need from them: a decision, an approval, expertise or ownership. Doing this early enough that a decision can still change something matters more than doing it elegantly. And the old line about bringing solutions rather than problems is worth ignoring: raising a problem you have no authority or expertise to solve is exactly what you should do.

14. Planning Implementation

A chosen response is not a resolved problem. Implementation is part of problem solving, and the parts that get skipped are usually the ones that decide whether anything changes. This does not need to become project management — for most workplace problems a short list is enough.

Where implementation spans several people over time, coordination becomes the dominant problem rather than the diagnosis — that is the territory of management skills, and of time management skills for fitting the work into a week that is already full.

15. Monitoring Results and Evaluating the Outcome

Monitoring means deciding in advance what you expect to see, then looking. Check the same indicator that identified the problem, watch for unintended effects elsewhere, look for recurrence in a slightly different form, take stakeholder feedback where it is relevant, and stay open to new information that changes the picture. Avoid inventing a metric for the sake of having one; if the original problem was described in observable terms, that description tells you what to look at.

Evaluation is the step most often skipped, because completing the action feels like finishing. A completed action is not a solved problem. Working through a short set of questions is usually enough:

• • Has the original issue changed, or only the attention being paid to it?
• • Have the symptoms changed, and in the direction expected?
• • Has the problem recurred, including in a modified form?
• • Have new problems appeared as a result of the change?
• • Did any assumption behind the response turn out to be wrong?
• • Is further action required, and does it belong with the same people?

An honest evaluation sometimes concludes that the response did not work and the explanation was wrong. That is a useful result. Going back to the investigation with better information is far cheaper than defending a fix that is not delivering.

16. Learning From Problems and Preventing Recurrence

Learning from a problem can mean nothing more than a two-line note: what we thought was happening, what the evidence showed, what we did, and what changed. Where it is warranted, it can extend to updating documentation, adding a step to a checklist, adjusting a process, training where a genuine knowledge gap exists, adding a preventive control, or monitoring an indicator for a while.

Proportion is the whole discipline here. Not every problem should produce a new policy, an extra approval or a longer form. Organizations accumulate process this way — each addition reasonable in isolation, the total an obstacle. Before adding a control, it is worth asking whether the issue is likely to recur, what the recurrence would cost, and whether the control would actually have prevented this instance. Sometimes the correct conclusion is that the problem was a one-off and nothing needs to change.

Retrospectives are useful where the culture supports them and hollow where it does not. A review that cannot say "the process made this likely" will produce conclusions about being more careful, which is not a change.

17. Problem-Solving Skills at Work

Fifteen situations across different settings, with the skill each mainly calls on and what a reasonable first move can look like. These are illustrative, and the appropriate response in your workplace depends on role, policy and risk.

18. Problem Solving vs. Critical Thinking

The two overlap and are not the same. Critical thinking is mainly about how information is evaluated: examining assumptions, assessing reasoning, weighing evidence and distinguishing stronger support from weaker support. Problem solving is broader and action-oriented: identify and define a problem, investigate it, generate options, choose or escalate, implement and evaluate.

In practice, critical thinking supports problem solving throughout — most obviously when checking assumptions and weighing evidence about causes. The distinction matters mainly because a well-reasoned analysis that never reaches a response has not solved anything, and a fast response built on unexamined reasoning tends to solve the wrong problem. For a deeper look at evaluating information, checking assumptions, comparing explanations and judging how strongly evidence supports a conclusion, see our guide to critical thinking skills, with 50+ practical examples.

19. Problem Solving vs. Decision Making

Decision making is choosing among options. Problem solving is the wider process that may include defining the problem, investigating it, generating the options in the first place, making or supporting the decision, implementing it and evaluating the result.

Decisions happen constantly without any problem being present — choosing a supplier from three acceptable ones, picking a meeting time, selecting which of two good candidates to hire. And problem solving usually contains at least one decision, sometimes several: what to investigate, whether to act now, which response to recommend, when to stop. The practical implication is that being decisive is not the same as being good at problems. A person who chooses quickly among the options presented to them may never have questioned whether those were the right options.

20. Problem Solving vs. Management Skills

Management skills cover planning and organizing work, delegating, coordinating people, managing resources and workload, monitoring execution and carrying operational responsibility. Problem solving is a specific ability that managers use constantly and that people without any management responsibility also use constantly.

Neither is superior, and neither implies the other: plenty of individual contributors are the strongest problem solvers in an organization, and plenty of competent managers rely on others for diagnosis. For the coordination side, see management skills; for direction, influence and judgment in a wider sense, see leadership skills.

21. How to Identify Your Problem-Solving Skills

Most people underestimate this because they are looking for dramatic examples. Routine problems handled well are better evidence than a crisis handled once. Work through the eight steps below with two or three real situations.

1. 1. Review problems you have encountered. List a handful of real situations where something was not working as expected — routine ones count.
2. 2. Identify what you actually observed. Write down what you saw or measured, separately from what you concluded.
3. 3. Separate the problem from your first explanation. Note whether your initial explanation turned out to be right, partly right or wrong.
4. 4. Identify the information you gathered. Records, timelines, observations, conversations — and what you could not access.
5. 5. Review how you investigated causes. Comparisons, tests, process walkthroughs, specialist input.
6. 6. Identify the options you considered. Including options you rejected and why.
7. 7. Review what action or escalation occurred. Who decided, what was done, and what your specific contribution was.
8. 8. Identify evidence from the result. What changed, what did not, and what you learned or would investigate differently.

Eight illustrative mappings from experience to evidence. These are fictional examples written to show the pattern, not case studies, and they deliberately contain no metrics.

If you are turning this into development goals rather than application material, our guides to a professional development plan and an individual development plan cover how to structure that.

22. Problem-Solving Skills for a Resume

"Excellent problem-solving skills" in a skills list carries almost no information — nearly every applicant writes it, and it can be claimed without evidence. What carries information is a specific line describing a problem you identified, what you investigated and what changed.

On placement: the strongest home is inside work experience bullets, where the context makes the claim credible. A summary line can reference it where problem solving is central to the role. A skills section entry is fine as a keyword, but treat it as a label that your experience section has to earn. Resist the temptation to attach percentages you cannot support — invented figures are easy to probe in an interview.

Resume bullet patterns (adapt with your own real examples)

- Identified [recurring issue] by [what you reviewed or observed], and [what you changed or recommended].
- Investigated [problem] across [records/process/period], traced it to [factor], and [action taken].
- Compared [number] possible responses to [problem] and recommended [option] based on [trade-off].
- Escalated [type of issue] to [appropriate team] after establishing [what you had verified].
- Reviewed [change] after implementation to confirm whether [original issue] had actually changed.

For the wider picture, see our guides to skills for a resume, resume examples and resume summary examples.

23. Problem-Solving Skills in Interviews

Interview questions about problem solving are usually asking how you think, not whether you got a good outcome. A clear structure helps: situation, the problem as you defined it, what you investigated, what you did or recommended, and the result or lesson. The four examples below are fictional and illustrative — use them as a shape, not as content to borrow. General preparation is covered in our guide to how to prepare for a job interview.

Situation: In a scheduling coordinator role, the same weekly report was being submitted late most weeks.

Problem: Rather than "the team is disorganized", I described it as: the report requires data from two teams, and the second set usually arrives after the internal cut-off.

Investigation: I looked at four weeks of submission timestamps and asked both teams when their data becomes available.

Action: I proposed moving the internal cut-off later and the reminder earlier, and raised it with the report owner rather than changing the deadline myself.

Result / lesson: The change was adopted and lateness became occasional rather than routine. The lesson was that the problem was in sequencing, not effort.

Situation: In a customer support role, a small number of customers reported being charged twice, with no obvious pattern.

Problem: I could confirm the reports were real but could not confirm a cause from what I had access to.

Investigation: I documented each case with account type, channel and timing, and checked whether they shared any of those.

Action: I stated clearly what was known and what was not, and passed the documented cases to the billing team, who had the system access I did not.

Result / lesson: The cause was in a payment retry path. The lesson was that naming the limits of what I could verify made the handover faster than speculating would have.

Situation: In a warehouse team, picking errors on one product line had increased.

Problem: My first explanation was that two similar items were stored adjacently.

Investigation: We separated them. Errors continued, which told me the explanation was incomplete.

Action: I went back to the data and found the errors clustered on one shift and one label format, and raised both with the supervisor.

Result / lesson: The label format was changed. The lesson was that a recurrence after a fix is evidence, not a reason to repeat the fix harder.

Situation: In an administrative role, I noticed a shared folder containing documents with personal data that appeared to be visible more widely than intended.

Problem: Potential inappropriate access to personal information.

Investigation: I recorded what I had seen and when, and did not open or move the files further.

Action: I reported it immediately to my manager and the team responsible for data protection, following the internal policy.

Result / lesson: Access was corrected by the responsible team. The lesson was that this category of issue is not one to investigate independently, however straightforward it looks.

Two things interviewers tend to notice. First, whether you can describe the problem separately from your explanation of it — candidates who begin with the cause usually never examined it. Second, whether you can talk about a case where you were wrong. An example where the first response failed and you revised your thinking is often more convincing than a story where everything worked.

24. How to Improve Problem-Solving Skills

Improvement here comes from changing how you handle the problems already in front of you, not from taking on extra responsibilities or unpaid work. The ten practices below are deliberately small. No timeline is attached to them, and no level of mastery is promised — how quickly anyone improves depends on the problems they meet, the feedback available and how much the organization lets findings change anything.

1. 1. Practice defining problems before solving them. For the next few issues you meet, write one observable sentence describing what is happening before you propose anything.
2. 2. Separate facts from assumptions. Split your notes into two columns: what you know and what you are assuming. The second column is usually longer than expected.
3. 3. Ask what information is missing. Before concluding, name the one piece of information that would most change your view — then see whether you can get it.
4. 4. Look for multiple possible causes. Force yourself to write a second and third candidate explanation, even when the first feels obvious.
5. 5. Generate more than one reasonable response. Include at least one option that is cheaper and one that is more reversible than your preferred answer.
6. 6. Compare trade-offs explicitly. Write the downside of your preferred option in one sentence. If you cannot, you have not examined it.
7. 7. Recognize authority and expertise limits. Decide in advance which categories of issue you will escalate rather than deciding under pressure.
8. 8. Review what happened after action. Set a specific date to check the original indicator rather than relying on the absence of complaints.
9. 9. Document useful lessons. Keep a short running note of issues, what you assumed, and what the evidence turned out to be.
10. 10. Practice on increasingly complex problems. Take on harder problems gradually, within your role and with appropriate support — not by quietly absorbing work that belongs elsewhere.

Two of these do most of the work. Writing the problem before the solution changes what you investigate, and checking the result weeks later changes what you learn. The rest are refinements on those.

Problem-solving improvement plan

Skill I want to strengthen:
Why it matters in my current role:
Current evidence of where I am now:

Practice 1 (next 2 weeks):
Practice 2 (next 2 weeks):
Practice 3 (next month):

Where I will get feedback:
What I will record (problem, assumption, evidence, outcome):
Review date:
How I will know whether anything changed:

Problem solving also improves through other people. Colleagues who work a step upstream or downstream hold information you do not, which makes interpersonal skills more relevant to diagnosis than it first appears, and domain knowledge — the hard skills of your field — determines which explanations you are even able to consider.

25. Problem-Solving Techniques and Practice

Techniques are prompts. They help you not skip a step, and they make thinking visible to other people, which is genuinely valuable in a group. What they cannot do is supply evidence, and none of them is universally best. Each entry below pairs what a technique can help with against its limitation.

Two statements worth keeping in view. A technique is not a skill: someone can run a flawless 5 Whys session and still have accepted an unchecked premise at step one. And a framework is not a guaranteed answer: structure improves the odds that relevant factors are considered, and improves nothing about the quality of the information going in.

Choosing between them is a judgment about the problem, not a preference. Repetitive operational issues with good records reward comparison and pattern analysis. Process failures reward mapping and walking the actual work. Novel problems with thin evidence reward hypothesis generation and safe testing. Group problems reward whatever makes reasoning visible to people who see different parts of it. Practising means applying these to the ordinary issues in your own work, not adopting a method because it is widely discussed.

26. How to Demonstrate Problem-Solving Skills

"I am a strong problem solver" is a claim. Evidence is a description of what you noticed, what you checked and what changed — for example: "I identified a recurring handoff issue, traced where work was being delayed, compared possible fixes and helped implement a clearer follow-up process." Twelve types of evidence, with illustrative phrasing:

None of these needs a number attached. Fabricated metrics — a percentage reduction, a cost saving — are the fastest way to turn a credible example into one that collapses under a follow-up question. Where you genuinely have a figure that your employer published or measured, use it; otherwise describe what changed in plain terms.

27. Problem-Solving Skills Worksheet

Sixteen prompts for working through a real situation you have handled or are handling now. There is no score, no result to interpret, no problem-solving rating and no automated evaluation — it is a structure for describing your own thinking clearly enough to use in a development conversation, a review or an interview answer.

Problem-solving worksheet

1. Situation:
2. Expected outcome:
3. What actually happened:
4. Observable problem (one sentence, no explanation):
5. Who or what is affected:
6. Known facts:
7. Unknown / not yet checked:
8. My initial assumptions:
9. Possible causes (list more than one):
10. Constraints (time, resources, policy, authority, safety):
11. Relevant expertise or authority needed:
12. Possible responses (include containment, action, escalation, monitoring):
13. Main trade-offs and risks:
14. Chosen action or escalation:
15. Result and evidence:
16. What I would change or investigate next:

There is no score here, and no result to interpret. It is a structure for describing
a real situation you can use in a review, a development conversation or an interview.

28. Common Problem-Solving Mistakes

Fifteen patterns that recur across roles and industries. Most are reasonable instincts applied at the wrong moment rather than carelessness.

29. Problem-Solving Skills FAQs