Understand the Problem Not the Solution

Separating the problem from the borrowed fix

Asked what algorithm runs in her head, Shuo Wang, a co-founder of Deel, describes a routine for separating the problem, which she thinks deserves study, from the proposed solution, which she treats as usually borrowed and one-dimensional. In her words: "I understand the problems, not the solutions. A lot of the time people come with a problem and they also come with a solution. But the solution may just be for one dimension. A lot of people follow the existing solutions without understanding the real problem, and without understanding why the existing solution was built for this real problem."¹

The routine

Wang lays out the sequence she runs before acting. First, acknowledge the problem exists and matters, rather than dismissing it or jumping to a fix. Second, ask why the problem exists, to reach the actual cause rather than the symptom someone has already wrapped in a solution. Third, ask why the existing solution was built the way it was, which means understanding the prior designers' constraints and reasoning, "what were they thinking about." Only then, informed by the problem's structure and the tradeoffs of the existing solution, does she design her own.

A worked example

Wang illustrates the routine with a team that says "we need to hire more people," which she treats as a solution rather than a problem and refuses to act on directly. She asks why, and learns that Project A needs resources while the existing team is committed to Project B. She then asks whether Project A's value is meaningful to the goal, and what the current team's capacity actually is, and whether Projects A and B could share a better process. Usually, she says, the answer is that a better process is the right move rather than a dedicated new team, because spinning up a siloed team would create non-communicating workflows and downstream inefficiency. Her summary of the anti-pattern: "if we just listened to the solution, we need more people, I'd say go ahead, hire," and the point is precisely not to do that reflexively.

Why she says it matters

Wang ties the routine to two payoffs. The first is anti-cargo-cult discipline. She names the founder trap of chasing "what's popular, what Brazilian companies are doing," copying solutions without owning the underlying problem. The second is that understanding the problem is upstream of focus: it is what lets a company "build a long-term solution and long-term vision" rather than rebuilding a different product every quarter as the market shifts. In her framing the method is what makes a durable roadmap possible, because a solution copied without its problem cannot be reasoned about when conditions change.

Where it strains

The routine is demanding in a way Wang's own examples make visible. It asks the operator to reconstruct the reasoning of prior designers, which is not always recoverable, and to hold off on a plausible fix long enough to interrogate it, which cuts against the speed pressure inside a fast-growing company. It also assumes there is time and access to trace a problem to its cause before committing, a luxury not every decision affords. Wang treats the discipline as the method that complements an attitude of moving toward problems: the instinct says run to the problem, and this routine is how she takes one apart once she is there.