The 6Ws Framework: A sequential diagnostic methodology

Intro

This is an attempt to codify how I actually work through a problem.

In practice it rarely looks like six neat steps. Most of it runs fast, often without me naming the stages as I go. But the sequence is there underneath, and over the years I've taught parts of it to people I've worked with. This is the first time I've drawn the whole thing together so someone else can pick it up and run it themselves.

The shape is simple: six questions, asked in order, each one feeding the next. Run forwards, it's a way of pulling insight out of a mess. Run backwards, it's a way of finding where the thinking went wrong — "we missed it at step 5" instead of "communication broke down."

The order matters. You can't stress-test what you haven't transferred; you can't transfer what you haven't diagnosed; you can't diagnose without something that doesn't fit in the first place. Skip a step and you tend to get an answer that sounds right and falls over under pressure.

What follows is the sequence, then one case worked all the way through — a division that looked like it had a client problem and didn't.

The Six Ws 

1. What doesn't fit? Entry condition. Something contradicts the accepted framing. A gap between what's described and what's actually happening, a question nobody's asking, an assumption being treated as fact. This is pattern recognition and gap analysis. Not identifying a pattern you've seen before, but detecting where the current pattern breaks. Critically, the absence of a signal is often more important than the signal itself. What should be happening that isn't? What data should exist that doesn't? What conversation should have happened that hasn't? If no anomaly is visible, assume one exists and test the current system against expected outcomes. This can be self-detected or externally identified. The framework doesn't require you to be the one who notices, it requires that the anomaly exists before diagnosis begins. 

Diagnostic mirror: Did you ignore the anomaly because it was inconvenient? Did you start solving before you'd actually identified a misalignment? 

2. What is it actually doing? Diagnosis. Once the mismatch is identified, this step isolates what's actually causing it. This is signal detection and the antidote to the nominal fallacy, the mistake of believing that naming something explains it. Strip the label and describe the actual mechanism. Not what it's called, not what it's categorised as, not what the experts in the room have agreed it is. What is it doing, structurally, when you remove the context everyone else is operating in? The forcing function is simple: describe it without using its name. Explain it as a process, not a category. This is where most conventional thinking never arrives. It stays inside the frame and analyses from there. This step demands you leave the frame before you analyse. It's where you find the assumptions nobody's questioned, the biases baked into the process, the systems that have grown organically over time without a fundamental core to work from, and the inefficiencies that everyone tolerates because they've been there so long they look like features.

Diagnostic mirror: Did you stay inside the conventional frame? Did you mistake the label for the function? 

3. So what? Consequence. Vertical. What follows from this diagnosis? What breaks, what changes, what becomes inevitable? This is first principles thinking and root cause analysis. If the diagnosis is accurate, the consequences should be derivable, not arguable. The discipline here is resisting the urge to leap to solutions and instead following the chain of effect to its honest conclusion. This is where you produce the cost of inaction that determines executive urgency. The second and third order effects that make the problem impossible to ignore, the dependencies that will fail, the timeline on which the current state becomes unsustainable. Crucially, this step serves a secondary, critical function: identifying outlier cases that do not require systemic action. While failure often triggers an instinctive need for a build, asking "how often does this happen?" and "if we scaled 100x, would the problem scale proportionally?" provides the proportionality filter. If the issue is a non-scaling outlier, identification and manual mitigation is often the correct operational choice, preventing the "technical debt" of an unnecessary system. 

Diagnostic mirror: Did you leap to a solution before following the chain of effect? Did you skip the cost of inaction because the answer was uncomfortable? Are you over-engineering a systemic fix for a non-scaling outlier? 

4. What if? Transfer. Horizontal. Where else does this pattern exist? If the mechanism you've diagnosed operates here, where else is it operating under a different name, unrecognised? This is where you produce solutions others have used elsewhere, but it's also where you gather insight from multiple different failures. It is about the creativity and imagination to take a solution from one place and apply it to another, but equally to study how the same problem has broken things in different contexts. Each failure illuminates the problem from a different angle, and partial solutions from each can combine into something none of them could have produced alone. That's the basis of innovation. A structural observation locked inside one context is interesting. The same observation found operating across multiple fields is significant. 

Diagnostic mirror: Was your solution too local? Did you fail to check whether this problem has already been solved somewhere else, or whether its failures elsewhere could have informed a better approach? 

5. Where does this break? Resilience. Forward-facing stress-test. Not "did I get this right?" but "does this hold against what's coming?" This is where you find the load-bearing limits. The point at which the model stops scaling, the condition under which the solution collapses, the assumption about the future that would invalidate the whole structure if it turned out to be wrong. Will this hold at 10x? Does it account for the technology, regulation, or market shift that is already visible on the horizon?

For experienced operators, this often becomes an embedded constraint during design rather than a separate step. For most users, it must be run explicitly. Candour and critical thinking are required here. If you cannot impartially stress-test your own work, a well-structured query to an LLM can.

Diagnostic mirror: Did you fall in love with your transfer and skip the stress-test? Where did you assume the future would be static? 

6. What next? Implement and iteration. The tested insight resolves into a structural understanding or an action. A framework, a model, a decision, a build. But this is rarely the end. There are usually multiple issues within a system, or the process has unearthed a new misalignment that wasn't visible before. This is iterative development and problem solving. The 80/20 approach in action. Solve the highest-impact problem, then run the pipeline again on the next one. The measure of the whole framework is whether each pass produces something someone else can use without needing to have run the previous five themselves. 

Diagnostic mirror: Is the output usable by someone who wasn't in the room? If it requires your presence to make sense, it isn't finished.

