The Four-Column Ask

Most roadmap fights look like disagreements about which feature is best. They almost never are. They're two people arguing past each other because one is sure of the solution and the other is sure of the problem, and nobody said which. The fix isn't a scoring spreadsheet with eleven weighted columns. It's two questions, asked out loud, about every idea on the table.

How clear is the solution? Do we actually know what we'd build, or are we hand-waving?

How strong is the evidence? Do we have data that real users have this problem, or is it a hunch with confidence?

Plot those two on a 2×2 and every idea lands in one of four boxes. The point of the box isn't a label — it's that each box dictates a different next action. You're not ranking features. You're deciding, for each one, whether the honest next step is to build it, test it, research it, or let it go.

The four columns

Build — high clarity, high evidence. You know the problem is real (the data says so) and you know what to make (the design is settled). This is the only quadrant where writing code is the right next move. Everything else is a different kind of work wearing a "feature" costume. Most teams' mistake is treating the whole backlog as if it lived here.

Test — high clarity, low evidence. You have a crisp, fully-designed concept and no proof anyone wants it. The trap is that a polished mockup feels like evidence — it's concrete, it demos well, a stakeholder loved it. It isn't evidence. The next move is a prototype or a fake-door or five user sessions — the cheapest thing that turns "we think" into "we know," before a sprint goes into it.

Analyze — low clarity, high evidence. You have strong signal that customers are in pain — support tickets, churn interviews, a metric falling off a cliff — but no idea what the solution looks like yet. Jumping to "build" here is how you ship a confident answer to a question you haven't understood. The next move is research and divergent design: define the problem precisely, generate options, then graduate the best one rightward into Test or Build.

Drop or Backlog — low clarity, low evidence. A vague idea with nothing behind it. Someone's pet theory, a competitor's shiny thing, a "wouldn't it be cool if." No shame in it — most ideas start here. But it doesn't get a roadmap slot until it earns one by acquiring clarity or evidence. Park it or let it go, and stop relitigating it every planning cycle.

The move is the output, not the label

Here's what makes this more than a quadrant meme: the matrix doesn't tell you what's important, it tells you what to do next — and those are different things. A feature with huge potential value can still belong in Analyze, because the honest next action is research, not a Jira epic. The framework's whole job is to keep you from skipping that step.

And ideas move. That's the part static prioritization misses. A Test item that passes its prototype slides up into Build. An Analyze problem, once you've designed a solution, slides right. A Build item that turns out to rest on stale data slides back down into Test, which is exactly the conversation nobody wants to have and everyone needs to. The matrix is a snapshot of a thing in motion, and re-placing items every cycle is the work.

What it actually buys you

I run this on a whiteboard before any roadmap review, and three things happen every time.

It kills the most expensive mistake first. Building unvalidated features — the Test column shipped as if it were Build — is where teams burn quarters. Naming the quadrant out loud makes that miscategorization visible before it's code.

It gives stakeholders a shared language for risk. "I love this idea" and "the data backs this" stop being the same sentence. An exec can advocate hard for something and still see, on the wall, that it's in Test — that wanting it doesn't move it to Build, evidence does. That conversation is so much calmer when the axes are drawn.

It makes the next step unambiguous. No idea leaves the meeting as "approved" or "rejected." It leaves as build it, test it, go research it, or back to the parking lot. People know what to do Monday.

What I'd tell a team

• Ask the two questions before you score anything. Clarity and evidence first; weighted scoring later, and only inside the Build column where it actually means something.
• Treat a beautiful mockup as Test, not Build. Polish is not proof. The number of "obviously great" features that died in their first real user session should make you humble about your own quadrant calls.
• Protect the Analyze column. It's the one teams skip, because "go figure out the problem" feels slower than "go build something." It is slower. It's also the difference between solving the problem and shipping a confident guess.
• Re-place the board every cycle. The value isn't the first sort; it's noticing what moved, and especially what slid backward when the evidence didn't hold.

