What is the 5 Whys framework?

Summary

Stop treating symptoms. Start solving root causes. The 5 Whys framework cuts through surface-level problems to uncover the real issues holding your team back.

In this guide, you will learn:

• What the 5 Whys framework is and when to use it
• The historical background and origins from Toyota
• How to apply the 5 Whys step-by-step with evidence-based questioning
• Real-world examples from product teams using Miro
• When the 5 Whys works — and when it doesn't
• How to facilitate effective 5 Whys sessions with Miro AI
• Common mistakes to avoid
• Best practices for getting reliable results

Quick Reference: 5 Whys at a Glance

• Definition: A simple problem-solving technique that asks "why" five times to find root causes
• Best for: Simple to moderately complex problems with likely single causes
• Time needed: 30-60 minutes
• Key requirement: Each answer must be backed by evidence, not assumptions
• Origin: Developed by Sakichi Toyoda at Toyota in the 1930s

What is the 5 Whys Framework?

The 5 Whys framework is a simple problem-solving technique that helps you identify the root cause of a problem by asking "why" five times (or more). Instead of addressing surface symptoms, this method pushes you to dig deeper until you uncover the fundamental issue causing the problem.

Why it works:

The technique forces teams to move beyond quick fixes and surface-level solutions. When something goes wrong, our natural instinct is to patch the immediate issue and move on. A server crashed? Restart it. A customer complained? Offer a discount. A deadline was missed? Work overtime next time. These responses address symptoms, not causes.

The 5 Whys reveals systemic issues that, when left unaddressed, create recurring problems. It requires minimal time and resources compared to complex analytical frameworks, yet it can be applied to almost any type of problem. Most importantly, by identifying and fixing root causes rather than symptoms, you prevent problems from recurring.

Use it to transform "we keep having the same problem" into "we fixed the actual cause." Whether you're debugging production issues, investigating project delays, or understanding why customer complaints keep surfacing, this framework helps you stop applying band-aids and start implementing real solutions.

The method's power lies in its simplicity: you don't need specialized training, expensive consultants, or lengthy analysis periods. You just need the discipline to keep asking "why" until you reach the real issue.

Origins of the 5 Whys: From Toyota to global adoption

How Toyota developed the method

The 5 Whys technique was developed by Sakichi Toyoda, founder of Toyota Industries, in the 1930s. It became a cornerstone of the Toyota Production System — the methodology that revolutionized manufacturing and laid the foundation for Lean thinking.

Toyoda recognized that most production problems had deeper causes than what appeared on the surface. Rather than reacting to each incident individually, he developed a systematic approach to uncover underlying issues that, once addressed, would prevent multiple problems from recurring.

The method's brilliance lies in its simplicity. You don't need specialized training, expensive tools, or complex frameworks. Just a clear problem statement and the discipline to keep asking "why" until you reach the real cause.

Beyond manufacturing: Where 5 Whys is used today

The technique has expanded far beyond Toyota's factory floors. Product teams use it to diagnose feature delays and user experience issues. Engineering teams apply it for debugging and incident response, finding it valuable during post-mortems where tracing failures back to their source reveals gaps in testing, monitoring, or deployment processes.

Operations teams leverage the method to improve processes and reduce inefficiencies, uncovering systemic bottlenecks. Marketing teams apply it when campaign performance drops, discovering that real issues often lie in audience research or planning processes. Healthcare organizations employ it extensively for patient safety and quality improvement, where understanding root causes can literally save lives.

How the 5 Whys works: Core principles

The basic concept

The 5 Whys method follows a deceptively simple pattern. You start with a problem, then ask "why it happened" and record the answer. Use that answer to ask "why" again. Repeat this process until asking "why" no longer produces useful information — at that point, you've typically reached your root cause.

The technique is iterative by design. Each answer forms the basis for the next question, creating a chain of causality that leads you from symptom to source. Think of it like peeling an onion: each layer you remove reveals another layer underneath, and you keep going until you reach the core. The power of this approach is that it prevents teams from jumping to solutions before they truly understand the problem. By forcing yourself to ask "why" multiple times, you resist the temptation to stop at the first plausible explanation and instead push through to deeper understanding.

Why "Five" Whys?

