10 Problem Solving Techniques That Work

The best problem solving techniques don’t begin with an answer. They begin with a diagnosis of the problem’s shape. A recurring publishing failure calls for a different method from a strategic decision, a creative challenge, or a complex system with several contributing causes.

That distinction matters because problem solving is broader than individual reasoning. The OECD’s PISA 2015 assessment included collaborative problem solving across 51 education systems, including 32 of 35 OECD member systems, reflecting a shift toward evaluating how people analyze, communicate, coordinate, and adapt together. Earlier PISA results also found that only 11% of 15-year-old students across OECD countries were top performers in individual problem solving, according to the OECD’s overview of student problem-solving skills. The lesson is practical: strong outcomes depend on choosing a method and applying it deliberately.

This guide organizes 10 problem solving techniques by the kind of problem they address. For each one, you’ll find its purpose, process, best use case, strengths, limitations, a realistic example, and a quick template. The same framework can support decisions for a publication such as maxijournal.com across editorial planning, audience engagement, technology, contributor relationships, and operations. For additional context, compare this approach with how to apply RCA and Design Thinking.

1. Root Cause Analysis and the 5 Whys

A useful starting point for a recurring failure is the 5 Whys. The method asks why a problem happened, then asks why again about each answer until the team reaches a cause it can address rather than another symptom.

Suppose an article receives little organic traffic. “The article is unpopular” describes an outcome, not a cause. Asking why may reveal weak search intent alignment, an unclear title, poor internal links, or missing technical information. The method helps an editorial team separate content quality from discoverability instead of rewriting a strong article without understanding what failed.

How to use it

Write the problem as a specific observation, not a judgment. Then record every answer in sequence and test each one against available evidence. If the answers become circular, stop and review the original problem statement. The root cause may be a process gap rather than a single individual’s mistake.

Practical rule: Stop asking “why” when the answer points to a controllable process, decision, or condition that can be tested.

The technique works best when cause and effect are fairly direct. It’s fast, inexpensive, and easy to explain, but it can oversimplify problems with several interacting causes. Don’t force one root cause onto a system that clearly needs a broader analysis.

Example: A magazine sees contributors leaving. The first answer is dissatisfaction with the platform. Further questioning may identify unclear payment schedules, inconsistent editorial feedback, and a lack of audience support. The team can then test which condition appears most frequently in contributor interviews and records.

Quick template

• Problem: What failed, and where?
• Why one: What directly caused it?
• Why two: Why did that condition exist?
• Why three onward: What process or assumption sustained it?
• Action: What will you change and how will you verify it?

2. Fishbone Diagram

The Fishbone, or Ishikawa diagram, is better than the 5 Whys when several causes may be operating at once. Instead of following one chain, the team draws a central problem and branches possible causes into categories such as people, process, materials, environment, and methods.

A media team diagnosing declining engagement might place search visibility, distribution, article relevance, publishing timing, page design, contributor workflow, and audience expectations on separate branches. The visual structure prevents the conversation from collapsing around the first plausible explanation.

Build the diagram before prioritizing

Begin with a precise outcome, such as “readers leave before reaching the article’s main argument.” Invite people from editorial, technology, audience development, and operations to propose causes. Categorize those causes, then add sub-causes by asking what created each condition.

The cause and effect maps used for equipment analysis illustrate the same underlying discipline, mapping possible contributors before deciding which ones deserve investigation.

Useful categories include:

• People: Skills, ownership, communication, or staffing.
• Process: Briefing, review, publishing, payment, or support steps.
• Materials: Source quality, assets, data, or content inputs.
• Environment: Competition, timing, audience context, or platform changes.
• Methods: SEO practice, editorial standards, testing, and measurement.

The strength of a Fishbone diagram is breadth. Its weakness is that a crowded diagram can become a catalogue of guesses. After mapping, rank causes by evidence, likely impact, and ease of testing. The diagram generates hypotheses, not proof.

Example: A technology publication investigates repeated browser troubleshooting complaints. The team maps unclear instructions, outdated screenshots, browser differences, missing service-status checks, and device-clock errors. It then tests each cause against support messages and article revisions.

Quick template: Put the measurable problem at the head, draw five or more cause branches, add sub-causes, mark assumptions, assign evidence checks, and select the causes worth testing first.

3. SWOT Analysis

