No Facts Inside the Building
What happens when the chance to get out of the building is available but not taken?
Every organization has experienced some version of this. A solution is directed from a higher level, and the problem it is meant to solve is real. The intent behind it is not unreasonable, and yet, somewhere between the directive and the deployment, the people who will actually have to live with the solution were never really asked what they needed.
We have been watching one of these situations develop. A data and dashboard initiative, directed from a level removed from day-to-day operations, is moving toward a solution that will almost certainly serve the level that commissioned it while creating new burdens for the levels below. The underlying data has known integrity problems. The numbers look different depending on which system you are reading. None of that has been fully surfaced in the design conversation, and the people closest to the operational reality offered to walk the project team through the process.
The offer was not taken.
No Facts, Only Opinions
Steve Blank, writing about why so many startups fail before they find their market, put it this way: “In a startup, no facts exist inside the building, only opinions.” Blank was describing product development, but the observation travels well beyond Silicon Valley. He later collaborated with BMNT to bring this same customer discovery methodology to national security problem sets through the Hacking for Defense course at Stanford, now running at over 70 universities. The core insight transfers directly: whether you are building a consumer app or a command-directed data platform, staying inside the building means substituting opinion for fact. Understanding the actual problem requires going to where the problem lives.
We have written about this dynamic before. Earlier in this series, we noted that agile development only earns its name when users are involved from the start. Most customer discovery failures happen because teams do not think to ask. The assumption that leadership’s understanding of the problem is sufficient goes unexamined. The result is a product built from the inside out.
But something more interesting happens when the chance to get out of the building is offered and not taken. What does it mean when the operational level extends an invitation and the development team declines? The problem is no longer ignorance. The path to the facts was available, and the choice to stay inside was a choice.
Who Is the Customer?
We are not suggesting bad faith. In large hierarchical organizations, the pressures to move quickly and demonstrate progress are real. Walking a process takes time, and it can surface complications that are easier to defer. And when authority is concentrated at the commissioning level, it is easy to mistake the commissioner’s understanding of the problem for the user’s experience of it.
That distinction matters more than it usually receives. In a hierarchical setting, the customer of a data solution is almost always assumed to be whoever directed it. In practice, the people who have to use the solution daily are often an entirely different population with different questions, different workflows, and a different relationship to the underlying data. Conflating the commissioner with the user is not a minor oversight. It shapes every decision that follows: what gets measured, what gets displayed, what gets governed, and what gets quietly ignored.
When the underlying systems of record are already producing different numbers depending on who is reading them, this distinction becomes critical. A solution designed from the top down will be calibrated to resolve the questions leadership is asking. It will not necessarily resolve the data integrity problems that make those numbers unreliable in the first place. And it will almost certainly not answer the questions that operational leaders need answered before the next cycle begins.
A Discovery Problem
This is not a technology problem. The platform choices, the dashboard design, the governance architecture, those are secondary. The primary problem is a discovery problem. The people who understand the operational reality offered to share it. That offer represented a low-cost opportunity to surface the gap between what the solution will deliver and what the work actually requires.
If your organization is working through a similar gap, a solution that was shaped without adequate input from the people who have to execute against it, Storm King Analytics is glad to help you think through it. These are solvable problems, but they require asking different questions before the design is locked in. Reach out at info@stormkinganalytics.com.
What happens when that opportunity is passed over is not hard to predict. We explored the structural dimensions of that outcome in an earlier post. The short version: when a solution does not answer the questions operators need answered, and when trust in the underlying data is already fragile, operators find other ways to get the information they need. Not as defiance, as execution.
That is the subject of the next post.
This is a great insight and it applies in any number of industries. Higher education leaders seem to forget they run outfits literally full of subject matter experts, and never think to consult them.....