How to Build a Conversation Tree for Research and Decisions

A conversation tree starts with a stable trunk (the question, constraints, and sources), then forks named branches for each live option or sub-question. You compare branches against criteria you wrote down early, prune the weak paths, and finish with a short decision record. The chats are scaffolding. The record is the work product.

You can build this in ChatGPT with branching, in Claude with edit/regenerate forks, in a plain doc with headings, or on a canvas where each chat sits as a node. The method transfers. The tool is secondary.

Trunk first: freeze the question and constraints

Most messy AI research fails before the first clever prompt. The question was soft, so every answer felt vaguely useful and nothing could be rejected.

Write the trunk in plain language:

Decision or deliverable: "Choose a pricing shape for the pro plan" or "Recommend whether we respond to Competitor X's feature launch."
Constraints: budget, timeline, non-goals, audience, must-keep promises.
Sources in play: links, PDFs, notes, prior decisions. Name them. Do not assume the model will "remember the vibe."
Kill criteria: what would make an option dead on arrival (for example, "requires a sales team we do not have").

Paste that trunk into the top of the main chat or the top of your doc. Everything else branches from here.

If you cannot write kill criteria yet, you are still in problem-framing. Stay on the trunk until you can.

When to branch (and when not to)

Branch when a path would pollute the trunk or destroy a sibling you still need:

Two or more options that must stay comparable.
A deep side investigation (one paper, one customer segment, one technical risk).
A tone or structure experiment on a draft you might still want.
A disagreement between sources that deserves its own workspace.

Do not branch for tiny wording tweaks. That creates fake complexity. Edit in place when the intent is "improve this same path."

A practical rule: if you would have opened a new tab in the old world, you probably want a named branch in this world.

Naming branches so you can compare them later

Default titles are how projects die.

Name branches like files you will reopen in a week:

pricing/usage-based
pricing/seat-flat
risk/switching-cost-objections
source/acme-report-2025-claims
draft/memo-skeptical-tone

Include the job in the name, not a vibe ("interesting idea 3"). When you compare, you should be able to line up three tabs or three headings and know what each one argued.

Cap live branches. Three to five is plenty for most decisions. Parking lots exist for a reason: move cold ideas to a list instead of keeping ten half-alive chats.

Worked example: pricing decision tree

Trunk setup

Trunk text you might paste:

Decision: pick a packaging direction for Pro for the next quarter.
Constraints: no enterprise sales motion yet; must be explainable on a pricing page in one screen; churn from confusion is worse than leaving money on the table.
Kill criteria: any option that requires custom quotes for every deal; any option that breaks existing annual contracts this month.
Sources: last 12 lost-deal notes, three competitor pricing pages, current plan mix.

Three forks

From the trunk, create three branches:

pricing/usage-based: Prompt: propose a usage metric, expected buyer reaction, failure modes, and a one-paragraph pricing page draft.
pricing/seat-flat: Same prompt shape, different packaging.
pricing/hybrid-with-cap: Same prompt shape again.

Keep the evaluation criteria identical across forks. If you change the rubric midstream, you are no longer comparing.

Compare and prune

Score lightly. You do not need a fake 40-point rubric. Four questions are enough:

Does it violate kill criteria?
Can we explain it in one screen?
What does lost-deal evidence say?
What breaks first if we are wrong?

Prune in writing: "Killed usage-based because lost-deal notes show buyers feared bill shock and we have no CS capacity to explain invoices." That sentence is gold later when someone reopens the debate.

Promote the winner into a decision record. Archive or clearly mark the losers.

Worked example: research memo tree

Trunk: "Should we enter Segment Y this half?"

Branches might be:

segment-y/demand-evidence
segment-y/competitive-intensity
segment-y/delivery-cost
segment-y/counterargument-steelman

Each branch answers its question with claims tied to sources. The memo draft lives on the trunk (or a final deliverable/memo branch) and only pulls claims that survived comparison.

If two sources conflict, do not average them in one paragraph. Give the conflict its own short branch, then decide how the memo will treat it (weight A, weight B, or "unknown").

Tool-agnostic tactics

ChatGPT (and similar "branch in new chat" UIs). Fork at the message where paths diverge. Rename immediately. Keep the original as the trunk or as the baseline draft.

Claude-style edit/regenerate trees. Edits and regenerates can keep prior variants. Use that for sibling answers to one prompt. For larger forks (different strategy entirely), start a clearly named parallel chat from shared trunk text.

Docs. Headings are branches. A table of options works. The doc becomes the system of record; chats feed it.

Spatial canvas / chat whiteboard. Useful when you need many chats and source nodes visible at once. Same method: trunk in the center or top, named branches outward, decision record as the artifact you export.

Whatever you use, promote insights out of the disposable layer. Threads rot. Records travel.

Common mistakes

Branching every tweak. You will recreate tab chaos with prettier vocabulary.

No kill criteria. Without them, every branch "has potential," which means nothing dies and nothing ships.

Never writing the decision down. A beautiful tree that ends without a dated choice is procrastination with diagrams.

Secret rubric changes. If Branch B was judged on revenue upside and Branch A on implementation risk, you did not compare options. You compared moods.

Letting the model own the structure. Models are happy to ramble across options inside one answer. That feels like a tree. It is still one blob. You own the forks.

Checklist

Trunk states decision, constraints, sources, kill criteria
Each live branch has a job-style name
Live branches capped (about 3–5)
Comparison criteria identical across forks
Losers pruned with a written reason
Winner promoted into a short decision record (question, options, choice, why not others, date)

Run this once on a real decision this week. The first tree will feel slightly formal. The second one will feel like relief.