SWOT analysis turns a strategic question into a set of choices. It separates internal strengths and weaknesses from external opportunities and threats, helping teams assess fit before committing resources.

For a digital publication, strengths may include trusted contributors, broad subject coverage, or a flexible publishing model. Weaknesses might involve inconsistent search optimization, limited technical capacity, or unclear audience positioning. Opportunities can include underserved topics and new formats. Threats may come from platform dependence, stronger competitors, or changing reader habits.

Turn four boxes into decisions

A useful SWOT entry needs more than a label such as “strong brand” or “high competition.” Connect each observation to evidence, an implication, and an action. Assign an improvement to a meaningful weakness, define an experiment for an opportunity, and specify how the team will monitor or reduce a threat.

For a worked example, see this Ivory Mind SWOT analysis guide. Use decision-making frameworks for structured choices when the results must support a documented choice rather than remain a descriptive list.

A SWOT analysis is useful only when each observation changes what the team will do next.

The method fits strategy workshops, partnership reviews, editorial positioning, and product planning. Its trade-off is scope. SWOT does not establish causality, forecast outcomes, or resolve operational details. A threat still requires prioritization by immediacy, probability, and potential impact.

Example: A publication is considering a technology newsletter. Existing technology coverage and contributor access are strengths. Limited newsletter production experience is a weakness. An opportunity is to package practical troubleshooting content for a defined audience, while established specialist newsletters represent a threat. The decision should rest on a small, testable launch plan, such as a defined audience, content scope, and review point.

Quick template

• Strengths: What internal assets can we use now?
• Weaknesses: What internal limitations could block progress?
• Opportunities: What external opening fits our capabilities?
• Threats: What external condition could undermine the plan?
• Decision: Which combination deserves action first?

4. Six Thinking Hats

Six Thinking Hats works best when a decision contains several kinds of disagreement. It gives facts, reactions, risks, benefits, ideas, and process management separate turns, so the team can examine one issue without treating every objection as a personal contest.

Use the hats as defined thinking modes:

• White hat: Establish verified facts, gaps, and evidence needed.
• Red hat: Surface emotions, instincts, and likely reactions.
• Black hat: Test weaknesses, risks, constraints, and failure points.
• Yellow hat: Identify benefits, value, and reasons the option could work.
• Green hat: Generate alternatives, variations, and safer approaches.
• Blue hat: Set the sequence, summarize findings, and assign the next action.

The method suits decisions that need balanced evaluation rather than root-cause diagnosis. It can support editorial choices, technology planning, and business reviews. Its trade-off is facilitation: without clear time limits and a moderator, participants may slip back into advocacy or criticism before the relevant round is complete.

Example: An editor reviewing a controversial story can use the white hat to separate verified claims from uncertainty. The red hat captures likely reader and contributor reactions, while the black hat tests legal, reputational, and editorial risks. The yellow hat assesses public value, and the green hat proposes safer angles or formats. The blue hat converts those observations into a recommendation.

For a publishing platform considering a contributor dashboard, the same sequence might document workflow pain points, privacy and maintenance risks, alternative onboarding features, and unresolved evidence. Technology teams can use it to compare implementation options; business teams can use it to test value and exposure.

A practical session follows five rules:

1. Name the hat before each round.
2. Keep evidence, reactions, risks, and ideas in separate notes.
3. Protect idea generation from early criticism.
4. Record questions that require verification.
5. Finish with a recommendation, owner, and review condition.

This structure supports deliberate ways to improve critical thinking skills by making the team’s reasoning visible. Use a compact template: define the decision, run each mode, record its distinct contributions, identify missing evidence, then assign one next step.

5. Design Thinking

A problem can be technically well described and still solve the wrong user need. Design Thinking addresses that risk by beginning with empathy, then moving through definition, ideation, prototyping, and testing.

For an editorial product, the user may be a reader who can’t find related coverage, a contributor who struggles with submission requirements, or a subscriber who doesn’t understand the publication’s value. Interviews, observation, support conversations, and usability tests reveal the gap more reliably than internal assumptions.

Prototype before you build

Design Thinking is especially effective when the problem is ambiguous and the solution isn’t known. A rough newsletter mockup, revised article navigation, contributor form, or sample content package can expose flaws before the team commits substantial development or editorial effort.

The trade-off is time and ambiguity. Teams may gather rich feedback without converging on a decision, or ask users what they want instead of observing what they do. Keep the prototype narrow and define what evidence would justify iteration, revision, or abandonment.

