The Analyze column: the one everyone skips
This is part of The Four-Column Ask. The framework sorts ideas by clarity and evidence. Analyze is the top-left: high evidence, low clarity. You have strong proof customers are in pain — a pile of support tickets, the same sentence in five churn interviews, a metric falling off a cliff — and you genuinely do not know what the solution is yet. This is the column teams skip, and skipping it is the most expensive habit in product after building unvalidated features.
Why it gets skipped
Because "go figure out the problem" feels slower than "go build something," and it is slower — in the way that aiming is slower than firing. A roadmap full of Analyze items looks, to an impatient stakeholder, like a team that isn't shipping. So the pressure is to convert the loud problem straight into a feature: the metric's dropping, do something, here's a thing. And now you've shipped a confident answer to a question nobody understood — which usually moves the metric not at all, and costs a sprint to discover that.
Strong evidence of a problem is seductive precisely because it's real. It feels like a mandate to act. But evidence that a problem exists is not the same as knowledge of what solves it, and treating the first as if it were the second is how good teams build earnest, well-intentioned features that miss.
The move: define the problem, then diverge, then graduate
Analyze is discovery work, and it has a shape:
- Define the problem precisely. "Users churn" is not a problem statement; it's a metric. "Users on the free tier churn in week two, right after they hit the export wall, and the export wall isn't mentioned at signup" is a problem statement. The sharper the definition, the smaller the solution space.
- Diverge before you converge. Generate several genuinely different solutions, not three flavors of the first idea. The whole value of the column is that you don't yet know the answer, so the worst thing you can do is anchor on the first plausible one.
- Graduate the best candidate rightward. Once a solution has clarity, it leaves Analyze: if it's well-evidenced and settled, into Build; if it's clear but the demand is still a hypothesis, into Test. Analyze doesn't ship anything itself — it manufactures clarity and hands it off.
The output of an Analyze item is not a feature. It's a sharpened problem and a ranked set of options. If a research spike ends with "we now know exactly what to build," it worked.
Protect it from the pressure to ship
The reason this column needs active defense is that its work is invisible until it pays off. A Build item produces a demo; an Analyze item produces understanding, which doesn't screenshot well. So name it explicitly on the board, give it a real timebox (research without a deadline becomes a hobby), and report its output as an output: "we defined the churn problem and have three candidate solutions, one heading to Test." That's progress, and saying so in those words is how you keep the column alive against the gravity of "but what are we shipping."
What I'd tell a team
- Treat a loud metric as a question, not a mandate. The drop tells you where to look, not what to do. Resist converting evidence-of-problem directly into a feature.
- Make the problem statement do the work. Most of the value of this column is in the sentence that defines the problem. Vague problem, vague solution; precise problem, small solution space.
- Timebox the research. Analyze without a deadline drifts. A two-week spike with a defined output ("a problem statement and three options") keeps it honest.
- Report understanding as progress. "We figured out the real problem" is a shippable result. If your status format can't represent it, your status format is biased toward the Build column.
What's next
Build, Test, and Analyze are all about moving ideas forward. The last column is about the opposite, and it's the hardest of the four — not intellectually, but emotionally. Next: the Drop column, and the real cost of the roadmap items you keep alive because you can't bring yourself to kill them.