Context
Most engineering work starts under pressure to produce something. A ticket arrives, a stakeholder names the fix, and the work begins. The faster path is to take the problem statement at face value and start building. It is also the more common one.
That reflex is expensive when the problem is hard or novel. The cost rarely shows up at first. It surfaces later, when the shipped solution misses the actual constraint, or when the second-order problem the first one created consumes more time than the original.
For hard problems, we treat problem definition as work in its own right. Before code, before architecture, before a quote. Going deep on a problem is not separate from solving it; when the problem is hard, it is most of the solving.
The wrong problem, well solved
The failure mode we see most often is not a poorly built solution. It is a well-built solution to the problem someone happened to articulate first.
A team is asked to "speed up the report." They optimize the report generator. The report becomes faster. Six weeks later, it turns out the report itself was a workaround for missing data exports, and the underlying need was an API. The optimization holds, but it solved a symptom. The real work, exposing the data, still has to be done, and now there is a faster report nobody uses.
This pattern repeats across security findings, prototype briefs, and platform migrations. The named problem is almost always a compression of the real one. Researching it is the act of restoring what was compressed out.
What going deep actually means
In our practice, going deep on a problem is concrete work, not a posture. It looks like this:
- Restate the problem in our own words. If we cannot, we do not understand it yet. The restatement gets reviewed by whoever brought us the problem.
- Find the boundary. What is in scope, what is adjacent, what is out. Where does this problem touch other systems, other teams, other deadlines.
- Inventory what is already known. Prior art, internal history, vendor documentation, the relevant academic work. We assume someone has thought about this before; the question is what they found.
- Identify the binding constraint. Performance, cost, regulatory, human, political. Solutions that respect the wrong constraint do not survive contact with deployment.
- Reproduce the symptom. Where possible, get the problem to occur in a controlled setting. A reproducible failure is half a solution.
- Write down what we do not know. The list of unknowns is usually more useful than the list of knowns.
This work happens before a single line of production code. On a typical engagement it takes anywhere from a day to a couple of weeks. What we produce is a written document. The rest of the project leans on it.
What changes when you do this
Two things shift, both quietly.
First, the proposed solutions get smaller. A correctly framed problem usually has a tighter solution than the framing it arrived with. The "rewrite the service" recommendation becomes "change one query and add an index." The "we need an ML model" becomes "we need cleaner labels." The reduction is not because we are conservative; it is because the original framing was reaching for tools that the actual constraint did not justify.
Second, the work that does happen tends to stay solved. A fix grounded in the right problem is harder to dislodge by the next surprise, because the surprise was probably already on the list of unknowns we wrote down.
Takeaways
The case for going deep is not philosophical, it is economic. Time spent on problem definition compounds; time spent on the wrong solution does not. The two are almost always traded against each other under deadline pressure, and the second one wins more often than it should.
We do not always have the luxury of a long study. Some problems are well-understood and the right move is to act. But when a problem is unfamiliar, expensive to get wrong, or has been "solved" before without sticking, the highest-value work is usually upstream of the solution.
Before the fix, the question. Before the question, the problem. We try to spend more time there than feels comfortable.