DataKnobs

Before the roadmap

The questions worth settling before you decide how to build it.

Most product work fails quietly — not because the execution was weak, but because the team answered solution questions before it had finished answering problem questions. These are the questions that catch that, organised by what they're actually asking about rather than by what stage of a process they belong to.

Opening slide of a presentation on product approach questions
Title slide from the source deck. It carries its own text, so it opens full size in a new tab rather than being read at page scale.

Why this order

Solution questions are the easiest to answer well

Ask a team to justify its build plan and you'll get a fluent answer almost every time — the tech stack makes sense, the timeline is reasonable, the design reviews went smoothly. None of that tells you whether the team is solving something real.

Solution questions are comfortable because they have a craft to lean on: architecture, design systems, sprint planning. Problem, user, and business questions are less comfortable, because the honest answer is sometimes "we don't actually know" — and that answer is far more useful to surface in week one than to discover after launch.

The five clusters below are ordered from least to most comfortable to skip. Nobody skips the solution questions. Plenty of teams skip straight past the first two.

01

The problem

Before anything else: is there actually something here worth solving.

  • What problem, stated without mentioning the solution?

    If the problem statement already names a feature, the team has skipped straight to an answer and can no longer tell whether it was the right one.

  • Who has this problem, specifically?

    "Everyone" is not a segment. A problem that's real for a named group is testable; a problem attributed to everyone usually means nobody was asked.

  • Why now, rather than six months ago or six months from now?

    Urgency that can't be explained is often borrowed from someone else's priority, and a plan built on borrowed urgency loses support the moment attention shifts.

  • What happens if nobody solves this?

    If the honest answer is "not much," that's a real answer — it just means the effort belongs lower on the list than its advocates believe.

02

The user

A real problem can still be attached to an imagined user.

  • What is this person trying to get done, in their own terms?

    A job description is more durable than a persona. People change; the job they're trying to accomplish changes far more slowly.

  • What are they doing today instead?

    Every user already has a workaround, even if it's a spreadsheet or doing nothing. If the current workaround is good enough, the bar for replacing it is higher than the team assumes.

  • How would they describe success, unprompted?

    If the team can't answer this without guessing, the plan is still describing what the team wants to ship, not what the user wants to happen.

  • Who is this explicitly not for?

    A plan that serves everyone equally usually serves nobody especially well. Naming who's out of scope is what keeps the in-scope answer sharp.

03

The solution

Only once 01 and 02 hold up does it make sense to ask how.

  • What's the smallest version that tests the riskiest assumption?

    Not the smallest version of the product — the smallest version of the bet. Those are often different things, and conflating them produces MVPs that are small but still untested on what actually matters.

  • What are we deliberately not building yet, and why?

    An explicit not-yet list protects scope better than a roadmap does, because it states the reasoning instead of just the sequence.

  • What would make this solution wrong even if the problem is right?

    Separates two failure modes that get diagnosed identically from the outside — a good answer to the wrong problem, and a wrong answer to the right one — but need different fixes.

04

The business

A solution can work for the user and still not work for the business carrying it.

  • How does this create or protect value, concretely?

    Revenue, retention, cost avoided, risk reduced — pick the actual mechanism rather than a general claim that it's "important" or "strategic."

  • What does it cost to build, and then what does it cost to run?

    Build cost gets estimated; ongoing operating cost — support, infrastructure, the maintenance nobody schedules — routinely doesn't, and it's often the larger number over time.

  • What is this displacing?

    Every commitment is also a decision not to do something else with that time. Naming the alternative is what keeps the tradeoff honest instead of implicit.

05

Risk and validation

The questions that decide whether the team will notice being wrong.

  • What's the riskiest assumption the whole plan depends on?

    Ask, for each assumption, what happens if it's wrong. The one whose failure unravels the most work — and that the team has the least evidence for — is the one worth testing first.

  • What would prove this plan wrong fastest?

    Not what would confirm it — teams are good at finding confirming evidence without trying. The disconfirming test is the one worth actually running.

  • What signal tells us to stop or change course?

    Decided in advance, this is a stop condition. Decided after the fact, under sunk-cost pressure, it's a rationalisation — and it's almost always more generous to the plan than the pre-committed version would have been.

Signature tool

Where are the open questions right now?

Think of a specific initiative you're currently deciding how to approach. For each question below, check it off only if you — or someone on the team — could answer it right now without guessing. The bars track how covered each cluster actually is, not how confident the team feels.

01 — The problem0%
02 — The user0%
03 — The solution0%
04 — The business0%
05 — Risk & validation0%
Problem
0/4
User
0/4
Solution
0/3
Business
0/3
Risk
0/3

Check off what you can genuinely answer. The gap, not the score, is the point.

Getting it wrong

How teams skip these without noticing

Naming the feature in the problem statement

"Users need a dashboard" is a solution wearing a problem's clothes. It closes off every other answer before the problem cluster even gets asked.

Treating a strong opinion as a validated answer

Confidence and evidence are easy to confuse in a room full of smart people. A firmly held belief about the user still needs to be checked against an actual user.

Writing the stop condition after the fact

A stop-or-change signal decided under sunk-cost pressure is not a signal — it's a justification. It has to exist before the team is invested.

Answering business questions with "it's strategic"

That phrase is doing the work a concrete value mechanism should be doing. If nobody can say how, the business cluster isn't actually answered.

Questions

Common questions

Why answer these before designing a solution?

Because a well-built answer to the wrong question is expensive to detect. A team can ship something competent — the build goes smoothly, the reviews look reasonable — and the miss only becomes visible after launch, when it costs far more to unwind than it would have to catch during framing.

Do all five clusters need to be fully answered before starting?

No. The clusters are where to look, not a gate to clear in order. Some answers only firm up once building starts — that's normal. What matters is that the team can name which questions are still open, rather than mistaking silence on a question for agreement.

What is the riskiest assumption in a plan?

The belief the rest of the plan depends on most, and that's least supported by evidence. Ask, for each assumption, what happens if this one is wrong — the one whose failure would unravel the most work, and that the team has the least reason to believe, is worth testing first.

What's the difference between a solution question and a problem question?

A problem question asks whether something is worth solving at all — is it real, for whom, why now. A solution question asks how to solve it, assuming the problem is already settled. Answering solution questions well while the problem questions are still open is the most common way teams build the wrong thing competently.