Case Study

A COVID-testing division served large film and television productions. The division was at war with its clients. Leadership framed it as a compliance problem — clients refusing to follow internal process. Meetings were confrontational; nobody was looking for solutions.

W1: Anomaly. The presenting problem was client behaviour; the anomaly sat underneath it. Film and TV runs on managed unpredictability — the light changes, the director changes the shot, the production relocates within hours. A model built on the assumption that this environment could be made predictable wasn't failing because of difficult clients. It was failing because it was designed for conditions that didn't exist.

W2: Diagnosis. Strip "difficult clients" as the label. What was actually happening: a lab-centric model built for controlled, stable environments, applied to an industry where no two days look alike. The function the system performed wasn't "testing." It was logistics and planning under constant ambiguity. The label had hidden the mechanism.

W3: Consequence. The division's largest revenue line was running well below the margin it should have. Crisis calls with the primary client were weekly. On the biggest production days, with lead talent on site, an operational failure could halt a shoot — and a halted day was enormously expensive. The proportionality filter confirmed this was systemic, not an outlier: every production, every phase, every week. The cost of inaction wasn't friction; it was the relationship itself.

W4: Transfer. The solutions came from outside the domain. Productions already use location-shooting planning frameworks to manage exactly this ambiguity — that discipline was borrowed from the industry being served and applied back to the service. Queuing systems were lifted from events. Holding reserves came from military logistics. Mobile testing already ran from trailers on site; the transfer was asking whether more versatile vehicles could follow productions off-location. No single source — each transfer compounded into the redesign. The framework was later requested by the largest client and distributed to its other providers as the model to follow.

W5: Resilience. The framework was stress-tested through escalating complexity, and each stage broke the last one's assumptions. Studio-lot shooting was the easy case. Outdoor lots away from amenities needed new sections. Remote locations broke the assumption that a courier could close a supply gap, forcing planning for lead times and transport. International shoots forced integration with local labs, dual-regulation compliance, and customs and in-country sourcing that domestic assumptions never anticipated. A structured core, with modular sections added as each new condition appeared.

W6: Next. Dozens of iterative innovations across the operational lifecycle. Margins recovered sharply. Weekly crisis calls became monthly strategic reviews. As productions wrapped, leads moved to new films and insisted on keeping the service even where a competitor had been incumbent. The system generated its own demand — and outlasted both the engagement and the company that built it.

So what?

The case looks like a turnaround story. For me it was just the sequence running on a hard problem — the same sequence I'd run on a small one.

What I find useful about writing it down this way is that it's traceable. Each step leaves something the next one stands on, so when an answer holds you can see why, and when it fails you can point at the step where it went wrong rather than waving at "it just didn't work." That's the part I've found worth teaching.

This is a first attempt to set the whole thing out, rather than pass on a piece of it in the moment. It's how I think, and I've found it holds up. Whether it's useful to you is the real test — and it's the same test I'd apply to anything: can someone who wasn't in the room actually use it?

Operating function

Most frameworks help you reach an answer. What I wanted from this one was something that also shows where the thinking broke when the answer turns out wrong. Used over time, it changes how you diagnose problems rather than just helping you solve one.

It's a sequence, not a checklist — a circuit, not a menu. Each step is a different mode of thinking, and the order does real work. You can't stress-test what you haven't transferred, can't transfer what you haven't diagnosed, can't diagnose without something that doesn't fit. Skipping a step doesn't save time; it produces something that reads as insight and isn't.

Each step also leaves evidence the next one stands on, which is what makes it traceable. If you can't show your working at step 3, step 4 isn't ready. If step 4 doesn't survive step 5, it was pattern-matching rather than insight.

Run in reverse, it becomes a diagnostic. When something fails you can trace back through the six and find where it actually went wrong — jumped from diagnosis to solution without following the consequences, transferred without stress-testing. It gives failure a specific, numbered answer. A post-mortem reads "we missed it at step 5 — strong transfer, but we assumed the future would hold still and didn't test for scale," which is more use than "communication broke down."

It's teachable. People can learn to run it on their own problems. The depth at each stage grows with experience, but the discipline — running the order, showing the work, using the diagnostic mirrors — transfers from the start.

It's a scaffold, not a one-off tool. With use the discipline becomes second nature and the framework runs lighter, but it stays useful as a shared reference: bringing someone new up to speed, checking back after a decision to confirm nothing was skipped, giving a team a common language when something goes wrong.

Purpose 

Who: Anyone responsible for making things work, whether that's fixing something broken, building something new, or figuring out why something that should be working isn't. 

Where: Situations where straightforward answers don't exist. Turnarounds, transformations, scaling, building from scratch, spotting opportunities others haven't seen, or preparing for what's coming next. Equally useful in a crisis and in a stable environment that hasn't been stress-tested. 

What: A way of thinking through complex problems in sequence, applied to anything where there's a gap between what people say is happening and what's actually happening, and where that gap has real cost. 

When: When the obvious answer isn't solving the problem. When something has been analysed but keeps failing. When you need to understand, after the fact, exactly where the thinking went wrong. The 6Ws is built for problems with structural causes. It is less applicable to purely political problems where the diagnosis is known but the obstacle is willingness, and it does not replace domain expertise. It works alongside it. 

Why: Most approaches to diagnosis work within one context. The 6Ws moves across contexts: from noticing something is off, through understanding why, what it costs, where else the same thing is happening, whether the fix holds, and what to do next. It also works in reverse. When something fails, you can trace back and find the exact step that was skipped.