You don't prioritize a feature. You prioritize the next action a feature has earned — build, test, analyze, or drop — and you make the team say which, out loud, with the axes on the wall.

What's next

This is the framework. The rest of the series is one post per column, because each is a different discipline with its own traps: Build (the smallest column, and why teams overfill it), Test (a mockup is not evidence), Analyze (the column everyone skips), and Drop — the hardest one, where you learn to kill what you're attached to.

This is part of The Four-Column Ask — one post per column. The framework post sorts every roadmap idea by two questions: how clear is the solution, how strong is the evidence. Build is the top-right corner: high clarity and high evidence. It's the only column where the next action is "write the code." It's also the smallest, and the one teams quietly turn into a dumping ground.

Build is a destination, not a starting line

Here's the mental flip that makes the whole framework work: Build isn't where ideas go to get prioritized — it's where they arrive after they've earned it everywhere else. A feature lands in Build because the evidence already exists (you proved the problem in Analyze or the demand in Test) and the solution is already settled (you designed it, you scoped it, the open questions are closed). Build is the output of the other three columns doing their job, not the inbox.

Most roadmaps invert this. Everything goes straight into Build because "we're a shipping team and shipping means building." So the column fills with half-validated bets and half-designed features, and the team spends the sprint discovering the questions that should have been answered before the ticket existed.

What actually earns a Build slot

Three things, and all three, not two of three:

• Evidence the problem is real. Not "a stakeholder wants it." Usage data, a metric that moves, a validated demand signal from a Test, a clear pattern from Analyze. Wanting is not evidence — that's the Test column's whole lesson.
• A settled solution. You can write the definition of done before the sprint, and it won't change three days in because someone "realized" something. If the design still has open forks, it's not Build yet — it's Test or Analyze wearing a Jira ticket.
• Scoped to a shippable increment. "Rebuild search" is not a Build item; it's a project. "Add fuzzy matching to the existing search box, measured against the current null-result rate" is. Build items are small enough that done is unambiguous.

If a candidate is missing any one of those, it doesn't get demoted in priority — it gets sent to the column that supplies the missing piece. No evidence → Test. No solution → Analyze. The honest move isn't to build it anyway "to learn"; that's just an unfunded experiment with a deadline.

The definition of done is the gate

