19 Problem-Solving Techniques That Actually Work (And When to Use Each One)

Why Most Problem-Solving Frameworks Fail Before You Start

We’ve watched smart people schedule three-hour workshops for problems that needed ten minutes of clear thinking. The issue isn’t a shortage of problem-solving techniques — there are hundreds. The issue is matching the technique to the problem type.

A SharePoint adoption failure needs different thinking than a procurement bottleneck. A political deadlock needs different thinking than a technical bug. Here are 19 techniques we’ve used across energy, financial services, insurance, and government programmes. Each one works best in a specific situation.

Which Techniques Work When You Need Answers Fast?

1. The 5-Minute Rule

Set a timer for 5 minutes. Write every possible solution without filtering. Stop when it rings. Pick the three strongest and test one immediately.

This suits operational problems where speed matters more than elegance. When a client’s invoicing system crashed on month-end, we used this and had a working fix in 20 minutes — instead of the usual two-day committee process.

2. What Would [Expert] Do?

Name someone who has solved this exact problem before. What would they do first? Most problems aren’t unique, so someone has already worked out the shortest path.

When a Microsoft 365 Copilot rollout hit adoption resistance at week three, we asked what the Microsoft FastTrack team would check first. Answer: usage telemetry in the M365 Admin Centre. The data showed 80% of users hadn’t completed the mandatory 20-minute training — a fixable problem, not a product problem.

3. Opposite Thinking

Instead of asking “How do we fix this?” ask “How could we make this catastrophically worse?” Then systematically do the opposite.

A client’s Power BI report accuracy kept degrading. We listed everything guaranteed to corrupt a semantic model: multiple data sources with no refresh schedule, no row-level security, calculated columns built on other calculated columns. They were doing all three.

Which Techniques Work for Complex, Systemic Problems?

4. The 5 Whys (Done Properly)

Ask “why” five times, but each answer must be specific and measurable. Surface-level whys produce surface-level fixes.

Weak version: “Why are reports late?” → “People don’t prioritise them.”

Useful version: “Why are reports late?” → “They’re due Friday, but the source data isn’t available until Thursday at 3 PM, leaving two hours for a process that takes four.” That’s a scheduling problem, not an attitude problem.

5. Force Field Analysis

Draw a vertical line. Forces driving progress on the left, forces blocking it on the right. Strengthen the left side, weaken the right side — in that priority order.

We used this when an AI chatbot project for a financial services client kept stalling at governance review. Three blockers dominated: IT security sign-off, legal review of training data, and procurement approval for the Azure OpenAI spend. Tackling security first unblocked the other two within two weeks.

6. Systems Mapping

Draw a box for each component. Draw arrows showing how they connect. Look for loops, single points of failure, and handoffs with no owner.

One client’s purchase-to-pay process averaged 47 days. The systems map revealed seven approval loops and three systems — SAP, a legacy procurement portal, and a SharePoint list — that shared no data. Removing four loops and building a Power Automate connector between two of the systems brought average cycle time to 12 days.

Which Techniques Work When Standard Solutions Have Already Failed?

7. Assumption Reversal

List every assumption baked into how the problem is framed. Flip each one. Check whether the inverted assumption opens a different solution path.

Assumption: “Staff hate logging time in the project management system.” Reversal: “Staff want accurate time records but hate the current input method.” That reframe led us to build a voice-to-text timesheet integration in Microsoft Teams using Power Automate — completion rates went from 34% to 91% in the first month.

8. Resource Constraint

Solve the problem with 10% of your normal budget, time, or headcount. The artificial limit forces you to find the essential mechanism rather than the comfortable one.

A client needed cross-project portfolio visibility but had no capital budget. We built a Power BI dashboard against their existing Project Online data in two days. It answered the same questions a £60,000 PPM tool implementation would have taken six months to answer.

9. Outsider Perspective

Explain the problem to someone with zero context in your industry. Their questions — which feel obvious — expose assumptions you stopped questioning years ago.

We explained a document version control problem to someone with no SharePoint background. Their question: “Why does anyone need to save a file at all?” Led directly to enforcing co-authoring in SharePoint with auto-versioning enabled. Eliminated 90% of the version conflict tickets overnight.

Which Techniques Work When You Need Group Buy-In?

10. Silent Brainstorming

Everyone writes ideas independently for 10 minutes before any discussion starts. Then share. This prevents the first person to speak from anchoring the entire room’s thinking.

Use this in any session where seniority gradients exist. Junior analysts consistently produce the most operational insights — they just don’t produce them when a director speaks first.

11. Devil’s Advocate Rotation

Assign one person to argue against each proposed solution. Rotate the role every 15 minutes so no one becomes the permanent pessimist. Run this before any solution moves to implementation planning.

12. Solution Ranking Matrix

List candidate solutions as rows. List decision criteria as columns — typically: cost, implementation time, risk, and expected impact. Score each cell 1–5. Weight the columns by importance. Multiply and sum. Highest score proceeds.