Here's something important to understand: the number five is a guideline, not a strict rule. Simple problems might only need two or three whys before you reach an actionable root cause. Complex problems might need seven, eight, or even more iterations before you uncover the fundamental issue. The goal isn't to hit exactly five questions like you're following a recipe. The goal is to dig deep enough that you uncover a systemic issue you can actually fix — something that, when addressed, will prevent the problem from recurring.

You'll know you've gone deep enough when asking "why" one more time either produces the same answer you just got, circles back to something you've already identified, or simply doesn't generate any useful new information. That's your signal to stop digging and start focusing on solutions.

Linear vs. branching analysis

Not all 5 Whys analyses follow a single straight line. Sometimes you'll encounter problems with multiple contributing causes, and you'll need to choose between a linear or branching approach.

Linear analysis works best for straightforward issues with clear causal chains. One problem leads to one cause, which leads to one deeper cause, which eventually leads to a single root cause. For example, if your website went down because a server crashed, and the server crashed because it ran out of memory, and it ran out of memory because of a memory leak in recently deployed code, that's a linear path from symptom to source.

Branching analysis becomes necessary when several factors contribute to a problem simultaneously. When you ask your first "why" and get multiple valid answers, you need to explore each path separately to understand how different causes interact. For instance, if project timelines keep slipping, you might discover multiple contributing factors: requirements changing mid-sprint, insufficient testing resources, and unclear approval processes. Each of these deserves its own line of questioning.

When you find yourself in a branching scenario, consider switching to a fishbone diagram to visualize the multiple paths. This helps teams see how different causes relate to each other and ensures you don't lose track of any important branch in your analysis.

Mastering the 5 Whys: Step-by-step guide

Step 1: State your problem clearly

The foundation: A clear, specific problem statement. Vague problems produce vague root causes.

Your problem statement needs to be concrete enough that everyone on the team immediately understands what went wrong and can verify whether it's been fixed later.

Make it specific, not general:

• ❌ "Website isn't performing well"
• ✅ "Website conversion dropped 30% in Q3"

The first statement could mean anything from slow load times to broken links to poor content. The second statement is measurable and focused.

Make it measurable:

• ❌ "Customer service is slow"
• ✅ "Customer support response time increased from 4 hours to 48 hours"

Focus on one issue at a time. If you're trying to analyze why your product launch was late, why customers are complaining, and why your team is burnt out all in the same session, you'll end up with a muddled analysis that doesn't help anyone. Pick the most pressing problem, solve it, then move to the next one.

Step 2: Ask your first "Why?"

Simple: Why did this problem happen? Write down the answer based on facts, not assumptions.

Example:

• Problem: Our app shipped two days late
• First Why: Why was it late? → The engineering team had to deploy a last-minute patch

Step 3: Validate with evidence

Critical step: Before moving to the next "why," verify your answer with data. This is what separates effective analysis from speculation.

Without evidence, your analysis can easily drift into assumptions, office politics, or convenient narratives that feel true but don't actually reflect reality.

Evidence comes in many forms:

• System logs, timestamps, error reports
• Performance metrics or analytics
• Documentation, project management records
• Customer interviews, support tickets
• Direct observations

The key is that your evidence should be verifiable and specific, not based on "I think" or "it seems like."

See the difference:

• ❌ "Sales dropped because the team wasn't motivated" (assumption)
• ✅ "Sales dropped because we had 40% fewer demos scheduled, according to our CRM data" (evidence)

When you can't find evidence: Pause. Don't move forward with unverified claims. Take time to investigate, gather data, or acknowledge uncertainty. It's better to admit you don't know than to build your entire analysis on shaky assumptions.

Step 4: Keep asking "Why?" Until you find the root cause

The discipline: Take your answer from the previous "why" and ask why that happened. Keep building the chain of causality.

This is where the method really tests your patience. It's tempting to stop at the first answer that sounds reasonable, but the first answer is often just another symptom in disguise.

Following our app delay example:

Second Why: Why did engineering need a last-minute patch? → A critical bug was found during final testing

Third Why: Why wasn't the bug caught earlier? → Testing happened too late in the development cycle

Fourth Why: Why was testing late? → Development ran over schedule

Fifth Why: Why did development run over? → Requirements changed mid-sprint without adjusting the timeline

Now we're getting somewhere. The root cause isn't the bug itself, or even the late testing. It's the lack of a process for adjusting timelines when requirements change during development.

You've reached the root cause when:

