Put It All Together: One Problem End to End

You now have all four moves of the method: define the problem, trace it to a root cause, see it as a system, and map that system with a boundary. Up to now you have practiced each move on its own. This last chapter runs all four, in order, on a single everyday problem, so you can see how each move feeds the next and hands you exactly what the following one needs. This is the same run you can do yourself on any problem, so read it as a model you can copy step by step.

Run the Whole Method on One Problem

Here is our everyday problem. A residents’ association uses one big group chat for everything: notices, questions, chit-chat, photos, the lot. Lately it has become so noisy that people have stopped reading it closely, and genuinely important messages slip past unseen. We will take it from a vague grumble all the way to a mapped system with a boundary.

Start With the Felt Frustration

Someone in the association says: “The group chat is a nightmare, nobody reads anything important anymore.” That is a real feeling, but it is a complaint, not yet a problem. Nothing in it is observable or bounded, so there is nothing to work on. Our first job is to fix that.

Turn the Frustration into a Defined Problem

Bring back the two tests from Chapter 1: could someone else watch it happen? (observable) and do you know what’s in and what’s out? (bounded).

Make it observable. What could you actually watch? A notice about a scheduled water shut-off is posted, and hours later most residents still ask when the water is going off, because the notice has scrolled out of sight under dozens of unrelated messages. People visibly miss things and ask questions already answered. That is observable.

Give it an edge. In scope: the single association group chat, its resident members, and the people who post official notices. Out of scope: residents’ private chats, the paper noticeboard downstairs, and the monthly email. Now the problem has a clear edge.

Write the four-part statement:

Residents and the association’s notice-posters experience important messages going unread when urgent notices get buried under a high volume of chit-chat in the single group chat; in scope: the association group chat, its resident members, and the people who post notices; out of scope: private chats, the paper noticeboard, and the email newsletter; a good response must get urgent notices reliably seen without silencing ordinary conversation.

That statement passes both tests, names its stakeholders, and says what success looks like. Only now is there something worth tracing.

Trace It to a Root Cause

Take the symptom, important messages go unread, and run the 5 Whys, following the branches.

• Why do important messages go unread? Because they scroll out of sight fast, and many people have muted the chat.

• Why has that happened? Two honest branches:

  • Branch A: because the volume of unimportant messages is high, so anything urgent is quickly buried.

  • Branch B: because nothing marks a message as official or urgent, so a shut-off notice looks exactly like a meme.

• Branch A, why is the volume so high? Because there is one channel for everything, with no separation between urgent and trivial. Root cause: a single undifferentiated channel mixes the urgent with the trivial.

• Branch B, why is nothing marked urgent? Because the group never agreed on a way to flag a message as important. Root cause: there is no shared signal for “this one matters.”

Sort the causes. Both are in reach: residents could agree to split the chat into channels, and could adopt a simple flag for urgent posts. What stays out of reach is each member’s own phone notification settings, which no one else controls. Notice that both root causes are about how the parts connect, not about any one person, which is the hint that we are looking at a system.

Map the System and Set Its Boundary

Now draw it, following the four steps from Chapter 4.

List the parts. Stakeholders: the residents and the notice-posters. Inputs: the messages themselves (urgent and trivial) and each member’s limited attention. Steps: someone posts, others scroll, they read or skip, and some eventually mute. Output: whether urgent notices actually get seen.

Draw the arrows and mark the loop. High chit-chat volume pushes notices out of sight, so residents mute or skim, so fewer people read anything, so posters repeat notices and residents re-ask answered questions, which adds even more volume. That circles back on itself, so it is a reinforcing loop: noise leads to muting leads to missed notices leads to more reposting and more noise.

Set the boundary. Inside: the group chat, its residents and posters, the message volume, and the muting behavior. Outside: each phone’s notification system, residents’ private chats, and the paper noticeboard. The line sits just past the in-reach causes, channel design and flagging, and leaves the phone settings outside as context.

