Short answer: Give the plan a spine: customer and problem, reachable market, offer and price, channels, numbers, and the assumptions that would sink it. Put each branch's evidence in rich notes, cross-link every claim to the assumption that supports it, and export the map as Markdown when you need a written plan.
Define the customer and the problem
Name the customer in the root node, then add the problem as three children: what they do now, what that costs them, and what makes them look for a fix this month. The third one decides whether the plan is real, because a problem with no trigger is a problem nobody spends money on.
Let the node labels carry the claims and the rich notes carry the evidence. A label such as "they reconcile invoices by hand across three systems" is a sentence you can argue with, and the note holds the interview, the date and the exact words they used. The mind map maker starts you in the browser, and Canvasola also ships thirteen starter templates, one of which is the Business Model Canvas, a shape to fill in or delete rather than a blank page.
- Name a customer you could list five of by name
- The problem branch holds what happens now, what it costs and the trigger
- Labels carry the claim, notes carry the interview and the quote
- Cross-link the customer branch to the offer branch later
Size the market you can reach
The number that matters is the one you can reach, not the one that looks impressive. Three numbers are worth writing down: the total market, the part of it your offer could serve, and the slice you can actually reach in the first year. Plans routinely quote the first and quietly work with the third, and readers notice the jump.
Build the reachable number from the bottom rather than the top. How many people fit the customer description, how many of them can you name, and how many could you contact in a month if you did nothing else? Put the working in the note, because the number is an argument and the working is what a reader will check. A number without working is a wish with a decimal point.
- Three numbers: total market, serviceable market, reachable market
- Build the reachable figure from named people
- Record the working in the note next to the number
- Compare the reachable slice against the cost of one customer
Note: Market figures copied from a report are the easiest thing on a plan to contradict. A reachable number you built from your own list is smaller, and it is the one worth planning on.
Describe the offer and the pricing
The offer branch answers three questions: what the customer gets, what it costs, and why the price is that figure. Give the branch a child for the offer, a child for the price, a child for the reason behind the price, and a child for what the offer replaces. The reason behind the price is where the answer to "why not just do this ourselves" lives.
Price is a claim about value, so the comparison belongs on the map. Put in the note what the customer spends today for the same outcome and what the nearest alternative costs, with the source. A price with no comparison behind it is a guess, and the first customer who asks why not less will find it out.
- Offer, price, reason for the price and what it replaces
- The note holds what the customer spends today for the same outcome
- A child node for what is out of scope
- One sentence per child, in language a customer would use
Map the channels that reach them
Give each channel a branch with three children: where the customer already spends attention, what it costs to reach them there, and what you would test first if this were the only channel you had.
Rank the channels by the cost of a real signal rather than by reach. The first months of any plan should be dominated by the cheapest channel that produces evidence about willingness to pay, and everything else can wait. If you are still choosing between channels, the startup idea map runs the same decision on assumptions instead of channels, which is often the more useful order.
Cross-link each channel to the customer branch it reaches. A channel that does not point at a named customer is a habit rather than a plan, and the missing link is usually the reason a plan stalls after the first month.
- One branch per channel, with cost, reach and first test
- Rank by cost of a real signal, not by audience size
- Link every channel back to the customer branch
- Name the one channel you would test first if it were the only one
Show the numbers behind the plan
Give the plan a numbers branch with one node per line, and let each node's rich note hold the working rather than the result. Fixed costs, variable cost per customer, price, gross margin, and the number of customers needed to cover the fixed costs. Write the formula in words inside the note, because that is where a reader can check the thinking and a bare number cannot be checked at all.
Show the monthly shape and not only the year. Plans that annualize everything hide the month where the money runs short, and that month is the one your cash has to survive. A node for the worst month, with the note saying what makes it the worst month, is worth more than a year-end total.
Export the map as Markdown and the plan becomes a document. Markdown export produces a nested text outline, which you paste under one heading per branch to get the written plan in a fraction of the time, and the map stays as the version you keep updating. The export guide covers the formats and the file naming.
- Build the numbers branch. Add one node per line of the model, from fixed costs through to the number of customers that breaks even.
- Write the working in the notes. Put the formula and the source of each input in the node's rich note so the number can be checked.
- Add the worst month. Give the plan a node for its thinnest month and note what makes it thin, so the cash forecast is not a yearly average.
- Export and read it as prose. Export the map as Markdown and read the outline top to bottom, fixing any branch that only makes sense as a picture.
List the assumptions that would sink it
The last branch is the honest one: the assumptions that would sink the plan if they turned out to be false. Write each as a statement, one per node, and mark every one that no other branch on the map supports. Then draw a cross-link from each assumption to the branch that depends on it, so a reader can see how far the damage would spread. The cross-links guide shows how to draw them and what they look like.
Finally, make the plan readable for a reader who did not build it. Node icons come from a fixed set of seven emoji plus a remove option, so you can mark the standard blocks of a canvas with a symbol each, and per-node typography sets the font family, the size from 10 to 96, the weight, the italics and the alignment. The Business Model Canvas template gives you the shape, and the icons and the type make it usable in a meeting.
- One node per assumption, written as a statement
- Cross-link each assumption to the branch that depends on it
- Sort by consequence, not by how hard the check is
- Mark unsupported assumptions so they cannot pass as findings
Note: A plan with no assumptions branch reads as a list of certainties, and a reader will not believe any of it. The branch that names what could be wrong is what makes the rest of the map credible.
A checklist you can reuse
- The customer is named specifically enough to list five real examples
- The problem branch records the cost and the trigger for acting
- Three market figures exist, and the reachable one drives the plan
- The pricing note compares the price with today's cost and the nearest alternative
- Every channel links back to a named customer
- Each number in the numbers branch has its working in a note
- Every assumption is linked to the branch that would fail if it is wrong
Common mistakes to avoid
- Quoting the total market. A number you cannot reach does not plan anything. Show the total for context, then plan against the slice you can actually contact.
- Prices with no comparison. A price on its own is a guess. Put what the customer pays today and what the nearest alternative charges in the same note.
- One channel, no backup. Plans that depend on a single channel stop when that channel changes. Map at least two, and mark which one you would test first.
- Numbers with no working. A result without the calculation cannot be checked or defended. Put the formula and the source of each input in the note.
- No assumptions branch. A plan that lists only certainties gets read as a pitch. Name the statements that would sink it, and link each to what depends on it.
Frequently asked questions
Do I need the Business Model Canvas template for this?
It is a useful starting shape rather than a requirement. The template is one of thirteen starters in Canvasola and gives you the standard blocks of a canvas, which you rename, fill in or delete. The plan you end up with should follow the argument of your business.
How do I stop assumptions from turning into facts?
Keep them in their own branch, in their own wording, and never move one into a claim branch until something in the map supports it. Cross-linking each assumption to the branch that depends on it makes the dependency visible, and a reader who spots a weak assumption sees what it puts at risk.
Can I export the plan to a document?
Export the map as Markdown and you get a nested text outline that pastes straight under your own headings, which is the fastest way to produce a written plan from a map. PNG and SVG give you pictures for a deck, and the .canv project file keeps everything in one file.
Can my co-founder work on the plan with me in Canvasola?
Not at the same time. There is no live editing for two people in one map, no comments and no share links, so your co-founder cannot open the map in the app from your browser. Export Markdown or PNG and send the file, or save a .canv project file for whoever has Canvasola.
Put the plan on one page of structure.
Open Canvasola and start from the customer branch rather than the numbers, because the numbers only make sense once the customer and the problem are written down. Add a branch, then a note with the evidence behind it.
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.