Knowledge Realism
Why the Best Plans Begin With What We Don't Yet Know
In 1940, the Tacoma Narrows Bridge collapsed just four months after opening.
What makes the story interesting is not that the bridge failed. Failures happen. What makes it interesting is that it failed despite careful planning. Competent engineers designed it. Calculations were performed. Drawings were reviewed. Construction was professionally managed.
Yet the plans extended beyond the limits of the available knowledge.
The collapse became a lesson. Engineers studied what happened and future bridges became safer. The failure became knowledge. The knowledge became better plans.
That sequence — experience, learning, knowledge, planning — appears throughout human history.
When humans first began building shelters, there were no blueprints. When the first boats were built, there were no engineering manuals. The first farmers had no agricultural science to guide them.
People built with the knowledge they had, observed the results, and adapted. Some approaches worked and were repeated. Others failed and were abandoned. Over time, successful practices were remembered, taught, and passed down. What one generation learned became the starting point for the next.
What began as experimentation gradually became craftsmanship. Craftsmanship became standards. Standards became specifications. Specifications became plans.
Planning did not come first. Learning came first.
That relationship is easy to miss because we live in a world surrounded by mature knowledge.
Consider something as ordinary as a roof. Today we understand gravity, water, materials, and the common causes of failure. Because those things are well understood, we can estimate materials, sequence work, assign skilled trades, and predict outcomes with reasonable confidence. The plan works because the underlying knowledge is mature.
But introduce a completely new roofing material and certainty begins to disappear. Questions emerge that nobody can answer with confidence because the knowledge does not yet exist. At that point, planning does not disappear — it shifts from planning execution to planning learning. Tests are run. Assumptions are validated. Observations are gathered. Knowledge is created.
Software is no different. Despite how modern it feels, software is simply another thing humans build.
Some aspects are mature and well understood — authentication, data storage, infrastructure, and many security practices have been refined through decades of experience. In those areas, detailed planning often works because the knowledge base is deep and stable.
Other aspects are far less certain. Will users adopt a new workflow? Does the organization truly understand its own business processes? These are not technical questions. They are questions of learning.
Many projects struggle because they fail to distinguish between what is known and what is assumed. Hypotheses become requirements. Assumptions become commitments. The result is an execution plan for work that has not yet been learned.
If you don’t know how to do something, you cannot honestly plan how to do it. You can only plan how you will learn.
I think of this as Knowledge Realism — the practice of matching plans to the actual maturity of our knowledge.
But maturity of knowledge is not a simple binary. In practice, there are meaningful distinctions worth naming:
There are things we know — observable, evidence-grounded, tested by experience. Plans built on this ground can be specific and confident.
There are things we believe — well-reasoned positions, supported by evidence but not yet proven. Plans built here should name their assumptions and include mechanisms for testing them.
There are things we suspect — directional intuitions, plausible but not yet evidence-backed. Plans that depend on these should be held loosely and reviewed as evidence accumulates.
And there are things we must learn — genuine unknowns the plan depends on but cannot yet answer. These are not gaps to paper over. They are often the most important items in the plan, because until they are resolved, everything downstream is built on air.
The more we know, the more we can specify. The less we know, the more we must plan to learn. Sometimes the most honest plan is a learning plan.
This matters beyond project delivery. It matters for strategy.
Strategic documents are full of claims that look identical on the page but carry very different weights of evidence. A confident assertion and a hopeful hypothesis wear the same clothes. Knowledge Realism asks the harder question: do we actually know this — or have we written it down so many times that it feels true?
The discipline of separating what we know from what we believe, what we suspect from what we must learn, does not make strategy weaker. It makes it more credible — and more resilient, because a plan that is honest about its own uncertainties can adapt when those uncertainties resolve differently than expected.
We are living through a moment that puts this discipline under particular pressure.
Artificial intelligence is compressing certain categories of work — precisely the categories where knowledge is most mature and accumulated expertise can be encoded and scaled. As that happens, what remains scarce is the opposite: judgment, understanding, the organizational capacity to know what problem you are actually trying to solve before committing to a solution.
Planning the execution is getting easier. Planning the learning has never mattered more.
Which brings the real question:
Where have you created an execution plan when what you actually need is a learning plan?