What is a decision tree?

A decision tree is a branching diagram that breaks one decision into a sequence of yes-or-no questions, with every path ending in an outcome. The decision sits at the top, each question splits the remaining options in two, and the leaves are the actions you'd actually take. Decision analysis, finance and customer support all lean on the same structure.

How do you make a decision tree?

Start with the decision at the top, written as the choice you're making. Add the question that eliminates the most options first, then branch it Yes and No. Keep splitting until every path reaches an action rather than another opinion. Then test it: take a case you already decided, walk it down, and see whether the tree agrees with you.

What are some real decision tree examples?

Loan approval is the classic one: credit score above a threshold, then employment history, then approve or decline. Support teams triage a ticket the same way, asking whether it's a bug and whether it's blocking before escalating or queueing it. Product teams use one to decide whether to build something, checking the quarter's goal, the success metric, then team dependencies.

Is a decision tree the same as the machine learning model?

They share a name and a shape, not a job. The diagram here is drawn by hand to make a human decision explicit, with questions you choose and outcomes you write. A machine learning decision tree is fitted from data by an algorithm that splits on whichever feature separates the classes best, and it exists to predict rather than to explain a choice you're facing.

How many branches should a decision tree have?

Fewer than feels natural. Three or four questions deep is usually plenty, and past that most of the paths never get walked. If you need more depth, that's often a sign two separate decisions have got tangled together and belong in their own trees. Every question you add doubles the number of paths a reader has to hold.

TemplatesFlowchartsDecision Tree

Decision Tree

A decision tree breaks one decision into a chain of yes-or-no questions, with each branch ending in an action you can take. This template gives you a blank structure to fill in and a worked example beside it, plus a legend showing which shape means a question and which means an outcome. Product teams, support leads and anyone stuck between options use it to make the reasoning visible.

Use this template

A blank branching structure, a worked product example, and a legend for the three node shapes.

What's included

A blank branching structure. A pill for the decision, two levels of yes/no diamonds and four outcome boxes, all ready to relabel.
A worked product example. The full should-we-build-this tree, from the first goal check down to Build it, so you can see a finished one.
Labelled branches. Every connector carries its Yes or No, so anyone can follow a path without guessing which way is which.
Colour-coded outcomes. Green for go, orange for do-something-first, grey for park it, so the endings read at a glance.
A shape legend. Pill for the decision, diamond for a question, rectangle for an outcome, kept on the board for readers.

Why use a decision tree?

Makes the reasoning reviewable. The path from question to outcome sits on the board, so someone who wasn't in the room can see why the answer came out the way it did.
Stops the same debate recurring. Once the tree exists, the next case gets walked down it instead of argued from scratch.
Catches the branch nobody planned for. Drawing every No forces you to say what happens in the cases people usually skip over.
Turns a judgement call into a rule others can run. Support and ops teams hand the tree to someone new and get the same decision back.
Shows where the real uncertainty sits. If one question is doing all the work, the shape of the tree makes that obvious and you know what to go and find out.

How to use this template

Write the decision at the top. One sentence, phrased as the thing you're actually choosing rather than the topic area.
Ask the question that splits widest first. The one that rules out the most options belongs at the top, not the most interesting one.
Answer every branch. A diamond with only a Yes leaving it isn't finished. The No has to land somewhere too.
Stop at an action. A leaf reading consider the options isn't an outcome. Park it until next quarter is.
Walk a real case down it. Take something you decided last month and check the tree gives the answer you actually went with.
Share the board. Send the link so the people who'll use the tree can argue with it before it's in play.

Open the decision tree in Whimsical

Decision tree vs flowchart

Both are branching diagrams, and they answer different questions. A flowchart documents a process: the sequence of steps that turns an input into an output, loops and all. A decision tree maps a single choice, so each branch is a yes or no and every path ends in an outcome rather than rejoining the flow. Draw a flowchart when you're describing how work moves. Draw a decision tree when you're choosing between options.

Frequently asked questions

A decision tree is a branching diagram that breaks one decision into a sequence of yes-or-no questions, with every path ending in an outcome. The decision sits at the top, each question splits the remaining options in two, and the leaves are the actions you'd actually take. Decision analysis, finance and customer support all lean on the same structure.
Start with the decision at the top, written as the choice you're making. Add the question that eliminates the most options first, then branch it Yes and No. Keep splitting until every path reaches an action rather than another opinion. Then test it: take a case you already decided, walk it down, and see whether the tree agrees with you.
Loan approval is the classic one: credit score above a threshold, then employment history, then approve or decline. Support teams triage a ticket the same way, asking whether it's a bug and whether it's blocking before escalating or queueing it. Product teams use one to decide whether to build something, checking the quarter's goal, the success metric, then team dependencies.

They share a name and a shape, not a job. The diagram here is drawn by hand to make a human decision explicit, with questions you choose and outcomes you write. A machine learning decision tree is fitted from data by an algorithm that splits on whichever feature separates the classes best, and it exists to predict rather than to explain a choice you're facing.
Fewer than feels natural. Three or four questions deep is usually plenty, and past that most of the paths never get walked. If you need more depth, that's often a sign two separate decisions have got tangled together and belong in their own trees. Every question you add doubles the number of paths a reader has to hold.