Evolution pattern

Walk the previous tree node by node at the start of a new cycle.

Purpose

Bring an existing tree up to date before anything new is added to it. The group walks every problem of the previous version and gives each one a verdict: still true, changed, or resolved.

The walkthrough surfaces which nodes persisted, got resolved, and shifted. The difference between old and new versions says as much as either version does. See a living document.

When to use it

At the start of a new planning cycle, when a tree from the previous cycle comes back.
At the start of any session that updates an existing tree. See evolving the tree.
Before a consequential decision that the tree should inform, when the tree has not been looked at for months.

Timing

The time depends on the number of problems in the tree. Keep each one short: the group gives a verdict, not a discussion. A tree with 15 problems can take about 20 to 30 minutes to walk through.

Steps

Save a copy of the tree, labeled with its date or planning cycle. From here on, the group edits the current version only.
Show the tree as it was saved. Give the group 1 or 2 minutes to read it in silence.
State the rule.

We'll go through every problem and ask one question: still true, changed, or resolved? New nodes wait until we're done. Write them down so you don't lose them.
Walk the problems one at a time, cluster by cluster. For each one, ask:

Still true, changed, or resolved?

Apply the verdict on the board right away.

Verdict	Meaning	What happens on the board
Still true	The problem is as the node says	The node stays
Changed	The problem is still there, in a different form	The node is reworded and/or its arrows are redrawn
Resolved	The problem is gone	The node is deleted along with any node that existed only for it

Mark any problem the group cannot agree on within a minute, and come back to it after the walk.
Read the result back: how many problems persisted, how many changed, and how many were resolved. Then open the board to new nodes.

Tips

A verdict rests on evidence such as a number, a recent case, or the word of someone who lives with the problem. "It feels better" is a reason to ask again.
A problem that is still true for a second or third cycle is telling the group something. It may be deeper than it looks, or the actions aimed at it so far may not be working.
Participants think of new problems during the walk. They write each one on a sticky note and hold it separated from the tree under review until the walk is done.

Traps

Adding before the walk is done. New nodes take all the attention, and the walk never finishes. Stale nodes then stay in the tree for another cycle.
Calling a problem resolved because its action is finished. The question is whether the problem is still true, not whether the work was done. A finished action with a surviving problem is a finding.
Marking a problem "done" and leaving it. The tree describes the present. A resolved problem is deleted, and it belongs the saved old version.
Keeping a node just in case. If nobody can say that a problem is still true, it is not. Resolved problems tend to linger unless removal is deliberate.

Variations

Outcomes and actions too. Walk the desired state / outcome nodes ("Still wanted? Reached?") and the action / intervention nodes ("Finished, under way, or dropped?").
In subgroups. For a large tree, give each subgroup one cluster to walk. Each one reports its verdicts to the full group, which confirms them.
Verdicts as hypotheses. The owner of the tree may mark a verdict on each problem before the session. The group confirms or corrects them, as it does with pre-seeded nodes.

Example

The renewals tree came back at quarterly planning in December, 3 months after the session that built it. The facilitator saved a copy, labeled "Renewals tree, September 2025," and walked the 14 problems with the same 12 leads. The diagram follows the walk through the support and deals corner.

Step 1 of 4. The September tree comes back in December. A copy is saved first, and nothing new is added yet.

Step 2 of 4. Tier 1 support cannot see a customer's setup: resolved. Tier 1 has had read-only access since October. The problem and its finished action leave the tree.

Step 3 of 4. Most tickets are escalated to engineering: changed. Escalations fell by half, and what remains is custom code. The node is reworded.

Step 4 of 4. Sales promises custom features to close deals: still true, for a second cycle. Only after the walk does the group add what is new: large deals skip the deal desk.

Diagram as text: The evolution pattern on the renewals tree

Steps:

Step 1: The September tree comes back in December. A copy is saved first, and nothing new is added yet.
Step 2: Tier 1 support cannot see a customer's setup: resolved. Tier 1 has had read-only access since October. The problem and its finished action leave the tree. Changes: removed "Tier 1 support cannot see a customer's setup", "Give tier 1 read-only access to the admin tool". arrows removed: "Tier 1 support cannot see a customer's setup" influences "Most tickets are escalated to engineering"; "Tier 1 support cannot see a customer's setup" influences "Give tier 1 read-only access to the admin tool"; "Give tier 1 read-only access to the admin tool" influences "Write runbooks for the 20 most common tickets".
Step 3: Most tickets are escalated to engineering: changed. Escalations fell by half, and what remains is custom code. The node is reworded. Changes: "Most tickets are escalated to engineering" now reads "Tickets about custom code are escalated to engineering".
Step 4: Sales promises custom features to close deals: still true, for a second cycle. Only after the walk does the group add what is new: large deals skip the deal desk. Changes: added "Large deals skip the deal desk". new arrows: "Large deals skip the deal desk" blocks "Deals close on the standard product".

After the last step:

Nodes:

Root / Problem: "Sales promises custom features to close deals"
Root / Problem: "Large customers run custom code paths"
Root / Problem: "Tickets about custom code are escalated to engineering"
Root / Problem: "Large deals skip the deal desk"
Action / Intervention: "Route custom requests through a deal desk"
Action / Intervention: "Write runbooks for the 20 most common tickets"
Desired State / Outcome: "Tier 1 resolves 7 in 10 tickets on its own"
Desired State / Outcome: "Deals close on the standard product"

Arrows:

"Sales promises custom features to close deals" influences "Large customers run custom code paths"
"Large customers run custom code paths" influences "Tickets about custom code are escalated to engineering"
"Tickets about custom code are escalated to engineering" influences "Write runbooks for the 20 most common tickets"
"Write runbooks for the 20 most common tickets" influences "Tier 1 resolves 7 in 10 tickets on its own"
"Sales promises custom features to close deals" influences "Route custom requests through a deal desk"
"Route custom requests through a deal desk" influences "Deals close on the standard product"
"Large deals skip the deal desk" blocks "Deals close on the standard product"

Of the 14 problems, 3 were resolved, 1 had changed, and 10 were still true. The walk took 25 minutes.

Each resolved problem had a small, specific action aimed at it. The problems that persisted were the deep ones. "Sales promises custom features to close deals" was still true although its action, the deal desk, was up and running. The first new node of the review explained why: large deals skip the deal desk.