Name one second-order effect. Suppose the fix is a strict announcements-only channel where replies are switched off. Urgent notices get seen, which is the goal, but the friendly chit-chat that made people feel like a community now has nowhere to live, and a few residents feel the association has gone cold. Solving the noise could quietly weaken the sense of belonging, a knock-on worth watching.

See how each move handed the next what it needed. Defining the scope told us which messages counted. The root cause, one undifferentiated channel, reappeared as the reinforcing loop on the map. And the boundary wrapped neatly around the causes we can actually act on. That chain, frustration to statement to cause to map, is the whole method, and it is exactly what you will run yourself next.

Your Turn!

Now run a mini version of the whole method on a fresh case.

Scenario. Five neighbors share one car, booked on a sheet pinned up in the hallway. Lately the car is often not ready when someone needs it: the tank is near empty, the inside is a mess, or it turns out someone else already took it. A couple of neighbors have started falling back on taxis instead.

Your task. 1. Turn the grumble into a four-part problem statement that passes the observable and bounded tests. 2. Run a short 5 Whys to at least one root cause, and mark it in reach or out of reach. 3. Sketch the system: its stakeholders, inputs, steps, and outputs; mark one feedback loop and say whether it is reinforcing or balancing; then draw a boundary around the parts you would treat as inside.

Do this in your own working document, and think it through yourself. Running the whole method start to finish is the exact skill this course has been building, so resist the urge to hand it to an AI tool to do for you. This is excellent rehearsal for running these same moves on any problem you choose.

Let’s Recap!

• The four moves form one method: define the problem, trace it to a root cause, see it as a system, and map that system with a boundary.

• Each move hands the next what it needs: the scope decides what counts, the root cause reappears as a loop, and the boundary wraps the causes you can act on.

• A defined problem always beats a grumble, because only an observable, bounded statement gives you something to trace.

• Root causes almost always live in how the parts connect, which is why they resurface on the system map.

• You are now ready to run the whole method yourself on a problem you choose, from a defined problem to a root-cause analysis to a system map.

Model Solution

Here is one strong run of the method on the shared-car case. Yours does not need to match it word for word; it needs to pass the same tests and reach a real cause and loop.

Four-part problem statement.

Neighbors who share the car experience the car being unavailable or not ready to drive when they need it, because there is no reliable way to book it or hand it back in good shape; in scope: the shared car, the booking sheet, and the neighbors who use it; out of scope: fuel prices, insurance, and each neighbor’s own separate transport; a good response must keep the car reliably available and ready to drive without depending on any single person to police it.

5 Whys to a root cause. The car is not ready to drive, so why? It often comes back with an empty tank or a mess inside. Why does it come back that way? Whoever used it last did not refuel or tidy it. Why not? Nothing says they have to, and no one checks. Why is there no such habit? The group never agreed on how the car should be handed back. Root cause: there is no agreed hand-back routine, which is in reach for the neighbors to change. Fuel prices and everyone’s schedules are out of reach; only the hand-back habit is not.

System sketch.

• Stakeholders: the neighbors who share the car.

• Inputs: the car, fuel, time, and the booking sheet.

• Steps: check the sheet, book a slot, use the car, then hand it back fueled and tidy, or not.

• Output: whether the car is available and ready to drive when someone needs it.

• Feedback loop: the car comes back not reset, empty or messy, so the next person is rushed and annoyed and skips resetting it too, so it is even less likely to be ready next time, so more people hand it back neglected. Reinforcing, because neglect feeds more neglect.

• Boundary: inside are the car, the neighbors, the booking sheet, and the hand-back behavior; outside sit fuel prices, insurance, and each person’s own transport, noted as context but not something the group can move.

Compare that with the bare grumble, “the car’s never ready and nobody bothers.” It names no clear problem, no cause, and no loop. The full run tells you exactly what to change: the missing hand-back routine that keeps the reinforcing loop spinning.