The Right Questions
None of these questions are technically difficult. What makes them powerful is not their complexity — it is that they are asked at all. The insider is too busy, too close, and too entangled to ask the question that would reveal the structure of the trap they are inside. Work through each section in order with the relevant step of the method. Do not rush to solutions. The diagnosis is in the answers.
Each section corresponds exactly to one step of the 7-step improvement method. Use the coloured header links to jump between questions and the method page. Ask questions in order within each section. Write every answer down without editing — the questions that produce silence are the most important ones.
Ask these before anything else. If the honest answer to P3 is “we would produce the same outcome twice as fast” — stop persisting and start diagnosing.
| # | Question | What it reveals |
|---|---|---|
| P1 | Is this failure happening in roughly the same way each time, despite different attempts to fix it? | If yes — the failure is structural, not situational |
| P2 | Has effort increased over the past year while results have stayed the same or worsened? | If yes — effort is not the constraint. The system is. |
| P3 | If we doubled our effort from tomorrow, would the result improve — or would we produce the same outcome twice as fast? | Separates effort problems from structural problems cleanly |
| P4 | Does the solution feel obvious to insiders but invisible or uncompelling to outsiders? | If yes — there is likely a jobs mismatch or a perspective gap |
| P5 | Are we persisting because the evidence supports it — or because stopping feels like failure? | Names the sunk cost dynamic before it closes the conversation |
| P6 | What would we need to see in the next twelve weeks to justify continuing on the current path? | Forces a prediction. If no answer exists, there is no method — only hope. |
Ask these of multiple people at different levels. Write every answer down without editing or filtering. More answers are better. Do not group yet — grouping is Step 3.
| # | Question | What it reveals |
|---|---|---|
| S1.1 | What keeps happening that should not keep happening? | Recurring problems — the fingerprint of structural causes |
| S1.2 | What never happens that should be happening? | Missing capabilities — the fingerprint of structural absences |
| S1.3 | What takes far longer or costs far more than it should? | Friction points — where the system works against itself |
| S1.4 | Where do outcomes vary most — some go well, some go badly, for no obvious reason? | Variation hotspots — where the system depends on people rather than design |
| S1.5 | What do you spend time on that you wish someone else could handle? | The routing problem made personal and specific |
| S1.6 | What decisions wait for one specific person before they can move? | Names the single-node constraint directly |
| S1.7 | What would you fix first if you had a free week and no one would push back? | Reveals what insiders already know but have stopped saying |
| S1.8 | What are your top day-to-day hassles or frustrations — the things that cause rework, waste, or disappointment? | Names the friction that insiders have normalised but customers feel |
| S1.9 | What gets in the way of you doing your best for the customer? | Separates system-caused obstacles from personal ones — the system is always the bigger story |
| S1.10 | What things help you get your work done effectively and efficiently right now? | The Bright Spots question — what is already working that the solution should preserve and scale |
S1.8–S1.10 are best asked of frontline staff in small groups. S1.10 is the Bright Spots question — the things that are working well are as diagnostic as the things that are not.
Before opening a spreadsheet, sketch the Behaviour Over Time chart first — what pattern do you expect to see? Then measure. These questions help you choose the right measure and interpret the result honestly.
| # | Question | What it reveals |
|---|---|---|
| M2.1 | What single number, if it changed, would tell us unambiguously whether this problem is getting better or worse? | Forces the outcome measure — avoids activity proxies |
| M2.2 | How far back does the data go? Is the series long enough to show the pattern rather than recent noise? | Short series can't distinguish signal from variation |
| M2.3 | Before running Bootstrap CUSUM — what pattern do we expect? Stagnation, decay, oscillation, or something else? | The pre-commitment that prevents reverse-engineering the result |
| M2.4 | If the Bootstrap CUSUM shows no change point, what does that tell us about every initiative run in this period? | The flat line is the diagnosis: the constraint has not been addressed |
| M2.5 | Are we measuring the outcome itself — or a proxy that could look good while the outcome worsens? | Distinguishes outcome measures from process measures |
| M2.6 | What would a genuine improvement look like on this chart — and by when should we expect to see it? | The pre-specified prediction that Step 7 will test |
For each significant symptom, trace the causal chain back to its root. Then ask the loop questions — why does it keep happening? The loop is why every previous fix was temporary.
| # | Question | What it reveals |
|---|---|---|
| S3.1 | If this root cause is true, does every symptom on our list necessarily follow? | The necessity test — a genuine root explains everything |
| S3.2 | If this root cause were eliminated tomorrow, which symptoms would disappear? | The removal test — if most disappear, the root is real |
| S3.3 | Is this a description of what someone does — or a description of what the system produces? | Separates behaviour from structure. If it describes a person, go deeper. |
| S3.4 | What does this problem directly produce — and what do those consequences produce? | Follow the consequence chain until it closes back on the original problem |
| S3.5 | What short-term fix relieves the pressure to address the root — and how does that fix prevent the structural fix from ever being made? | The balancing loop that maintains the system at an undesirable level |
| S3.6 | Where in the loop would an intervention break it most cleanly? | The leverage point — where the structural change needs to go |
Go through the symptom list. For each item ask S4.4. If the answer is yes — it is a consequence, not a cause. What remains in the causes column is what the structural response must address.
| # | Question | What it reveals |
|---|---|---|
| S4.1 | Would this symptom exist if the root cause did not exist? | If no — it is a consequence, not a cause |
| S4.2 | Is this a problem we could solve directly — or would solving it just create space for the same problem to refill? | Distinguishes treatable symptoms from structural outputs |
| S4.3 | Are we treating this as a cause because it is the most visible — or because it is genuinely upstream? | Names the visibility bias that makes consequences look like causes |
| S4.4 | If we fixed this tomorrow, would the root cause keep producing it? | The definitive test. If yes — it is a consequence, not a cause. |
Apply these to every proposed intervention before designing anything. If the answer to J2 is “people will try harder” — it is not a method. Go back and find the Level 3 structural change.
| # | Question | What it reveals |
|---|---|---|
| J1 | Is this intervention aimed at the system — or at an individual behaving differently? | If the latter — it is Level 1 wearing Level 3 language. Redesign it. |
| J2 | By what method will this intervention produce the improvement we are predicting? | Deming’s test. If the answer is “people will try harder” — it is not a method. |
| J3 | If we stopped this intervention tomorrow, would the problem return? | If yes — the intervention is not at the right level. |
| J4 | Could a policy decision achieve the same result? | The policy shortcut — always ask this before designing something more complex. |
| J5 | What is the prediction? What will change, by how much, within how many weeks? | Forces a testable commitment. Without it there is no method — only intention. |
| J6 | What might get worse as a result of this intervention succeeding? | The balance measure question — names the unintended consequence before it happens. |
| J7 | Does the team understand why this is happening — and have they been part of designing it? | All One Team. A correct intervention done to people fails. Done with people holds. |
Ask in sequence before designing any structural intervention. G3 — subordinate — is the most commonly skipped and often produces immediate relief at zero cost.
| # | Question | What it reveals |
|---|---|---|
| G1 | What is the single constraint limiting the throughput of the whole system right now? | Identify — the one thing that, if it moved, would move everything else |
| G2 | What already exists that we are not fully using? | Exploit — get the most from what is there before building anything new |
| G3 | What are we currently doing that feeds the constraint — and can we stop? | Subordinate — often produces immediate relief at zero cost |
| G4 | What investment would break the constraint if steps 2 and 3 are not enough? | Elevate — the structural intervention, sequenced correctly |
| G5 | Now that this constraint has moved — what is the next one? | Repeat — the constraint always moves. Find it before it finds you. |
For every pair of proposed interventions, ask S5.1 and S5.2 to build the dependency map. Then for each individually, ask S5.3–S5.5 to define the PDSA cycle.
| # | Question | What it reveals |
|---|---|---|
| S5.1 | Does this intervention require another to be working before it can succeed? | Dependency — if yes, the other one comes first |
| S5.2 | Would this intervention be undermined if a specific other one is not in place? | Fragility — names what the intervention depends on to hold |
| S5.3 | What is the smallest version of this we could test in the next four to eight weeks? | The PDSA starting point — small scale, specific prediction, defined measure |
| S5.4 | What would we expect to see if this is working — and by when? | The prediction. Written before implementation, not after. |
| S5.5 | What would we need to see to conclude it is not working — and what would we do then? | Prevents the intervention being defended regardless of evidence |
Ask before the sunk cost closes the conversation — before the investment deepens, before the relationship makes honest evaluation uncomfortable.
| # | Question | What it reveals |
|---|---|---|
| L1 | Can we identify at least three other organisations with the same need who did not ask us to build this? | Whether the need is general or specific to this user |
| L2 | What job does the mainstream market think it is hiring us to do — and is that the same job this lead user has? | The jobs mismatch test. Different jobs means no market at scale. |
| L3 | What would the mainstream buyer need to stop doing, start doing, or pay for that they currently do not? | The switching cost. If large — adoption will be slow regardless of product quality. |
| L4 | If we showed this to ten prospects who had never heard of us, how many would immediately understand the value? | The comprehension test. Fewer than half means the job framing is wrong. |
| L5 | What is the smallest version of this we could test with a new customer — not the lead user — within ninety days? | Forces a market test rather than a development continuation |
| L6 | What would we need to see from that test to justify scaling the investment? | The prediction. Written before the test. If no answer — there is no method, only hope. |
You will have more possible solutions than capacity to implement them. These questions help score each initiative honestly and make the Kill decisions defensible.
| # | Question | What it reveals |
|---|---|---|
| P6.1 | If this initiative succeeds, what specifically changes in the outcome measure — and by how much? | Forces an impact estimate. Vague impact = low confidence = lower PICK score. |
| P6.2 | What is the total effort required — including the hidden costs of distraction, coordination, and maintenance? | Real effort is almost always higher than estimated. Overestimate deliberately. |
| P6.3 | If we stopped this initiative tomorrow, what capacity would be released — and what would we do with it? | Makes the opportunity cost of continuing explicit |
| P6.4 | Does this initiative address the constraint — or a non-constraint? What evidence supports that? | Improving a non-constraint does not improve system throughput. Verify this first. |
| P6.5 | Has this initiative been running for more than six months without a Bootstrap CUSUM change point? If so — is it working or are we persisting? | The sunk cost test applied to the portfolio |
| P6.6 | For Challenge items: what is the first stage — the smallest version that delivers real value and can be tested within eight weeks? | Converts an intimidating large project into a manageable PDSA cycle |
The most important questions on this page. A PDSA without a pre-specified prediction is not a PDSA — it is an action with a description attached afterwards. Write the prediction before you start.
| # | Question | What it reveals |
|---|---|---|
| S7.1 | What specifically do we predict will change — in which measure — by which date? | The Plan. Written now, not after the results are in. |
| S7.2 | What Bootstrap CUSUM change point are we looking for — upward or downward, on which series, within how many periods? | Makes the prediction statistical and testable rather than impressionistic |
| S7.3 | What would constitute a clear failure — and what would we do if we saw it? | The study question. Without a failure criterion, every result confirms the hypothesis. |
| S7.4 | At what confidence level will we accept the Bootstrap CUSUM result as confirmation? | 95% for routine monitoring; 99.7% before committing to irreversible action |
| S7.5 | If the change point appears — what does the Act step look like? Scale, modify, or stop? | The decision rule, written before the result, not after |
| S7.6 | If the change point does not appear within the predicted time — what does that tell us about the hypothesis? | The flat line is information. It means the constraint was not what we thought. |
Questions that cut across everything
Ask early. Hold the silence.These are not stage-specific. They unlock the whole conversation. The answer is always already there — the question creates permission to say it out loud.
| # | Question | Why it matters |
|---|---|---|
| D1 | Describe your perfect Tuesday. | Reveals the gap between what the role should be and what it actually is |
| D2 | How much of your actual Tuesday do you spend on those things? | Makes the gap numerical. Removes the ability to say it is not that bad. |
| D3 | What on this list requires you specifically — and what is here because the system routes it to you? | Separates the irreplaceable from the structural default |
| D4 | If the system were designed differently, what would it do instead of routing this to you? | Moves from diagnosis to structural imagination |
| D5 | How long has that been the case? | Names the duration of the constraint. Makes visible what has been normalised. |
| D6 | What would need to be true for that to change? | The structural design question. Opens the conversation about what must be built. |
| D7 | Is this a problem of effort — or a problem of design? | Separates the Level 1 response from the Level 3 one |
| H1 | What are the top hassles or frustrations in your day-to-day work — things that cause rework, waste, or disappointment for you or your customers? | Surfaces friction the system produces that insiders have stopped noticing |
| H2 | What gets in the way of you doing your best for the customer? | Makes the system-caused obstacle visible and separable from personal effort |
| H3 | What things help you get your work done effectively and efficiently right now? | The Bright Spots question — preserves what is working before redesigning what is not |
Ask the right questions, in the right order, with someone who has the distance to ask them before the answers become too uncomfortable to act on — and you will find the root cause, understand why it keeps recurring, design the structural response at the right depth, and sequence the interventions so that each one creates the conditions the next one requires.