Zoom pattern
Treat a single node as its own tree.
Purpose
See what is inside one node. A node that looks like a single problem in the full tree is often several problems written on one sticky note. Taken out of the tree and treated as a tree of its own, it shows the detail the group needs before it can act.
When to use it
- During Decompose, to start each deep dive.
- In a deep-dive session, as the opening question.
- When a top-voted node has many arrows going out and none coming in.
- When 2 participants read the same node differently. Zooming in usually shows that each of them has a different part of it in mind.
Timing
A quick sketch, 1 or 2 levels deep, takes 15 to 20 minutes. Going deeper takes the full time of Decompose, or a session of its own. See the time budget in running a deep-dive session.
Steps
-
Take the node out of context. Copy it to an empty area of the board, give it a double border, and head the area "Deep Dive:" followed by the node's name. The original stays where it is.
-
Ask the zoom question.
If this node were its own tree, what would be at the roots? What problems live inside this one? What does solving this fully require?
-
Add the answers as new nodes around it. A node stays white when its type is in doubt.
-
Connect the new nodes to the node from the full tree, and to each other.
-
Check the new nodes against the full tree. When one of them already exists there, use the same wording, so the 2 views agree.
-
Stop when the group understands the node well enough to act on it. Link the deep dive to its node in the full tree. See the deep-dive sub-tree.
Tips
- Hide the rest of the tree. Move to a separate wall, or zoom the digital board until only the new area shows. With the full tree in view, the group redraws the arrows it already has.
- Expect more than one problem. If the zoom finds a single cause, ask once more: "What else is in here?"
- Ask the people closest to the node. The parts of a problem are visible to those who live inside it. Put them in the subgroup.
Traps
- Zooming into every node. Most nodes never need a deep dive. Choose the few where understanding is weakest and the stakes are highest.
- Replacing the node. The deep dive explains a node of the full tree. The node stays in the full tree, with a link to its deep dive.
- Planning inside the deep dive. Owners and dates belong after the session. Stop at understanding.
Variations
- An action or an artifact. Zoom into an action / intervention by asking what it involves: its parts, its requirements, or the decision behind it.
- A vague node, during Connect. When an arrow is disputed because people read a node differently, ask the zoom question for 2 minutes. Split the node into the parts the group names, and connect those.
- On your own. One person may zoom into a node before a deep-dive session. The result is a seed list for the session, offered as hypotheses.
Example
In the full renewals tree, "Sales promises custom features to close deals" is a root: 7 votes, 3 arrows going out, and none coming in. During Decompose, the sales and product subgroup took it to an empty corner of the board and asked what would be at its roots.
Step 1 of 3. In the full tree, 'Sales promises custom features to close deals' is one node with 3 arrows going out.
Step 2 of 3. Taken out of context, it becomes the entry point of its own tree.
Step 3 of 3. Inside it are 4 problems, and an artifact that attacks one of them.
Diagram as text: The zoom pattern on the renewals board
Steps:
- Step 1: In the full tree, 'Sales promises custom features to close deals' is one node with 3 arrows going out.
- Step 2: Taken out of context, it becomes the entry point of its own tree. Changes: removed "Large customers run custom code paths", "The roadmap is reshuffled for every big deal", "Route custom requests through a deal desk". arrows removed: "Sales promises custom features to close deals" influences "Large customers run custom code paths"; "Sales promises custom features to close deals" influences "The roadmap is reshuffled for every big deal"; "Sales promises custom features to close deals" influences "Route custom requests through a deal desk".
- Step 3: Inside it are 4 problems, and an artifact that attacks one of them. Changes: added "Sales is paid on signed deals, not on renewals", "Competitors demo features we lack", "Product never says no in deal reviews", "Nobody can say what the product already does", "Catalog of what each setting can do", "Route custom requests through a deal desk", "Deals close on the standard product". new arrows: "Sales is paid on signed deals, not on renewals" influences "Sales promises custom features to close deals"; "Competitors demo features we lack" influences "Sales promises custom features to close deals"; "Product never says no in deal reviews" influences "Sales promises custom features to close deals"; "Nobody can say what the product already does" influences "Sales promises custom features to close deals"; "Catalog of what each setting can do" attacks "Nobody can say what the product already does"; "Product never says no in deal reviews" influences "Route custom requests through a deal desk"; "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"; "Catalog of what each setting can do" influences "Deals close on the standard product".
After the last step:
Nodes:
- Root / Problem: "Sales is paid on signed deals, not on renewals"
- Root / Problem: "Competitors demo features we lack"
- Root / Problem: "Product never says no in deal reviews"
- Root / Problem: "Nobody can say what the product already does"
- Root / Problem: "Sales promises custom features to close deals" (node from the full tree)
- Action / Intervention: "Route custom requests through a deal desk"
- Desired State / Outcome: "Deals close on the standard product"
- Artifact / Deliverable: "Catalog of what each setting can do"
Arrows:
- "Sales is paid on signed deals, not on renewals" influences "Sales promises custom features to close deals"
- "Competitors demo features we lack" influences "Sales promises custom features to close deals"
- "Product never says no in deal reviews" influences "Sales promises custom features to close deals"
- "Nobody can say what the product already does" influences "Sales promises custom features to close deals"
- "Catalog of what each setting can do" attacks "Nobody can say what the product already does"
- "Product never says no in deal reviews" influences "Route custom requests through a deal desk"
- "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"
- "Catalog of what each setting can do" influences "Deals close on the standard product"
Four problems were inside of it. Sales is paid on signed deals, not on renewals. Competitors demo features the product lacks. Product never says no in deal reviews, a problem that one of the product leads named. And nobody can say what the product already does, so a custom feature is promised where a setting would do.
The last one changed what the subgroup thought it was solving. Part of what looked like a sales problem was a missing artifact: a catalog of what each setting can do.
The node stayed in the full tree, unchanged, with a note: "See Deep Dive: Sales promises custom features to close deals."