Analogy

Forced Analogy (Structural Transplant)

What this technique does

Take the problem, strip it down to its bare structure — who the actors are, what flows between them, where it jams — and find a system in a distant domain that has the same shape. An immune system, an air-traffic control tower, a restaurant kitchen at dinner rush. Then ask what that system does about the jam that you don't, and carry the mechanism back as a concrete idea. The point is distance: the further the source domain sits from your problem, the more its solutions will look nothing like the ones already on your whiteboard.

Source: Synectics (William J.J. Gordon, Synectics: The Development of Creative Capacity, 1961), specifically the "direct analogy" operation; widely used in biomimicry and TRIZ-adjacent practice.

Workflow

Step 1: Confirm the target

A valid target is a concrete creative or design problem: how to grow something, how to route something, how to redesign a process or a system. If it is unclear, ask one focused question — "What's the system you're trying to reshape, and where does it jam?"

Refuse requests to perform analytical work — debugging, reviewing code, implementing a change — and suggest an analytical approach instead. Redesigning or ideating about such a process is a valid creative target: "reinvent our code-review ritual" is in scope; "review this PR" is not.

Step 2: State the problem's structure in one sentence

Reduce the target to actors, flows, and the bottleneck. No domain vocabulary, no solution language — just the shape. For example: "many independent producers, one congested channel, quality varies." This sentence is the load-bearing part of the whole technique; if it still names your industry, it is not abstract enough yet.

Step 3: Draw 3-5 domains whose structure rhymes

Pull from references/domain-pool.md. Choose domains whose structural property matches the sentence from Step 2, not domains that sound related to your problem. Mix at least one biological, one operational, and one social/cultural so the transplants come from genuinely different logics. Never run more than five in a batch.

Step 4: Per domain, map roles then transfer a mechanism

For each domain, do two things in order:

1. Map the roles. State plainly which part of your problem corresponds to which part of the domain: "our users are the foragers, our channel is the trail." If the mapping is clean, one line does it.
2. Ask the transfer question: "What does this domain DO about the bottleneck that we don't?" Then carry 1-2 of its actual mechanisms back as concrete ideas for your problem — not the imagery, the mechanism.

Step 5: Meta-pattern scan

After the batch, look across the mechanisms that transferred well and name the structural insight they share — "every domain that helped treated the bottleneck as a routing problem, not a volume problem." State it explicitly. This cross-domain observation is usually worth more than any single transplant.

Step 6: Honest ranking, no closure pressure

Pick the sharpest transplants. Say which are weak and why. Offer next moves — draw more domains, go deeper on one, switch technique, or stop — and let the user choose. Never push the user to commit.