"What he forgot to add was the crucial fourth term: the "unknown knowns," the things we don't know that we know."
I've found it's really critical during the project planning phase to get to not just where the boundaries of our knowledge are, but also where are the things we're either tacitly assuming or not even aware that we've assumed. An awful lot of postmortems I've been a part of have come down to "It didn't occur to us that could happen."
To me the corporate version of the unknown known is when a a project is certainly doomed, for reasons everyone on the ground knows about, yet nobody wants to say anything and be the messenger that inevitably gets killed, as long as paycheck keeps clearing. An exec ten thousand feet from the ground sets a “vision” which can’t be blown off course by minor details such as reality, until the day it does.
Theranos is a famous example of this but I’ve had less extreme versions happen to me many times throughout my career.
Another example of unknown knowns might be the conflict between companies stated values (Focus on the User) and the unstated values that are often much more important (Make Lots of Money)
As an example, there are a lot of unknown knowns that you accumulate over the years in certain lower level languages that need to be spelled out more clearly to someone who is coming at it as a later endeavor. It's entirely possible to spend all your time in a completely managed language nowadays and the concept of the stack, heap, etc., will be largely alien to you. These ideas and their limitations need to be spelled out clearly in order for someone to build the same knowledge base and intuition.
Unknown knowns are essentially endless in nature and extremely hard to find unless you have someone who simply doesn't know to basically fall into traps and guide you toward finding your hidden knowledge.
Would that not be an unknown unknown?