• Asking "why" again doesn't produce useful information
• The answer points to a process, system, or policy issue
• The team agrees this is the fundamental issue
• You can imagine a concrete solution that prevents recurrence

Important: If your root cause is "because John forgot," you haven't gone deep enough — ask why the system allowed John's memory to be the only safeguard.

Step 5: Develop and implement your solution

Now: Brainstorm solutions that address the root cause directly, not the symptoms.

If your root cause is "no process for adjusting timelines when requirements change," don't just tell the team to "be more flexible" or "communicate better." Those are vague directives that address symptoms rather than creating systemic change.

Create concrete action plans:

• Define specifics: When requirements change, who gets notified? Who adjusts timelines? How are changes communicated?
• Assign clear ownership: One person accountable for implementation
• Set deadlines: Implement by [specific date]
• Schedule follow-ups: Review in 30-60 days to verify it worked

Example for our app delay:

• Root cause: No process for adjusting timelines when requirements change mid-sprint
• Solution: Implement requirement change protocol with automatic timeline reassessment
• Owner: Product Manager
• Timeline: Implement by next sprint
• Follow-up: Review next 3 sprints to confirm deadlines are met when requirements change

Why follow-up matters: It confirms whether you correctly identified the root cause. If the problem recurs, you probably didn't dig deep enough. Follow-ups also ensure solutions don't just get documented and forgotten — they create accountability.

5 Whys in action: Real-world example from Medibank

Medibank, Australia's largest health insurer, faced a challenge familiar to many product teams: innovation cycles that stretched for months, with stakeholders scattered across business units and busy executive calendars making alignment difficult.

The problem

Their Digital Labs team was tasked with reimagining medibank.com.au — a project typically requiring six months to achieve stakeholder alignment and prototype vision. This wasn't just any website; it was their digital front door, requiring input from over 80 stakeholders across the entire enterprise.

Applying 5 Whys thinking

While Medibank didn't document a formal 5 Whys analysis, their approach demonstrated the framework's core principle: digging past surface symptoms to uncover root causes.

The surface problem: Projects take too long

Digging deeper revealed:

• Why were projects slow? → Stakeholders couldn't align quickly
• Why couldn't they align? → Information was scattered across PowerPoint, Excel, Jira, Confluence
• Why was information scattered? → No single space to capture everything
• Why no single space? → Teams lacked a collaborative platform for real-time alignment
• Root cause: No unified workspace where diverse stakeholders could see the complete picture and provide input simultaneously

The solution using Miro

The team brought all stakeholders together in a single Miro board. Instead of traditional back-and-forth cycles, they:

• Captured over 140 pain points in one living board
• Created tailored templates for each business area
• Used Miro's collaborative features so senior executives could immediately see the complete picture
• Facilitated real-time prioritization during focused sessions

The result: They compressed a six-month alignment cycle into six weeks — a 75% reduction in time from idea to outcome.

"When everyone's solving the same problem, in the same space, at the same time — that's when the magic happens. That's how six weeks becomes not just possible, but repeatable."

— Ben Abbott, Product Leader at Medibank Digital Labs

Their success validated a key insight of the 5 Whys method: solve the systemic issue (lack of unified workspace), and multiple symptom problems (slow alignment, scattered information, difficult scheduling) resolve themselves.

When to use the 5 Whys

The 5 Whys shines when

Problems are simple to moderately complex with likely single dominant causes. Your website crashed? Project missed a deadline? Customer complaints spiked? These situations often have one primary root cause that, once fixed, resolves the issue.

You're dealing with process and operational issues. Problems involving people, handoffs, or unclear procedures are perfectly suited to this technique. Why do reports always come in late? Why do handoffs between teams consistently break down? The 5 Whys helps you trace these back to missing processes, unclear ownership, or misaligned incentives.

The same problem keeps recurring. If you're repeatedly patching the same type of issue, it's a signal you're treating symptoms rather than causes. The 5 Whys forces you to dig deeper and find what keeps generating these symptoms.

You need answers quickly. When something breaks and you need to understand why — fast — the 5 Whys gives you a structured approach without requiring extensive data gathering. You can often complete a solid analysis in under an hour.

You have a diverse team with firsthand knowledge. The collaborative questioning process brings different viewpoints together. One person might know why development was delayed, while another understands why that delay wasn't communicated.

You can verify answers with data. The method works best when you can quickly check logs, pull metrics, review documentation, or talk to people involved. Evidence-backed analysis moves quickly and confidently from symptom to cause.

