Should we build this? A product decision framework

A feature request can be clear and still hide the real decision.

“Add SSO.” “Build an AI assistant.” “Create team dashboards.” The requested output is obvious. What is usually less clear is which problem it solves, for whom, what needs to be true for it to matter and what happens if the team is wrong.

Before estimating implementation, make the decision and its assumptions explicit enough to investigate.

1. Write the decision behind the feature

Start with the decision the team is actually making.

A feature-shaped question might be:

Should we build shared dashboards?

A decision statement adds the context that can be investigated:

Should we invest in shared dashboards now because lack of visibility is preventing team accounts from adopting the product?

The second formulation exposes a target user, a problem and an expected consequence.

2. List what must be true

A build decision rests on assumptions. Make them explicit.

For the dashboard example, you might need to believe that:

• team accounts have a visibility problem;
• the problem affects adoption or retention;
• dashboards address the problem better than simpler alternatives;
• the affected segment matters enough to justify the cost.

If the team cannot state what must be true, there is not yet enough structure to evaluate the decision with evidence. See assumptions vs evidence in Product Discovery.

3. Investigate competing explanations

Questions framed only around demand can make the first proposed solution look inevitable.

A stronger investigation asks what else could explain the observed problem.

Maybe teams are not adopting because setup is difficult. Maybe managers lack permissions rather than visibility. Maybe the request comes from one large prospect while existing customers solve the problem elsewhere.

Competing hypotheses reduce the risk of using research mainly to justify the first solution proposed.

4. Match confidence to the cost of being wrong

Different decisions justify different levels of research effort.

A reversible experiment can tolerate uncertainty. A six-month platform investment, migration or pricing change should face a higher confidence bar.

Ask:

• how expensive is this to build and maintain?
• how difficult is it to reverse?
• what else will we not build if we choose this?
• which missing evidence could realistically change the decision?

Enough evidence depends on the decision, its reversibility and the consequences of being wrong.

5. Keep multiple outcomes available

A useful decision framework should leave room for several outcomes:

• build when the evidence and risk justify commitment;
• run a narrower experiment when the direction looks promising and uncertainty remains;
• reframe when research reveals a different problem;
• defer when important gaps remain and the question is still relevant;
• stop when the case is too weak to justify more attention.

Deferring a decision can be the disciplined outcome when the current evidence does not justify commitment yet.

Record why the decision is defensible

Whichever path the team chooses, the reasoning should remain understandable later.

A useful decision record connects the question, assumptions, hypotheses, evidence, contradictions and open gaps to the direction chosen at that moment.

That history gives the team a clear basis for revisiting the decision when new evidence appears.