Understanding the Problem

Imagine a deployment team receives a request from a client: the client wants a tool that flags unusual entries in a report. The engineers are eager, the request is specific, and within a week a working prototype exists. The client looks at it politely and then quietly stops using it. Nothing in the code is broken, yet the project has failed.

Follow the state of this project as it moves. At the start, there is one sentence: the client wants a tool. By the end of the first week, there is a finished prototype, and the team's plan has been fixed around that sentence. The step that was skipped is the one that asks whether the sentence describes the problem the people doing the work actually have. This article is about that missing step and about the habit that produces the failure when it is skipped.

Most projects begin with a sentence someone wrote down, such as a statement that a process must be done in a particular way. That sentence is only a first description, often shaped by whoever happened to raise the issue. The people doing the work may be struggling with something quite different. The gap between what was asked for and what actually hurts can decide whether a project succeeds or stalls for months.

The central move is to separate the two problems that are easy to blur together: the problem as it was stated, and the problem as it actually is when you examine the people and records involved. Once those two are separated, the choice of a first step often becomes much clearer. The two problems usually point toward different first steps.

The first slice is the smallest piece of work that could be finished and tested, and the problem you choose to solve determines it. If the stated problem is a large capability such as automated inspection, the first slice tends to inherit that size: it needs specialized technology, outside approval, and long rollout planning before anything is delivered. If the real problem is a documentation burden, the first slice can be built from more ordinary parts that already exist in the workplace. Redefining the problem can therefore turn a large, uncertain effort into a smaller, feasible one.

The source gives an example from a manufacturing team. Most people on the team had heard the request that the inspection line must be automated, and a whole plan had formed around it. Examining the daily routine revealed a different difficulty: a documentation burden. Inspectors were spending large amounts of their shifts writing records.

Notice that the redefinition does not throw away the original concern. The inspection problem is still a real frustration for the people involved. What changes is the order in which the team tackles that frustration. The source's documentation solution involved what it calls gravel road work: unglamorous pieces such as a pipeline, a workflow, and an export. Feasible solutions are often less exciting than the original request, and their value lies in being finished, tested, and trusted by the people who depend on them.

Once the real problem is named, the team needs a way to tell whether a solution has worked. That is the role of a success metric: a quantity that can be measured before and after a change. A useful success metric is tied to the real problem, not to the solution being proposed. If the team measures progress by how many automated checks are running, it may report success while inspectors are still writing records late into the evening.

The source states its metric in the customer's units: documentation hours per inspector-shift. This matters because the people who fund and judge the work think in those units. A metric the customer cannot read or relate to will be hard to defend, even when it is technically precise. A metric in the customer's units tells the customer directly whether their situation has improved.

The guard condition in the source example is essential. Reducing documentation time is not enough on its own, because the records must still be audit-ready. A solution that makes paperwork faster but less trustworthy has not met the target. A good success metric therefore often comes paired with a guard condition that the solution must not break.

An automated inspection might be the ideal end state and still be a poor place to start, if the validation bar is unlikely to be cleared and the rollout stretches over several quarters. Feasibility should therefore be examined through four factors that the source identifies.

A solution that scores poorly on several of these factors at once is a weak candidate for the next step, even if it addresses a visible problem. The timeline a candidate solution implies is part of the evaluation, not an afterthought.

The most common belief behind this failure is that the problem has already been stated. A customer describes what they want, and the team treats that description as the target. It feels efficient to accept the stated problem and begin building immediately. The misconception is the assumption that the stated problem and the real problem are the same thing.

In the build-first sequence, the wrong target is locked in at the second step, when the team builds directly from the stated request. The prototype is correct against that request, so nothing looks broken. In a discovery-first sequence, the real problem is surfaced before any building, and the system is built against that. The difference is not the amount of effort. It is the target the effort is aimed at.

The consequence of building against the wrong target is usually not a technical crash. The system may run correctly and meet every specification it was given. The trouble appears later, when people try to use it. The typical symptom is adoption stalling, because the system solves something other than what the line user actually needs help with.

The people who will live with the tool each day are the ones who notice the gap first. Follow the flowchart above: the decision point is the moment when a user tries the system against their daily work. If the tool does not fit that work, the path leads to stalled adoption and, eventually, quiet abandonment. The state that changes is not the code but the match between the tool and the work it was meant to support.