Common use cases:

• Post-mortem analysis after incidents
• Sprint retrospectives identifying recurring blockers
• Process improvement initiatives
• Customer complaint investigation
• Quality control issue resolution
• Operational efficiency optimization

When NOT to use the 5 Whys

Don't force the 5 Whys onto the wrong problem. This method isn't universal, and using it incorrectly wastes time and produces unreliable results.

The method's limitations

It oversimplifies complex problems. When multiple factors contribute simultaneously and interact in non-linear ways, the linear questioning of 5 Whys misses critical relationships. You might identify one root cause and miss that several others are equally important.

Results depend heavily on who's asking. Different facilitators asking questions in slightly different ways can lead teams to entirely different root causes for the same problem. This makes it less reliable than more structured methods.

Teams often stop at symptoms without realizing it. There's a natural tendency to accept the first plausible explanation. Without rigorous evidence validation, you convince yourself you've reached the root cause when you've really just gone one or two layers deeper.

It only works with knowledge you already have. If the real root cause involves something the team doesn't know about yet — a technical issue you haven't encountered, a market shift you're unaware of, or customer behavior you haven't observed — the 5 Whys won't reveal it.

The "five" is arbitrary. Some problems need two iterations, others need ten. There's no clear rule for when to stop, which leads to either premature conclusions or analysis paralysis.

Use these methods instead

Fishbone diagrams → When problems have multiple contributing factors that all need attention

FMEA (Failure Mode & Effects Analysis) → For high-stakes situations involving safety, regulatory compliance, or critical systems that require formal documentation

Comprehensive root cause analysis → When you need statistical validation, must prove causation with data, or deal with deeply interconnected organizational issues

Fault tree analysis → When analyzing system reliability or mapping multiple failure paths with probabilistic rigor

How to facilitate effective 5 Whys sessions with Miro

Before the session

1. Assemble the right team (4-8 people)

Include people with direct, firsthand knowledge of the process or problem. If you're investigating deployment failures, include the engineers who manage deployments, not just their managers. Cross-functional perspectives add value when the problem touches multiple areas, but everyone should have genuine knowledge to contribute.

Avoid filling the session with only senior leaders removed from day-to-day work — you need people who can say "here's what actually happened" rather than "here's what I assume happened."

2. Prepare your groundwork

• Define one specific problem to analyze
• Gather baseline evidence (logs, metrics, records, documentation)
• Set a time limit: 30-45 minutes for simple issues, 60 minutes for complex problems
• Choose a neutral facilitator to guide discussion without dominating it

3. Select your Miro template

Open one of Miro's 5 Whys templates to provide structure:

• 5 Whys Analysis by Atlassian
• The 5 Whys - Root Cause Analysis
• 5 Whys Basic Template

During the session

1. Start with your problem statement

Write it at the top of your Miro board and read it aloud. Make sure everyone agrees on what you're analyzing before diving into questions.

2. Create a blame-free environment

Focus on systems and processes, not people. When people feel safe, they share openly. Ask "why did this happen" rather than "who did this."

3. Document with sticky notes

Use Miro's sticky notes for each "why" question and answer. This makes it easy to rearrange if you need to branch your analysis. Everyone can add notes simultaneously rather than waiting for one person to type. Use different colors to distinguish questions, answers, and evidence.

4. Validate each answer with evidence

Ask "How do we know this is true?" Reference specific data, logs, or documentation. Add supporting evidence directly to your Miro board — upload screenshots, embed links, or connect to related boards. If you can't find evidence, pause and investigate before moving forward.

5. Watch for branching

When one "why" produces multiple valid answers, create separate sticky note clusters for each path. For complex branching, consider switching to a fishbone diagram format.

6. Test your root cause

Ask: "If we fix this, will the problem stop recurring?" If the answer is yes and the team agrees, you've found it.

Improve your session with Miro AI Sidekicks

Sidekicks accelerates your analysis by handling time-consuming tasks and suggesting new angles to explore:

Use it to:

• Guide questioning: Get AI-suggested follow-up questions based on your answers
• Cluster causes: Automatically group similar sticky notes by theme when your analysis branches
• Generate solutions: Create solution opportunity trees that surface approaches you might not have considered

To access Sidekicks:

