A concept map externalises the relationships between ideas in a domain, making invisible mental models visible and debatable. Use it when a team needs shared understanding of a complex space before making decisions — not after.
Section 1
What This Tool Does
Knowledge lives in relationships. Not in the individual facts, definitions, or data points that populate a domain, but in the connections between them — the causal links, the hierarchies, the dependencies, the contradictions. Ask five people on a product team what "platform" means and you'll get five definitions. Ask them how "platform" relates to "API," "marketplace," "developer ecosystem," and "network effects," and you'll get five entirely different architectures of understanding. Those invisible structural disagreements are where misalignment lives. They're also where the most expensive strategic errors originate.
Joseph Novak developed concept mapping in the 1970s at Cornell University, not as a business tool but as a research instrument. He was studying how children learn science, and he needed a way to see what was happening inside their heads — how they organised new knowledge relative to what they already knew. His insight was that meaningful learning isn't about accumulating facts; it's about integrating new concepts into an existing structure of relationships. A child who memorises "plants need sunlight" has learned a fact. A child who can draw the relationship between photosynthesis, chlorophyll, glucose, cellular respiration, and energy transfer has learned a system. Novak's concept map was designed to make that structural understanding visible, inspectable, and — critically — correctable.
The tool migrated from education into knowledge management, systems engineering, and strategic planning because the problem it solves is universal. The core cognitive shift: concept mapping forces you to articulate not just what you know, but how the things you know relate to each other — and it's in those linking phrases between concepts that most of your assumptions, errors, and insights hide. A concept map is not a list. It's not a hierarchy. It's a network of propositions — "concept A → linking phrase → concept B" — that together form a readable model of a domain. "Customer acquisition → drives → revenue growth" is a proposition. "Revenue growth → funds → product development" is another. Chain enough of these together and you have an explicit, arguable theory of how a business works.
The distinction from mind maps matters and is frequently confused. Tony Buzan's mind map radiates outward from a single central topic in a tree structure — branches and sub-branches, no cross-links, no labelled relationships. It's an organisational tool for brainstorming. A concept map, by contrast, is a network. Concepts connect to multiple other concepts. The links carry labels that specify the nature of the relationship. Cross-links between different regions of the map are not just permitted but are where the deepest insights emerge. A mind map says "these things are related to this topic." A concept map says "here is precisely how these things relate to each other, and here is where our understanding has gaps."
That precision is what makes concept maps useful for decision-making. When a founding team debates whether to pursue enterprise sales or self-serve growth, the disagreement is rarely about the conclusion. It's about the underlying model — the assumed relationships between pricing, sales cycle length, customer lifetime value, support costs, and product complexity. A concept map makes those assumed relationships explicit. Once they're on the wall, you can argue about the right ones instead of talking past each other because you're operating from different invisible models.
