The Map is Not the Territory

Jul 14, 2026

“The greatest obstacle to discovery is not ignorance. It is the illusion of knowledge.” - Daniel J. Boorstin

A map leaves almost everything out. That is the point. The streets on it are real, but the map is not the city. A map that showed every detail would be as large and as confusing as the city itself, and therefore no use at all. So it simplifies, and we use it, and it works.

We run on maps all day. A roadmap, an org chart, a dashboard, a plan, an idea of who the customer is. Each one is a simplified version of something larger and messier. They are useful because they leave things out. The problem starts when we forget they are simplifications and treat them as the real thing.

Where the idea comes from

The phrase comes from Alfred Korzybski, who founded a field called general semantics in the early twentieth century. In his 1933 book Science and Sanity, he made one point that has held up: the words and models we use are not the reality they describe. They are maps of it. A map can be accurate or wrong, detailed or rough, but it is never the territory, and problems come from confusing the two.

“A map is not the territory.” - Alfred Korzybski

The average pilot who did not exist

In 1950 the US Air Force set out to update the average pilot. The cockpits had been built around measurements taken in 1926, and the assumption was simple: design for the middle of the range and you fit the most people.

A lieutenant named Gilbert Daniels tested the assumption. He measured 4,063 pilots across 140 dimensions, then took the ten that mattered most for the cockpit and asked how many were close to average on all ten. The answer was zero. Not one pilot was average across the board. The average pilot was a number on a chart. He did not exist, and the cockpit had been built for him.

The average was a useful map. The territory was four thousand specific bodies, and none of them matched it. Once the Air Force understood that, they stopped designing for the man who was not there and made the cockpit adjustable: seats, pedals, and straps that move to the person. That change, designing for the real range instead of the imagined middle, is the same idea behind the seat that slides in your car.

The maps we draw ourselves

“The first principle is that you must not fool yourself, and you are the easiest person to fool.” - Richard Feynman

This gap is not only found in older stories. We have all met it in our own work.

At Reach we build a product that relies on data from external systems and partners. Answers from AI search engines, keyword volumes, domain authority scores, CPCs, crawls of entire websites. Before we build against any of these, we prepare. We read the API documentation, analyse the responses, think through the edge cases, design mockups with every field filled in. All set.

Then, sooner or later, something fails. The contract is not quite the one we implemented. The response carries nulls where none were supposed to be. The same request returns a different answer on a different day. A field that was always filled in the mockups arrives empty, and suddenly we are questioning the data we show our customers. The map was not the territory. What we analysed, detailed and designed has to change once it meets the real thing.

Maps do not only lie about data. They lie about people, and those are the expensive ones. A wrong API contract costs a rework. A wrong picture of the user costs a quarter, pointed with confidence at somebody who was never there.

I have been in that room more than once. Everyone is sure. The people closest to the problem are sure, I am sure, and not one of us has gone and asked. Within a day there is a picture of the user in our heads, detailed and confident, and the work starts pointing at it.

That picture is a map, and it was drawn from the certainty in the room.

When we do finally go and look, at what people actually do rather than what we were sure they did, the territory says something else. The user in our heads is rarely the user on the other side, and we have been building for a composite of our own confidence.

Certainty inside a building is not evidence about the world outside it, and I have caught myself treating one as the other more than once.

Walk the territory

“Go see, ask why, show respect.” - Fujio Cho

If maps can mislead, the fix is to go and look. The Toyota Production System has a name for it: the gemba walk. Gemba means “the real place.” A manager who wants to understand a problem does not rely on a report about the floor. They go to the floor, watch the work happen, and ask the people doing it.

A report is a map someone else already drew and simplified. The floor is the territory. The same is true away from a factory: the roadmap is not the product, the dashboard is not the customer, the spec is not the running system. When the map and what we are seeing disagree, the cheapest move is usually to go and check the real thing. Three moves make that concrete.

Watch one person use it. Not a usability report, not a survey, not a summary of a survey. Sit with one real user doing their real task, and stay quiet. The quiet is the hard part, because when they get stuck the urge to explain is almost physical, and the moment we explain, we have learned nothing. Their confusion is the data. Twenty minutes of that will contradict more of our assumptions than a quarter of dashboards, because we see the hesitation before the click, the workaround they invented months ago, and the spreadsheet they still keep open next to our product.

Call the real thing before designing against it. Documentation is a map, and it describes the system as it was on the day it was written. Then it drifts. Fields become optional, defaults change, the team that owned it moves on, and the document stays where it was. So before the first mockup, send the real request and read what comes back. The nulls where the docs promised a value. The field that arrives empty for half the rows. The answer that changes when the same question is asked a day later. Then design for that payload, the one that actually arrived, and make the empty and the wrong first-class cases instead of an afterthought. The alternative is to meet them later, in production, in front of a customer.

Pull the number yourself, at least once. A dashboard is a map somebody drew, and every number on it hides choices we never saw: what counted as an active user, whether the bots were excluded, which timezone the day starts in, whether the duplicates were removed. Go to the data and count it by hand, one time. Either it agrees, and that number can be trusted for a year. Or it does not, and we have just found that the whole team has been steering by something quietly wrong.

A good map is still worth having

“All models are wrong, but some are useful.” - George Box

This does not mean throw the maps away. A map we can trust is one of the most valuable things a team has. The point is to hold it loosely: use it to move, check it against reality as you go, and update it when the two stop matching.

Old maps deserve the same treatment. A model being established does not make it wrong, and dropping everything proven to chase the new is its own way of ignoring reality. A good map is compressed experience, and throwing it out to see for ourselves is a way of paying again for something somebody already paid for.

Pushed too far, the model becomes its own trap. If every map is suspect, nothing can be acted on. Every plan gets questioned, every number gets re-derived, and the team spends its days verifying instead of building. Rigour turns into paralysis, and from the outside it still looks like diligence.

And the arithmetic does not work. At any real scale we have to act on maps we cannot check ourselves. That is what a map is for, to let us move through territory we have not walked. A leader who insists on seeing everything firsthand becomes the bottleneck, and the organisation slows to the speed of one person’s eyes.

So the skill is selective. Check the map the decision rests on. Check the one drawn long ago by someone who has since left. Check the one nobody has verified and everyone quotes. The rest can usually be trusted until they give a reason not to.

Wrap-up

“If the map and the terrain disagree, trust the terrain.” - Swiss Army proverb

Every plan, model, and metric is a map. Each is useful, and each leaves something out, and the leaving out is the price of being able to use it at all.

This is not only a team problem. A career runs on a map, the plan we once made about who we would become. So does the story we tell ourselves about what we are good at. Those maps drift quietly, because nothing forces us to check them. The ground moves, and the drawing stays where it was.