1. Click on the "Sidekicks" icon above the Creation bar
2. Select "Sidekicks" from the panel
3. Describe your goal: "Help me facilitate a root cause analysis for recurring product delays"
4. Let Sidekicks guide your questioning and organize findings

The combination of human insight and AI assistance helps you compress analysis time while improving depth and quality.

After the session

1. Document everything on your Miro board

Record the full analysis chain, supporting evidence, and any branches explored. This creates a record for people who weren't there and helps track whether your root cause was correct.

2. Share findings with context

Use Miro's sharing features to send the board to your broader team. Add narrative about what you discovered and what actions you're taking.

3. Create concrete action plans

• Define specific solutions (not vague commitments like "improve our process")
• Assign clear ownership
• Set defined deadlines
• Schedule follow-up reviews in 30-60 days

4. Track effectiveness

Monitor whether the problem recurs. If it does, that's valuable data — it means your root cause identification was incomplete or your solution didn't adequately address it. Use that information to refine your understanding and try again.

Common mistakes to avoid

1. Stopping at symptoms

Mistake: Accepting the first plausible answer without digging deeper

Example:

• ❌ Stops too early: "Sales dropped because leads decreased"
• ✅ Keeps digging: "...leads decreased because our SEO ranking dropped...because we haven't published content in 6 months...because we eliminated the content team...because budget was cut without considering revenue impact"

Fix: Always ask "why" at least 3-4 times even if an answer seems obvious

2. Relying on assumptions instead of evidence

Mistake: Basing answers on opinions or guesses

Example:

• ❌ Assumption: "Customers aren't buying because our product is too expensive"
• ✅ Evidence: "Customer survey data shows 73% cite 'lack of integration with existing tools' as main barrier"

Fix: Demand proof for each "why" — if you can't verify it, investigate before moving forward

3. Blaming people instead of systems

Mistake: Ending the analysis with "someone forgot" or "person X made a mistake"

Example:

• ❌ Stops at blame: "The deployment failed because the engineer forgot to run tests"
• ✅ Examines systems: "...because there's no automated testing requirement in our CI/CD pipeline...because we haven't prioritized build automation...because technical debt wasn't included in quarterly planning"

Fix: When you reach a person, ask "Why did the system allow this to happen?"

4. Using 5 Whys for complex problems

Mistake: Forcing a simple tool onto multi-factorial issues

Example:

• ❌ Wrong tool: Using 5 Whys for "Why did our company culture decline?" (too complex, too many factors)
• ✅ Right tool: Use employee surveys, focus groups, and comprehensive cultural assessment

Fix: Recognize when to switch to more robust analysis methods

5. Accepting first answer without challenging

Mistake: Not exploring alternative causes

Example: After "Why did the server crash?" → "Because of high traffic"

• ❌ Accepts it: Moves to next why
• ✅ Challenges it: "What else could have caused it? Could it be memory leak? Configuration issue? Let's verify with logs"

Fix: Ask "What else could have caused this?" before moving forward

6. Analyzing without implementing

Mistake: Completing thorough analysis but never fixing the root cause

Fix: Analysis is worthless without action — assign owners, set deadlines, track results

7. Not validating solutions worked

Mistake: Assuming the problem is solved without checking

Fix: Schedule follow-up 30-60 days later to verify the root cause was correct and the problem hasn't recurred

Amplifying the 5 Whys with Fishbone Diagrams

You can improve the 5 Whys by pairing it with a fishbone diagram, also known as the Ishikawa Diagram. This combination works when:

• Your problem has multiple potential causes
• You need to explore different categories (People, Process, Tools, Environment)
• The team identifies several answers to a single "why"

How to combine them:

1. Create a fishbone diagram to brainstorm all possible causes
2. For each major cause branch, apply the 5 Whys to dig deeper
3. This gives you both breadth (fishbone) and depth (5 whys)

Miro has easy-to-customize fishbone diagram templates that integrate with 5 Whys analysis.

Best practices for reliable results

Focus on processes, not people

When you reach "someone forgot" or "person X didn't do something," you haven't gone deep enough. Ask why the system allowed that person's memory or judgment to be the only safeguard. Maybe there's no checklist, no automated alert, or no clear ownership. These are systemic issues that prevent problems regardless of who's doing the work.

Validate every step with evidence

Your analysis is only as good as your evidence. Logs, timestamps, records, metrics, documentation, and direct observations all count. "I think" or "it seems like" do not count. If you can't verify an answer, pause and investigate. Building a causal chain on assumptions is like building a house on sand.

