"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."
I really enjoy the concept of unknown knowns, but I don’t agree with your example, which is an unknown unknown.
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)
I think unknown knowns are more easy to spot when teaching newcomers how the system works. Their questions will sometimes be about things we hadn't even considerered (at least in some time) to be the case, but when you have to spell everything out it is indeed the case. In terms of teaching unknown knowns are critical to identify and instead make known knowns so that everyone can end up with a mostly equal playing field.
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.
Usually there's a tacit assumption of how the system works, how the users are using the system, or something else about the system or the environment that causes that - it's not that the answer wasn't known, it's that it was assumed to be something it wasn't and nobody realized that was an assumption and not a fact.
"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."