Why Organizations Don’t Know What They Want

The New Responsibility

“The business does not know what it wants” is one of the most common explanations for a difficult system-change initiative.

It is usually said with frustration. A team asks for requirements. The answers change. Stakeholders disagree. A prototype appears, and someone points out a condition that no one mentioned at the beginning. The project seems to move in circles.

From the outside, this can look like indecision or a lack of preparation. If people would only think carefully enough before the work began, the reasoning goes, they could define what they wanted and move forward.

But that is not how understanding usually works.

Organizations do not fail to know what they want because they are careless or incapable. They struggle because the answer is distributed across people, embedded in daily work, and often only visible when a proposed change makes it concrete.

They do not need better ways to extract a finished answer from stakeholders. They need better ways to develop an answer together.

The answer is already present—just not in one place

When someone says an organization does not know what it wants, they are often looking for a single authoritative statement: a requirement, a process map, a decision from a leader, or a list of features.

The knowledge is rarely organized that way.

The person who works directly with customers knows which exceptions are harmless and which predict a serious problem. A manager understands the tradeoffs behind an approval process. A finance partner sees the downstream consequence of a definition that looks simple to the operating team. A product leader recognizes where the current experience is breaking down. An executive may hold a strategic intent that changes the meaning of all of those local decisions.

Each perspective is partial. None is sufficient on its own.

This is not a defect in the organization. It is a consequence of specialization. Complex work requires people to see different parts of the system closely. The trouble begins when an initiative expects all of that distributed knowledge to arrive as one coherent answer before anyone has had the chance to compare it.

At that point, people often respond with what they can honestly provide: a description of the problem they see, a preferred solution, or an example from the last time something went wrong. Those are valuable inputs. They are not yet a shared model of the work.

Requests are often compressed observations

Consider a request like, “We need a better way to track customer escalations.”

It sounds like a straightforward system request. A team might begin by asking what fields the escalation record needs, who can create one, which reports are required, or what an agent should do when it encounters one. Those questions are reasonable, but they can move too quickly toward a solution.

Behind the request may be several different observations:

• Customers are repeating their story because information does not travel with the issue.
• Teams cannot tell who owns the next step.
• Some escalations are urgent for contractual reasons, while others are merely inconvenient.
• Managers learn about important problems too late.
• A product defect is being treated as a service case because no one has a clear path to connect the two.

All of those observations might be true. They do not necessarily point to the same system.

If a team treats the first request as a complete requirement, it may build an escalation tracker, automation, or agent workflow that records more information without resolving the coordination problem underneath it. The resulting system can be perfectly faithful to the request and still fail the people who made it.

The work is to unpack the request. What friction is it describing? What is happening today? Which distinctions matter? Where do different people see the same situation differently? Only then can the organization decide what it actually needs to change.

Understanding appears when people can react to something real

This is why asking people to describe the ideal solution in a meeting is often less productive than giving them something concrete to respond to.

A sketch of a workflow, a small set of examples, a prototype, or an early model makes assumptions visible. It gives people a shared object to examine. Someone can point to a state and say, “That is not what ‘resolved’ means in our team.” Another person can notice that an important handoff has disappeared. A third can explain why a rule that sounds sensible would create a problem at month-end.

Those reactions are not interruptions to discovery. They are discovery.

AI makes this process faster because it can turn an incomplete idea into something visible quickly. But it does not change the underlying dynamic. The first version is valuable not because it is likely to be right, but because it creates the conditions for people to see what they had not yet articulated.

This is also why early changes in direction should not automatically be treated as failure. Sometimes a team is drifting because it has no way to make decisions. But sometimes it is learning. The difference is whether the new information is being made visible, discussed, and carried forward—or whether the organization is simply recreating the same confusion with each new version.

Requirements cannot substitute for discovery

Requirements are useful. They record decisions, guide implementation, and make scope discussable. The problem comes when they are asked to perform a job they cannot do: create shared understanding where it does not yet exist.

Teams can write a detailed requirements document while holding different mental models of the business. They can agree on a list of features without agreeing on the concepts those features are supposed to represent. They can sign off on a workflow only to discover, once it is operating, that a crucial exception was never visible to the people in the room.

No amount of specification can eliminate the need to learn from reality.

The better sequence is not “collect requirements, then discover whether they were right.” It is to treat requirements as one output of an ongoing discovery process. As the team learns what the work involves, its descriptions become more specific. As it tests a model, it can distinguish a true rule from a one-off workaround. As people negotiate the meaning of a term, the requirement becomes a record of a decision they actually understand.

That makes requirements more useful, not less. They become an expression of shared understanding rather than a substitute for it.

The question to ask instead

When an organization cannot state exactly what it wants, the helpful response is not, “Come back when you have the answer.”

Ask instead:

• Where does the work break down today?
• What do people do when the formal process does not fit?
• Which decisions are difficult because the information or ownership is unclear?
• What do different teams mean when they use the same term?
• What would we need to see in a prototype to know whether this is moving in the right direction?

These questions do not demand false certainty. They give the organization a way to turn uncertainty into something it can examine.

That is especially important now. As AI lowers the cost of producing software and other system behavior, the pressure to begin with an answer becomes even stronger. A team can generate an application, agent, automated workflow, or report from a brief description, and the result may be impressive enough to discourage anyone from asking what was left out.

The opportunity is to use that speed differently. Generate an early version in order to learn, not to avoid learning. Treat the places where people disagree as signals of important work, not obstacles to getting started. Let the organization’s understanding emerge through the process of making its own operating model visible.

Organizations do not need to know everything they want before they begin. They need a disciplined way to discover what matters as they go.

The next question is the one that clarifies the difference: if understanding is an active, negotiated process, what exactly is the role of documentation?