The four-column ask: build, test, analyze, or drop

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.