Start with a user statement such as “Readers can’t move from one technology troubleshooting article to the next useful step.” Define the need, generate alternatives, prototype the navigation, and test it with real readers.

The cheapest version of a solution often teaches more than the most polished version.

A short visual introduction to the method can help teams understand its iterative character before they run a workshop.

Quick template: Observe users, define a specific need, create several options, build the simplest credible prototype, test it, record what users did, and revise the problem statement if the evidence contradicts it.

6. Brainstorming

Brainstorming earns its place when the problem is clear but the answer space is narrow. Its job is to expand options before the team spends time judging them.

Start with a prompt specific enough to guide useful contributions. “How might we help readers diagnose browser problems?” gives an editorial and technology team a workable target. “How do we improve the site?” invites vague ideas and produces little direction.

For an editorial project, participants might propose article formats, contributor types, distribution channels, recurring series, and audience questions. A technology team could generate troubleshooting formats, diagnostic tools, explanatory visuals, and support workflows. A business group might explore decision guides, interviews, worksheets, and case-based scenarios.

Design the session around separation

The main risk is early criticism. One person suggests an approach, another rejects it, and the group settles on a familiar option before alternatives develop. Set a rule that generation and evaluation happen in different stages. Capture every contribution, then cluster related ideas and assess them later.

Use a narrow timebox, silent writing before discussion, and a mix of editorial, technical, user, and delivery perspectives. Silent writing limits the influence of the loudest participant, while discussion helps people combine partial ideas. Remote teams can use a shared document, but the facilitator still needs to remove duplicates and clarify vague proposals.

Evaluate the resulting set against four practical filters:

• Audience value: Does it address a real reader or customer need?
• Feasibility: Can the team produce and support it?
• Risk: What could fail, and how costly would that be?
• Learning potential: Can a small test reveal whether it works?

A long list is not progress by itself. Brainstorming cannot confirm demand, technical feasibility, or business impact. Select a small group of ideas for a limited editorial run, prototype, or internal test, and record why the others were deferred.

Repeatable template: Define the challenge, generate independently, combine and cluster ideas, apply explicit criteria, choose test candidates, and document the decision.

7. SCAMPER Technique

SCAMPER works best when a team needs to improve an existing product, process, or piece of content. Its seven prompts, Substitute, Combine, Adapt, Modify, Put to another use, Eliminate, and Reverse, turn a vague request for fresh ideas into specific transformation tasks.

Start with the thing you already have. For an editorial team, that might be an article series, newsletter, review format, or contributor workflow. For a technology team, it could be a feature, onboarding flow, or support process. A business team might examine a sales package, customer report, or internal approval routine.

Apply the prompts to the right object

Take one prompt at a time and record the changes before judging feasibility:

• Substitute: Which component could be replaced, such as text with audio or a dashboard with a visual explainer?
• Combine: Which useful elements could work together, such as a reported story and a practical checklist?
• Adapt: What can another field contribute, such as turning a study-skills concept into a workplace learning guide?
• Modify: What should become clearer, smaller, faster, or richer?
• Put to another use: Who else could use the research, feature, or process?
• Eliminate: Which step adds effort without adding value?
• Reverse: What changes if the sequence or a basic assumption is reversed?

SCAMPER creates momentum because the team has a starting point. It also has a clear limitation: variations can look attractive while leaving the underlying audience need unchanged. Define that need first, then test whether the proposed change improves a measurable user outcome.

Example: A gaming publication could turn a standard review into a guided decision format by combining critique, gameplay context, and audience questions. The team can test whether the revised format helps readers choose a game more effectively.

Quick template: Name the existing product, run each prompt, capture ideas without feasibility judgments, group duplicates, choose the strongest transformation, and test it against a defined user need.

8. Mind Mapping

Mind mapping helps when the problem is not a shortage of ideas but a confusing mass of relationships. Place one central concept on the page, then branch into themes, subtopics, stakeholders, questions, and dependencies.

An editorial team planning a technology series might begin with a central topic such as device reliability. Branches could cover hardware, software, security, user behavior, troubleshooting, experts, and reader questions. Further branches reveal related articles, missing explanations, and internal-link opportunities.

Keep the map usable

