How the 5 Whys Method Actually Works
The 5 Whys Analysis is pretty straightforward on the surface: you ask “why?” repeatedly — ideally five times — to drill down to the root cause of a problem. But in actual practice, it’s rarely that clean. Sometimes you hit the real issue on the second “why.” Other times you’re still arguing about the third one in a meeting that should’ve ended 20 minutes ago. Let’s first quickly illustrate how it looks in a manual form.
Thank you for reading this post, don't forget to subscribe!| Iteration | Question | Answer |
|---|---|---|
| 1st Why | Why was the report missing data? | Because the data from the form never made it to the database. |
| 2nd Why | Why didn’t the form data reach the database? | Because the webhook was misconfigured. |
| 3rd Why | Why was the webhook misconfigured? | Because we cloned a workflow from another product without updating the payload URL. |
This usually continues until you uncover a policy flaw, training issue, or unclear documentation. The goal is not just patching the problem — it’s figuring out how to prevent it for good. That’s where it gets missed when teams treat “the fifth why” as a checkbox instead of a moment of insight.
Most teams try to do this with a whiteboard or in a long-threaded Slack conversation. The question is: how do you track this process reliably, especially across projects or audits? That’s where Google Docs and Confluence come in — two tools with very different vibes.
Google Docs vs Confluence: Basic Purpose and Philosophy
These two tools have wildly different workflows. Google Docs feels like a live notepad you can share instantly. Confluence is structured like a wiki — built for long-term, interconnected documentation. If you’re doing a one-off 5 Whys session and need to quickly share it across a small team, Google Docs wins every time. But for teams who want a persistent artifact linked to their larger project docs, Confluence makes more sense.
Let’s highlight some of the key environment differences:
| Feature | Google Docs | Confluence |
|---|---|---|
| Real-time Collaboration | Yes (full sync) | Yes, but slower collaboration tools |
| Templates | Manual or third-party add-ons | Native blueprint templates for 5 Whys |
| Permission Controls | Quick sharing, but hard to lock down granularly | Granular page-level permissions built-in |
| Integration with Issue Management | Weak (unless using add-ons) | Strong Jira linking and embedding |
To wrap that up: Docs is chaotic good. It lets you get started immediately, but you’ll be manually pasting rows and using tables just to sort anything. Confluence is lawful neutral — it imposes structure, but not without its own friction and loading quirks.
Capturing a 5 Whys Session in Google Docs
If you’re going to run a 5 Whys session in Google Docs, the setup is almost too easy. But that also means you can easily end up with a messy doc no one wants to revisit. Here’s an actual process I used when running a tools outage post-mortem for a remote product team:
- Open a new Google Doc and title it with the incident. Example: “[5 Whys] October Login Bug”
- Create a table with three columns: #, Why, Answer
- Use comments aggressively. Right-click any cell and use “Comment” to challenge reasoning or provide context. This creates a record without messing up the primary answers.
- Use the @ menu to assign owners. For example, if one answer involves developer handoff, tag someone and assign a follow-up task.
- Duplicate templates using File > Make a copy for every new incident. This is the fastest way to keep format consistency without requiring a complex setup.
What breaks? Well, formatting. Docs doesn’t lock table layout controls. If someone presses enter too many times inside a row, the whole thing stretches. You also can’t embed the doc in tools like Jira in a useful way, which matters if you’re reviewing post-mortems during retros.
At the end of the day, Google Docs works best when time-sensitive discussions matter more than traceability. Startups and ops teams racing through issues usually benefit.
Running 5 Whys Sessions in Confluence
Confluence is a living document system — every page can exist on its own, but also be part of a larger network of documentation. Here’s how we ran a full 5 Whys inside Confluence after a broken email campaign sparked hundreds of duplicate sends:
Set Up:
- Create a new Confluence page based on the “Root Cause Analysis” template (included in most standard spaces)
- Add an “Expand” macro for each why. This helps collapse each layer visually, especially when upper management just wants to see root causes.
- Use “Action item” macros within each cause explanation to assign follow-up investigation or verification steps.
- Tag the incident using the label system — makes future queries or dashboards easier to create if you’re documenting multiple recurring issues.
Biggest advantage? You can link directly to related documentation — like product requirement pages, past retro discussions, or user bug reports. You’re not locked in a linear doc. Navigation and traceability are superior. That also means if an issue resurfaces months later, you’re not starting from scratch. You just revisit the page, update if needed, and link from new task tickets.
But… permissions can get convoluted. If your Confluence space is too locked down (some teams keep incident logs under Ops-only visibility), others can’t benefit from shared learning. Plus, formatting can get clunky if contributors aren’t familiar with macros — I’ve seen Why #3 end up under Why #4 due to poorly nested structures.
Ultimately, Confluence becomes your best call if problem-solving is tracked as part of team metrics or you want audit trails linked to policy update tracking.
Comparing Real Case Outcomes with Each Tool
We’ve used both tools in live firefight settings. Here’s what we actually saw over months of real usage:
Google Docs sessions: Easy to schedule, fast to complete, but rarely revisited. We had team leads forget we’d already analyzed the same webhook bug two months prior.
Confluence sessions: Took more time up front, but more likely to be cited again or used in future sprint decisions. Our weekly retros gradually shifted to referencing Confluence over email threads once we trusted the structure.
The bottom line is: usability affects follow-through.
Which Tool to Choose for Your Team
Honestly, it depends on how your team thinks and moves. If you’re a squad that runs hot — quick decisions, constant iteration — Google Docs might be all you need. But if you’re managing long-lifecycle projects, or you’re in a regulated industry where document retention and traceability matter, Confluence is far more powerful long-term.
It’s also not either/or. Some teams run the initial session in Docs, then paste the direct findings into Confluence to archive or build a case for further changes. I’ve even seen folks use automation tools like Zapier or Make to copy Docs content into Confluence pages — but that’s a hack that needs maintaining.
To sum up, pick the tool that supports your cadence, not just the format.