Don't force exactly five whys

Stop when you reach an actionable root cause that will prevent recurrence. Some problems need two or three iterations, others need seven or eight. What matters is reaching a systemic issue you can actually address, not hitting a magic number.

Involve people with firsthand knowledge

You need team members who have direct knowledge of the process, witnessed the problem, understand the systems affected, and can implement solutions. A room full of managers who haven't touched the work in years produces theoretical analysis. The right mix depends on your specific problem.

Test your root cause before committing

Ask yourselves: Would fixing this actually prevent recurrence? Does the whole team agree this is fundamental? Can we implement a concrete, measurable solution? Does the causal chain make logical sense? If you get hesitation on any of these, keep digging.

Document everything in Miro

Record each question and answer, capture supporting evidence, identify the root cause clearly, outline proposed solutions with specifics, and assign action owners with deadlines. This creates organizational learning and accountability. Use Miro's features to export boards, link related analyses, and create formal reports from your findings.

5 Whys Frequently Asked Questions

Does it have to be exactly 5 whys?

No. The "five" is a guideline, not a rule. Ask "why" as many times as needed to reach an actionable root cause. Simple problems might need 2-3 whys, while complex ones might need 7-8 or more.

Can a problem have multiple root causes?

Yes. When a single "why" produces several different answers, your analysis should branch into multiple paths. Consider using a fishbone diagram to map these multiple root causes visually.

Who should participate in a 5 Whys session?

Include 4-8 people who have direct knowledge of the process or problem. Mix team members from different functions when relevant, but ensure participants have hands-on experience, not just managerial oversight.

How long should a 5 Whys session take?

Simple problems: 30-45 minutes Moderately complex problems: 60 minutes

If you need longer than 90 minutes, consider whether 5 Whys is the right tool or if you need more comprehensive root cause analysis.

What's the difference between 5 Whys and root cause analysis?

5 Whys is one specific technique within root cause analysis. Root cause analysis is the broader category that includes many methods (5 Whys, FMEA, Fishbone, Fault Tree Analysis, etc.). Think of 5 Whys as a simple, fast RCA tool.

How do I know when I've found the real root cause?

You've found it when:

• Asking "why" no longer produces useful answers
• The answer points to a process or system issue
• Fixing this cause would prevent recurrence
• Your team agrees this is the fundamental issue
• You can implement a concrete solution

What if my team disagrees on the root cause?

This is common. Use evidence to resolve disagreements — what does the data show? You may discover multiple root causes that all need addressing, or the disagreement reveals you need to dig deeper.

Can I use 5 Whys for personal problems?

Absolutely. The five whys technique works for career decisions, relationship challenges, productivity problems — any situation where you want to understand underlying causes rather than just symptoms.

What if we implement a solution and the problem returns?

This means you likely didn't identify the true root cause. Run the 5 Whys again, this time exploring different paths and validating each answer more rigorously with evidence.

Ready to start your 5 Whys analysis?

The 5 Whys is one of the simplest yet most powerful problem-solving tools available. By asking "why" repeatedly and validating each answer with evidence, you can move from treating symptoms to solving fundamental issues.

Key takeaways:

• Start with a clear, specific problem statement
• Validate each "why" with data, not assumptions
• Keep asking until you reach an actionable root cause
• Focus on systems and processes, not people
• Know when to use 5 Whys — and when to choose other methods
• Document your analysis and track solution effectiveness

Get started now:

Use Miro's 5 Whys templates to run your first analysis with your team. Our visual collaboration platform makes it easy to facilitate sessions, document findings, and track solutions — whether your team is remote or in-person. Plus, with Miro AI Sidekicks, you can get intelligent guidance through the questioning process and turn your analysis into actionable solutions faster.

Try Miro's 5 Whys Template Free →

Related resources

Continue learning about problem-solving:

• Root Cause Analysis Templates - Explore all RCA methods
• Fishbone Diagram Template - Visual tool for complex problems
• FMEA Analysis Templates - Alternative analysis approach

Miro templates for problem-solving:

• 5 Whys Analysis by Atlassian
• 5 Whys for Failed Sprint Goal Retrospective
• 5 Whys Counter Measures Template
• Root Cause Evaluation Template

Author: Miro Team

Last update: December 11, 2025