A mind map is valuable because it makes relationships visible. It can reveal that one article serves several audience needs, that two departments own related work, or that a proposed story depends on evidence the team doesn’t have. It’s also useful for campaign planning, book structure, complex interviews, and cross-category publishing.

The risk is visual noise. Too many words, decorative branches, and unranked ideas turn the map into a poster rather than a decision aid. Keep branch labels short, distinguish categories with color or shape, and mark priority, uncertainty, and ownership.

Use data visualization techniques when the project needs a clearer way to communicate relationships beyond the working team.

Example: A marketing team maps a health campaign from audience concern to search questions, article formats, expert review, distribution, and measurement. The map exposes a missing review step before the team starts producing content.

Quick template: Define the central problem, add major branches, expand each branch with short labels, mark dependencies, identify gaps, and convert selected branches into tasks or hypotheses.

9. Reverse Brainstorming

Reverse brainstorming asks a deliberately uncomfortable question: How could we make this problem worse? The negative framing helps teams notice risks they overlook when everyone is trying to sound constructive.

A publication trying to improve reader retention might ask how to lose readers quickly. Answers could include publishing repetitive articles, hiding the value proposition, making navigation confusing, ignoring corrections, and sending irrelevant updates. Each negative scenario becomes a preventive action or test.

Turn failure into prevention

The method works because people often identify failure mechanisms more easily than ideal solutions. It’s particularly useful before a launch, editorial change, migration, contributor-policy update, or technology release.

The danger is performative pessimism. Teams may generate jokes or obvious disasters without identifying realistic failure points. Anchor the exercise in a specific desired outcome and ask participants to explain how each negative scenario could occur in normal operations.

Example: A platform asks, “How could we alienate contributors?” The team identifies unclear payment terms, slow editorial responses, inconsistent acceptance criteria, and poor attribution. It then converts those concerns into published policies, response standards, and a contributor feedback process.

Quick template: State the desired outcome, invert it into failure, generate specific ways to cause that failure, cluster the scenarios, rank them by plausibility and impact, and assign preventive controls.

Use the negative question before launch, not after the audience discovers the failure for you.

This method is fast and accessible, but it doesn’t replace testing. It identifies risks worth investigating. Teams still need evidence, owners, and review dates.

10. Lateral Thinking

Lateral thinking challenges the assumptions that keep a team inside the same solution space. Instead of moving step by step from the current state, participants change perspective, combine distant ideas, or ask what would happen if a basic constraint were removed.

A technology publication might treat troubleshooting as a guided diagnostic conversation rather than a static article. A sports editor might explain esports through the structures of traditional sports. A business writer might present a strategy topic through the experience of a frontline worker rather than an executive summary.

Create useful distance

Lateral thinking needs deliberate inputs. Read outside your industry, invite people with different expertise, use random words or images to create associations, and ask “What if?” questions that challenge the brief. The goal isn’t novelty for its own sake. A surprising angle must still help a defined audience understand, decide, or act.

The strength of the method is differentiation. It can open new editorial angles, product concepts, and audience segments. Its weakness is evaluation. Unconventional ideas can consume time without improving the outcome if the team doesn’t return to user need, evidence, and feasibility.

Example: A publication covering music might connect independent bands with business, technology, and tourism themes, creating stories that serve readers interested in both cultural discovery and practical context. The editorial opportunity comes from crossing categories without losing clarity.

Quick template: State the default assumption, challenge it with a “what if” question, import a perspective from another field, generate several alternative frames, test each against audience value, and choose the direction with a credible next experiment.

Top 10 Problem-Solving Techniques Comparison

