A few years ago, a large Midwest-based paint and coatings manufacturer asked me to help them crowdsource a redesign of a new industrial pump. The new pump worked beautifully in the lab, but clogged constantly when used outdoors. The engineers were convinced they had a mechanical design problem. They wanted to put a challenge out to a crowd of external solvers to get a better pump.

Before we started to design a crowdsourcing campaign, I asked the engineers one question: were the indoor and outdoor testing conditions identical?

They weren’t. Lab testing took place in summer, with indoor temperatures often in the mid-seventies. Outdoor testing happened in autumn, with temperatures rarely exceeding sixty degrees. The paint loaded into the pump was becoming viscous with even a small drop in temperature — choking the device. The engineers fixed the problem by adjusting the paint formulation. No redesign. No crowdsourcing. No new pump.

What they were about to spend was tens of thousands of dollars on service fees and prize money, at least six months running the campaign, and additional months (and money) testing and validating new designs. The actual cost to fix the problem? Essentially nothing.

The engineers had not made an engineering mistake. They had made a diagnostic one. And it is the most common kind.

The Step Nobody Examines

Here is the move that almost derailed this project — and that derails far more projects than most organizations ever realize.

The engineers observed a failure: the pump clogged outdoors but not indoors. That observation was accurate. Their next step, however, was not an investigation. It was a classification. They decided, immediately and confidently, that they were dealing with a mechanical design problem.

That leap — from “we observe a failure” to “we know what type of failure this is” — is the most dangerous step in problem solving. It is dangerous not because it is always wrong, but because it feels indistinguishable from reasoning. It presents itself as a logical inference when it is actually an assumption.

Once that classification is made, everything that follows becomes coherent. If you have a mechanical design problem, you need better mechanical design. You bring in external solvers. You evaluate proposals. You test prototypes. Every subsequent step is rational, given the premise. The premise itself is never revisited, because it was never recognized as a premise in the first place.

This is how organizations spend months and significant resources solving the wrong problem with great discipline and intelligence.

Why Confidence Makes It Worse

There is a particular irony in the pump story. The engineers were not careless. They were experienced professionals who had designed, built, and tested the pump themselves. That expertise is precisely what made the misdiagnosis so easy to make and so hard to question.

When you know a domain deeply, pattern recognition accelerates. You have seen pump failures before. You know what mechanical problems look like. The clogging fit a familiar category, and the familiar category triggered a familiar response. Confidence was not a character flaw here — it was the natural output of genuine competence applied one step too early.

This is worth reflecting on, because it means the problem is not solved by hiring smarter engineers or more experienced consultants. It is solved by building in a deliberate pause between observation and classification — a moment where the question is not “what should we do about this?” but “what kind of problem is this, and how do we know?”

That pause is uncomfortable. It can feel like doubt, hesitation, or a lack of decisiveness. In reality, it is quite the opposite: it is the discipline to avoid committing resources to a direction before the direction has been validated.

This Is Not a Manufacturing Problem

The pump story is industrial and concrete, which makes it easy to follow. But the diagnostic trap it illustrates is not specific to manufacturing, or to engineering, or to any particular domain.

Consider an organization that has tried to fix a recurring operational problem three times, with three different interventions, none of which have helped. The instinct after the third failure is usually to look harder for a better version of the same type of solution — a different vendor, a different process, a different team. The question that is rarely asked is whether the problem type was correctly identified in the first place.

Consider a leadership team preparing to invest in AI tools because competitors are moving quickly and the pressure to act is real. The stated problem is often something like: “We need to be more efficient” or “We need to automate more of our workflow.”

Those are directions, not diagnoses. The classification — this is an automation problem, this is a technology problem — has already been made, usually before anyone has examined what is causing the inefficiency or where automation would genuinely create value versus simply accelerating a flawed process.

In both cases, the leap from symptom to assumed cause type has already happened. By the time the solution is being designed, the diagnostic window has effectively closed.

Intervention Is Simpler Than You Think

The question that stopped the crowdsourcing campaign was not sophisticated. It did not require advanced analytical tools or weeks of investigation. It required only a willingness to treat the problem classification as provisional rather than settled.

“Were the testing conditions identical?” is a question about assumptions. It surfaces a factor, temperature, that had been invisible not because it was hidden, but because it had never been looked for. The engineers were looking at the pump. Nobody was looking at the conditions around the pump.

Structured problem diagnosis does not replace domain expertise; it works alongside it. The goal is not to slow down good engineers or second-guess experienced teams. The goal is to insert a brief, rigorous examination between the moment of observation and the moment of classification — to ask, before resources are committed: “What are we assuming about the problem, and what would it take to test that assumption?”

That question, asked early enough, is worth more than almost any solution.

Before You Fund the Fix

The pump story ended well and quickly. One question, asked before the campaign launched, redirected months of effort and significant cost. Not every story ends that cleanly — sometimes the diagnostic question comes later, after some of the wrong path has already been traveled. But the principle holds regardless of timing.

The most expensive mistake an organization can make is not choosing the wrong solution. It is choosing the right solution to the wrong problem. Because the right solution to the wrong problem can be executed brilliantly, on time and on budget, and still fail to change anything that matters.

Before you fund the fix, redesign the system, or automate the workflow — make sure you’re solving the right problem.

That is not analysis paralysis. It is the precondition for genuine progress.