Mind map for a startup idea

State the idea in one sentence

Write the idea as one sentence: who it is for, what problem it removes, what it is, and how it differs from what they use today. Put that sentence in the root node, then make the four parts children of it, so each part can be examined on its own. Rename the nodes as the wording changes with Enter or F2.

Keep the sentence somewhere you can argue with it. The mind map maker starts a map in the browser with no account, and a blank map with one root node is the right start here: a template would hand you the structure of a business that already exists rather than the one you are trying to test.

• One sentence: customer, problem, approach, difference
• The four parts become child nodes you can examine separately
• Rename freely as the idea changes, and keep the old wording in a note
• No template here; the shape comes from your idea, not the other way round

List what you assume to be true

An assumption is a statement that must hold for the idea to work, and it has to be written so that it can be proved false. "People want this" cannot fail, so it proves nothing. "At least two hundred discharge coordinators will pay thirty dollars a month for a discharge checklist" can fail, and now it is worth a fortnight of your attention.

Put each one on its own node, in plain words rather than pitch words, because a sentence that would look good on a slide is a slogan, and a slogan cannot be tested or priced.

Cross-link each assumption to the part of the idea it supports, so the map shows which parts of your sentence collapse when an assumption fails. The link appears as a tube between the nodes and cannot be labeled, so write the dependency in the note of the assumption, for example "if this is false, the pricing is wrong". The cross-links guide covers how the tubes behave.

• Every assumption is a statement that can come out false
• One node per assumption, in plain words
• Cross-linked to the part of the idea that depends on it
• A slogan is not an assumption, however good it sounds

Attach evidence to each assumption

The rich note is where the evidence lives, and a single note holds up to 80,000 characters, which is plenty for a quote, a number and a date. Use a bulleted list with one line per piece of evidence and where it came from, and rank what you find: a behavior you can watch beats an opinion, and an opinion beats a belief.

When the evidence is a picture, keep it on the node. A node image takes PNG, JPEG, WebP or GIF files up to 1.5 MB, and double-clicking the thumbnail opens it, so a screenshot of a request thread or a photo of a whiteboard stays attached to the assumption it supports. Write the same point in the note as well, because images are not searched.

• Rank the evidence: behavior first, opinion second, belief last
• One note per assumption, as a bulleted list with sources
• Node images up to 1.5 MB hold screenshots and whiteboard photos
• Pictures on the node, the words in the note

Find the riskiest assumption

The riskiest assumption is not the hardest to check, it is the one that kills the idea if it turns out to be false, and it is frequently the cheapest to check. Sort the assumption nodes by consequence first and effort second, and the top of the list is where the next fortnight should go.

Use the layers to see the structure of the risk. The 3D layer stack puts each layer on its own depth plane, with up to eight layers in one map, so you can place the problem on one plane, the approach on another and the evidence on a third, then use trace mode to follow the cross-layer links and see which assumption touches which part of the idea. The 3D stack guide covers the camera presets and the explode slider.

• Sort by consequence first, effort second
• Problem, approach and evidence on separate layer planes
• Use trace mode to follow the links between layers
• Pull the stack apart and look for branches with no counterpart

Design the smallest test

A test is only worth running if it can come out badly, so write the failure condition before you design anything. Under each assumption node, add a child called "test" with four lines: the method, the cost, the deadline, and the number that would count as failure. If you cannot name the failure number, you are not running a test, you are gathering more opinions.

Cross-link the test node to the assumption it tests, and write the result in the note when it lands, with the date. A test with no recorded result quietly becomes an assumption you promoted to a fact, and that is the most common way an idea map turns into a sales pitch without anyone deciding anything.

1. Write the failure number first. Before designing the test, write what result would count as failure, so the test can actually end.
2. Pick the cheapest signal. Choose the method that costs the least and returns the clearest signal, usually a conversation or one small payment.
3. Set the deadline. Give the test a date, and treat the date as real, since a test with no deadline is a test that never runs.
4. Record the result in the note. When the test lands, write the outcome, the number and the date in the note of the test node.

Decide: build, pivot or drop

Set the decision rules before you have the results, while the idea still feels plausible. Make a branch with three children: the result that means build, the result that means pivot, and the result that means drop. A rule written after the result is a justification.

Apply the rules to the evidence and not to the enthusiasm. If the test came back negative but the problem is real, that is a pivot, and the map says so: move the assumption node into the pivot branch and write what you learned from it. The business plan map is the right next document once an idea survives this check, because it asks the same questions with a budget attached.

Keep the dropped ideas on the map as their own branch. Each one cost you a fortnight, together they are the reason you pivot quickly next time, and an idea you dropped for a stated reason is less likely to return as an obsession. A map of what you tested is worth more than a map of what you liked.

• Build, pivot and drop rules written before the results arrive
• Rules applied to the evidence rather than to how you feel
• Pivot means moving the assumption and recording what you learned
• Keep the dropped ideas, with the reason they were dropped

Note: The 3D stack needs WebGL, so the layered view is not available on every device. The two-dimensional layers work everywhere and are enough for the same job of separating problem, approach and evidence.

A checklist you can reuse

• The root node holds one sentence with customer, problem, approach and difference
• Every assumption is written as a statement that could come out false
• Each assumption is cross-linked to the part of the idea that depends on it
• Every note names the strength of the evidence, not only the evidence
• The riskiest assumption is chosen by consequence rather than by effort
• Every test has a failure number and a deadline written before it runs
• The build, pivot and drop rules were written before the results landed

Common mistakes to avoid

• Assumptions written as facts. A statement that cannot be proved wrong is not an assumption, it is a belief. Rewrite every one of them so a specific result would knock it down.
• Counting enthusiasm as evidence. Polite interest is not demand. Rank what you have found, and keep the rank visible so the map cannot promote a compliment into a finding.
• Testing the approach first. Building a version of the solution tests your taste and your coding, not your market. Check that the problem and the willingness to pay exist before the product does.
• No failure condition on a test. A test without a number that would count as failure cannot end, and so it never changes your mind. Write the failure number first.
• Deleting the ideas that failed. A map of what you tried is what makes the next decision faster. Keep the dropped ideas with their reasons, and the map becomes a record instead of a pitch.

Frequently asked questions

What is the difference between an assumption and a goal?

A goal is something you are trying to achieve, and an assumption is something you are betting on without proof. Your goal might be a thousand paying customers; the assumptions underneath it are that the problem is painful, that the buyers are reachable, and that thirty dollars a month is acceptable. The assumptions get tested and can be wrong.

How do I know which assumption is riskiest?

Sort by consequence first. The riskiest assumption is the one that, if false, removes the reason the idea exists, and it is often cheap to check, which is why it should go first. The 3D layer stack helps, because separating the problem, the approach and the evidence onto their own planes shows which assumption is holding everything up.

Do I need to build anything to test an assumption?

Almost never at the start. The assumptions about demand, reach and price are tested with conversations, a short offer and a payment. Building is what you do once the risky assumption has survived, and building too early is the most common way to spend a quarter on the wrong question.

Is talking to people real evidence?

It is evidence of opinion, and opinions are a good test of wording and a poor test of behavior. The map can record what each conversation showed and keep the pattern over ten conversations, but it cannot settle the market question. That is what a payment, a pre-order or a repeated behavior is for.

This guide is part of the mind map use cases collection. For the wider product tour, read the complete Canvasola guide, and keep the keyboard shortcut cheat sheet open while you work.