Method	Implementation complexity	Resource requirements	Expected outcomes	Ideal use cases	Key advantages
Root Cause Analysis (5 Whys)	Low, simple linear questioning	Minimal, team time, documentation	Single primary root cause; actionable fixes	Quick diagnostics (performance drops, churn)	Fast, low-cost, encourages deep cause tracing
Fishbone Diagram (Ishikawa)	Medium, structured mapping	Moderate, workshop, domain expertise, visual tools	Comprehensive map of contributing factors	Complex, multi-causal problems (engagement, churn)	Systematic, prevents overlooked causes, team alignment
SWOT Analysis	Low–Medium, quadrant matrix	Moderate, internal/external data, stakeholder input	Strategic overview of strengths/weaknesses/opportunities/threats	Strategy planning, competitive positioning, editorial strategy	Simple strategic framing; easy to communicate decisions
Six Thinking Hats	Medium, disciplined, facilitated process	Moderate, facilitator, training, time allocation	Balanced evaluation across six perspectives	Content decisions, contentious editorial choices, feature reviews	Reduces conflict, ensures diverse viewpoints, improves decisions
Design Thinking	High, iterative, research-driven	High, user research, prototyping, cross-functional teams	User-centered, tested and refined solutions	UX/features, audience engagement, product innovation	Generates creative, low-risk solutions via prototyping and empathy
Brainstorming	Low, open ideation session	Low–Moderate, facilitator, time, optional tools	Large quantity of ideas that need filtering	Content ideation, editorial calendars, topic discovery	Rapid idea generation; inclusive and energizes teams
SCAMPER Technique	Low–Medium, checklist-driven	Low, facilitator/time, structured prompts	Practical variations and incremental innovations	Reimagining formats, feature tweaks, fast ideation	Structured creativity; yields implementable, low-risk ideas
Mind Mapping	Low–Medium, visual organization	Low–Moderate, whiteboard or digital mapping tools	Visualized idea hierarchy and relationships	Project planning, content architecture, story mapping	Reveals connections; flexible and easy to update
Reverse Brainstorming	Medium, inverted questioning	Moderate, facilitation, time to convert negatives to solutions	Identifies vulnerabilities and preventive actions	Risk assessment, contingency planning, breaking assumptions	Uncovers hidden risks; counteracts groupthink
Lateral Thinking	Medium–High, cultural and cognitive shift	Low–Moderate, training, diverse stimuli/input	Breakthrough, unconventional ideas (may need vetting)	Disruptive content strategies, finding new audience angles	Produces novel, disruptive solutions; challenges assumptions

Match the Technique to the Problem

The right technique depends on what you know, what you don’t know, and what kind of decision the team must make. Start with the problem type rather than the method you happen to use most often.

• Use 5 Whys for a simple, recurring cause-and-effect failure where the chain can be traced and tested.
• Use a Fishbone diagram when several people, processes, materials, methods, or environmental conditions may contribute.
• Use SWOT when the question concerns strategic position, internal capability, and external conditions.
• Use Six Thinking Hats when a group needs balanced evaluation without mixing facts, emotions, risks, and creativity into one argument.
• Use Design Thinking when the user need is unclear or the team risks building an internally attractive solution that users won’t adopt.
• Use Brainstorming when you need a broad set of possible ideas before narrowing the field.
• Use SCAMPER when an existing article, product, process, or feature needs deliberate variation.
• Use Mind Mapping when complexity comes from relationships, categories, dependencies, or a large information space.
• Use Reverse Brainstorming when the priority is discovering failure modes before they become expensive.
• Use Lateral Thinking when conventional approaches produce predictable results and the team needs a different frame.

Don’t treat these methods as interchangeable checklists. Benchmarking research shows that experiment design can change how methods rank, especially when test sets, tuning parameters, computational environments, and evaluation measures differ, as discussed in this technical benchmarking guidance. The same principle applies to workplace problem solving: the framing, evidence, participants, and test conditions shape the result.

A practical sequence is simple. Define the problem, including the desired state and the evidence that shows a gap. Choose one method that fits the problem’s shape. Document the output, including assumptions, unresolved questions, and ownership. Test the most promising action on a scale that can produce useful evidence. Then review what changed, what didn’t, and whether the original problem statement still holds.

Feasibility deserves special attention. Recent formal-math benchmarking found that advanced proof-search systems solved at most 23.77% of FormalMath500, 27.47% of MiniF2F-Solving, and 0.31% of PutnamBench-Solving, according to the benchmark study on formal mathematical reasoning. Those results are a reminder that generating an answer isn’t the same as proving that an answer works. In editorial, technology, and business settings, a promising idea still needs constraints, validation, and a clear review loop.

For maxijournal.com, that could mean diagnosing a publishing issue with 5 Whys, mapping a multi-team audience problem with Fishbone, generating new formats with Brainstorming or SCAMPER, and testing a reader-centered change through a small Design Thinking prototype. The method matters, but the learning loop matters more.

---

Maxi Journal publishes independent writing across science, technology, health, sports, business, arts, tourism, fashion, pets, entertainment, education, games, music, and movies. Visit maxijournal.com to explore practical articles and contribute ideas that turn clearer thinking into useful publishing work.