This makes the selection logic visible and auditable. In programme governance, that matters — especially when a decision gets revisited six months later.

Which Techniques Work on Problems That Keep Coming Back?

13. Pre-Mortem Analysis

Assume the solution has already failed — six months from now. Write a one-paragraph post-incident report explaining why. Then design specific controls against each failure mode you’ve just described.

We run pre-mortems before every AI agent deployment. The most common finding: the human escalation path wasn’t defined clearly enough. Finding it in a pre-mortem costs nothing. Finding it in production costs significantly more.

14. Theory of Constraints

Identify the single binding constraint in the system. Everything else is secondary until that constraint is resolved. Optimising non-constraints first is waste.

We increased one client’s RPA throughput by 40% without changing any of the bots — by fixing the approval queue that was the actual bottleneck. The bots had been sitting idle 60% of the time waiting for human sign-off.

15. Jobs-to-Be-Done

Don’t ask what the solution should look like. Ask what job the end user is actually trying to complete. The answer is usually simpler than the proposed solution.

A client wanted a custom AI dashboard for executive reporting. The actual job: “Know within 60 seconds whether any programme is off-track.” A filtered Power BI bookmark with three KPIs answered that job. The custom dashboard idea was shelved.

16. Opportunity Cost Analysis

For every hour this problem consumes, what else isn’t getting done? Sometimes the correct answer is to stop solving the problem — particularly when the cost of solving exceeds the cost of living with it.

17. Solution Stacking

Stop waiting for one complete solution. Three 60% solutions running in parallel often produce better outcomes faster. This is especially relevant in AI projects where no single model handles every case perfectly.

18. Time Boxing

Allocate exactly 30 minutes to reach a decision. Hard stop. Time pressure eliminates the analysis paralysis that makes meetings run long and decisions arrive late.

19. Single-Instance Testing

Before any rollout, test the solution with one person for one day in real working conditions. Real usage breaks assumptions that documentation never catches. We’ve stopped three AI chatbot deployments at this stage — always glad we did.

How Do You Choose the Right Technique for Your Problem?

The selection logic is straightforward once you categorise the problem type:

• Operational problems needing fast resolution: Techniques 1–3
• Complex systemic issues with unclear root causes: Techniques 4–6
• Creative challenges where standard approaches have stalled: Techniques 7–9
• Political problems requiring visible buy-in: Techniques 10–12
• Persistent problems that resurface repeatedly: Techniques 13–19

The meta-skill isn’t knowing all 19. It’s spending 60 seconds categorising the problem before reaching for a technique. Most teams skip that step — then wonder why the framework didn’t work.

What Makes Problem-Solving Break Down in Practice?

Three failure modes appear consistently across industries. First: misdiagnosed problem type. A political problem treated as a technical problem will produce a technically correct solution that nobody implements. Second: wrong scope. Trying to solve the entire system when the actual blocker is one approval step. Third: skipping single-instance testing. Solutions that look complete in a workshop regularly fail on first contact with real users and real data.

The 19 techniques above cover all three failure modes — but only if you match the technique to the actual problem, not the problem you wish you had.

Frequently asked questions

How do you choose the right problem-solving technique for your situation?

Start by classifying the problem before picking a tool. Operational problems with time pressure suit fast-cycle methods like the 5-Minute Rule or What Would [Expert] Do. Complex, systemic problems — such as repeated report failures or stalled programme governance — suit structural methods like the 5 Whys or Force Field Analysis. The most common mistake is defaulting to a workshop format regardless of problem type. A political deadlock inside a programme board needs different thinking than a technical data refresh failure in Power BI.

Why does the 5 Whys often fail to find the real root cause?

Because most teams stop at the first plausible-sounding answer rather than a specific, measurable one. “People don’t prioritise it” is not a root cause — it’s an observation. A root cause is “source data isn’t available until Thursday at 3 PM, leaving two hours for a four-hour process.” That answer points directly to a scheduling fix. If your fifth why still sounds like an attitude problem, you haven’t gone deep enough.

When is Opposite Thinking more useful than standard brainstorming?

When the problem keeps recurring despite previous fix attempts. Standard brainstorming generates new ideas; Opposite Thinking exposes what’s already broken. Listing every action guaranteed to make a Power BI semantic model degrade — multiple unsynchronised data sources, no row-level security, calculated columns stacked on other calculated columns — immediately reveals whether those conditions exist in production. If they do, you have your diagnosis without needing a workshop.

Can these techniques be applied to AI and Microsoft 365 implementation problems specifically?

Yes, and they’re regularly more useful there than generic change management playbooks. M365 Copilot adoption resistance at week three is a measurable adoption telemetry problem — check usage data in the M365 Admin Centre before assuming the product isn’t landing. AI chatbot governance stalls are typically Force Field Analysis problems: identify which blocker (IT security, legal review, procurement approval) unblocks the others when resolved first. The technique doesn’t change; what changes is knowing which data source or approval gate to examine first.