The single most useful discipline in this column: write the definition of done before you start, and treat any mid-sprint change to it as evidence the item didn't belong in Build. A Build item whose scope keeps moving is telling you it was actually a Test (you didn't know if the approach worked) or an Analyze (you didn't understand the problem). That's not a failure — it's the framework catching a miscategorization before it eats the whole sprint. Slide it back a column and stop pretending.

This is also why "Build" is where weighted scoring finally earns its keep. RICE, value-vs-effort, whatever your shop uses — those models assume you know the value and the effort. Inside Build, you do; that's what got it here. Run them anywhere else and you're putting decimal points on guesses.

What I'd tell a team

• Keep the column small on purpose. A short Build column isn't a sign the team is under-ambitious — it's a sign the other three columns are doing their job. A bloated Build column is the warning light.
• Make "definition of done before the sprint" non-negotiable. It's the cheapest test for whether something is genuinely Build. If you can't write it, you're not ready to build it.
• When scope moves, move the item. A Build item that keeps changing isn't a discipline problem to push through — it's a misfiled card. Send it back to Test or Analyze and let it re-earn the slot.
• Save the scoring for here. Effort and value estimates mean something only when clarity and evidence are both high. Everywhere else, they're confident fiction.

What's next

Build is the easy column to describe and the hard one to keep honest. The harder questions are upstream. Next: the Test column — high clarity, low evidence — and the most seductive mistake in product, mistaking a beautiful mockup for proof.

This is part of The Four-Column Ask. The framework post sorts ideas by clarity and evidence. Test is the bottom-right: high clarity, low evidence. You know exactly what you'd build — it's designed, it's crisp, it demos beautifully — and you have no proof anyone actually wants it. The job of this column is to buy that proof for the price of a prototype, before it costs you a sprint.

The trap: polish feels like proof

A finished mockup is the most dangerous artifact in product, because it activates every instinct that's supposed to mean "ready." It's concrete. It's specific. It demos well in the all-hands. A stakeholder sees it and says "yes, this." And every one of those signals is about the solution's clarity — none of it is evidence the problem is worth solving. You can have a pixel-perfect, universally-admired design for a feature literally no one will use.

That's the miscategorization that eats quarters: a Test item shipped as a Build item, because polish got mistaken for validation. The whole point of naming the column is to interrupt that — to say, out loud, "this is gorgeous and unproven, and gorgeous-and-unproven is Test."

The move: the cheapest thing that turns "we think" into "we know"

Test is not "build a smaller version." It's "run the cheapest experiment that produces a real signal." The ladder, roughly cheapest to dearest:

• Fake door — ship the button, not the feature; measure how many people click it and where they fall off. Costs an afternoon, kills more bad ideas than anything else.
• Prototype + five users — a clickable flow in front of five real people in the target segment. You will learn more in those five sessions than in five weeks of internal debate. (Five is not a focus group; it's a smoke detector. If three of five hit the same wall, you have your answer.)
• Concierge / Wizard-of-Oz — do the thing manually behind the scenes for a handful of customers before automating it. Proves demand and surfaces the real workflow.
• A/B on a thin slice — only when you already have traffic and the build is genuinely small. The heaviest test; reach for it last.

The discipline is to pick the cheapest rung that would actually change your mind, run it, and then move the item: passed → it slides up into Build; failed → it goes to Drop, and you just saved a sprint.

"We'll just build it to learn" is a Build wearing a Test costume

The most common way teams skip this column is to build the real thing and call shipping it "the experiment." Sometimes that's right — when the build truly is cheaper than the test. Usually it isn't, and "we'll learn from production" is how you spend a quarter to learn something a fake door would have told you in a day. If the honest cheapest-thing-that-would-change-your-mind is smaller than the feature, the feature isn't Build yet. It's Test, and the test is the smaller thing.

What I'd tell a team

• Name the disguise. When a beautiful mockup shows up in planning, say "Test" before anyone says "Build." The word does the work — it reframes admiration as a hypothesis.
• Pick the rung that would change your mind. Not the most rigorous test imaginable — the cheapest one whose result you'd actually act on. If a fake door would settle it, a prototype is procrastination.
• Pre-commit to the threshold. Decide what "passed" means before you run it, or you'll rationalize whatever you get. "≥ 30% of clickers complete the fake-door flow" beats "see how it feels."
• A failed test is a win. It's the cheapest outcome in the whole framework — proof you shouldn't build, bought for an afternoon. Celebrate the kills.

What's next

Test answers "do they want this solution?" But sometimes you don't have a solution to test yet — only a loud, well-evidenced problem. That's the column most teams skip, and skipping it is how you ship a confident answer to a question you never understood. Next: the Analyze column.

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.

This is the last post in The Four-Column Ask, and the hardest one. The framework sorts ideas by clarity and evidence; Drop is the bottom-left corner — low clarity, low evidence — the vague idea with nothing behind it. Describing the quadrant takes one sentence. Living in it is a come-to-Jesus moment, because Drop isn't really about the obviously-bad ideas. It's about the ideas you're attached to.

The easy drops aren't the point

Yes, the pure bottom-left exists: someone's pet theory, a competitor's shiny thing, a "wouldn't it be cool if" with no problem behind it. Those are easy — no one fights for them once you say the words. If that were the whole column, it wouldn't deserve a post.

The real Drop work is everything that's been sitting in your backlog for a year because no one will kill it. It had a champion once. It got designed, maybe. It's "a good idea, just not now" — and it's been "not now" for four quarters. It isn't low-quality. It's low-priority forever, which is a different and harder thing to admit, because admitting it means admitting the time you already spent on it isn't coming back.

The zombie tax

Here's the part teams don't price: a backlog item you'll never build is not free to keep. Every one of them is rent you pay, every planning cycle, in the currency of attention:

• Someone re-reads it to decide if it's relevant yet.
• Someone re-litigates it ("should we finally do X?").
• It pads the backlog so the things that matter are harder to see.
• It quietly anchors estimates and roadmaps that will never include it.

A hundred zombie items don't cost nothing because they're "just sitting there." They cost a slice of every prioritization meeting, forever, and they make the board lie about how much is actually in play. The most expensive backlog is the one no one ever prunes — not because of what's in it, but because of what it costs to keep reading it.

The real grooming math: value × cost × what-else-is-in-there

Killing the easy ones is triage. Killing the attached ones needs a colder lens than "is this a good idea?" — because most zombies are perfectly good ideas. The question is never "is it good?" It's "is it good enough to beat what it's competing against, given what it'll cost?" Three axes, not one:

• Value — honestly, not aspirationally. The number you'd defend with evidence, not the one the champion hopes for.
• Cost — build and the carrying cost of keeping it alive unbuilt.
• Opportunity cost — what else is in the column. This is the axis people skip, and it's the one that does the killing. An item isn't competing against zero; it's competing against everything else you could do with the same slot. A 6-out-of-10 idea in a backlog full of 8s is a drop, even though 6/10 is "good."

That diagonal is the whole game. It isn't fixed — it rises every time a better idea enters the column. Which means an item can be a legitimate keep one quarter and a drop the next, having gotten no worse: the bar simply moved. "But it's still a good idea" is true and irrelevant. Good isn't the bar. Better-than-what-it's-displacing is the bar.

The 80/20 of a backlog

Pareto runs straight through here: roughly 80% of your realized roadmap value will come from about 20% of the candidate ideas. The implication is brutal and freeing at once — most of your backlog is not waiting its turn; it's never getting built, and on some level you already know which. The 20% deserve real investment. The other 80% deserve an honest funeral, not eternal "someday" status that costs you attention while delivering nothing.

This is why a healthy Drop column is a sign of health, not failure. A team that never drops anything isn't disciplined; it's hoarding. The backlog that only grows is a backlog no one trusts, because everyone knows most of it is fiction.

Why it's emotionally hard (and how to make it easier)

The thing standing between you and a clean backlog is almost never analysis. It's sunk cost and attachment. "We spent three weeks designing this." "It was my idea." "The VP loved it in Q1." None of those are reasons to build something; they're reasons it's hard to kill — which is exactly backwards. The sunk cost is gone whether you build or drop; only the future cost is yours to decide.

A few things that make the cut cleaner:

• Separate the kill from the criticism. Dropping an idea is not a verdict on the person who had it. Say that out loud, especially if it's your own idea.
• Drop, don't bury. Move it to a genuinely archived list you don't groom, not a "someday" column you re-read forever. The point is to stop paying rent, and a "someday" column still charges it.
• Make re-entry cheap and explicit. "This is dropped; if it acquires real evidence or clarity, it re-enters through Analyze or Test like anything else." That removes the fear that killing it means losing it forever — it can always come back, on merit, like a new idea.
• Drop on a schedule. Put a recurring "what do we kill" on the calendar, so it's a normal hygiene act and not a dramatic confrontation. Pruning shouldn't require courage; it should require a Tuesday.

What I'd tell a team

• Price the zombies. Every unbuilt item you keep costs attention every cycle. A backlog isn't a free storage locker; it's a room you have to walk through every time.
• Judge against the column, not against zero. "Is it good?" is the wrong question. "Does it beat what it's competing for the slot against?" is the right one — and most beloved items lose it.
• Name the sunk cost so you can ignore it. The three weeks are gone either way. Say it, then decide on the future cost alone.
• A growing-only backlog is a broken one. If nothing ever leaves, the list is fiction and everyone knows it. A regular, unsentimental Drop is what keeps the other three columns honest.

That's the four-column ask, end to end: Build what's earned it, Test what's only beautiful, Analyze what's only painful — and Drop, without flinching, what you're keeping alive for reasons that have nothing to do with the work.