Decision Framework

A decision framework should make one consequential choice clearer. It is not a way to avoid judgment or turn uncertainty into a score.

Use it when the team is circling a question such as:

• Should we hire?
• Should we raise prices?
• Should we add a channel?
• Should we build this feature?
• Should we enter this market?
• Should we stop an activity?

Complete:

We need to decide whether to _ by _ because ___.

Then write what is not being decided.

A vague question such as "How do we grow?" may hide separate questions about customer fit, channels, pricing, capacity and cash.

Create two columns.

Known: observed behaviour, financial records, commitments, customer evidence and verified external information.

Assumed: interpretations, forecasts, untested beliefs and missing information.

For every important assumption ask:

What evidence would make us change our mind?

Do not promote an assumption to a fact because it has been repeated internally.

At minimum consider:

• continue as is;
• change the current approach;
• run a smaller test;
• defer the decision;
• stop the activity.

For each option record:

Expected benefit: what could improve?

Cost: what does it consume?

Risk: what could go wrong?

Opportunity cost: what cannot be done instead?

Reversibility: how difficult is it to undo?

Evidence needed: what would reduce the largest uncertainty?

Ask what currently limits the outcome.

Examples:

• not enough qualified demand;
• poor conversion;
• delivery capacity;
• cash timing;
• product reliability;
• founder decision bandwidth;
• regulatory or contractual constraint.

A decision that does not address the current constraint may create activity without changing the result.

When uncertainty is high, a smaller test may be better than a large commitment.

Write:

Hypothesis: what must be true?

Test: what can we do now?

Cost limit: what are we willing to spend?

Time limit: when will we review it?

Signal: what result changes our confidence?

Decision rule: continue, change, stop or test again.

Do not use a small test when the decision is irreversible and the test cannot produce relevant evidence. In that case, identify the diligence required before committing.

Record:

• decision;
• owner;
• evidence used;
• assumptions;
• alternatives considered;
• trade-offs accepted;
• next action;
• review date;
• trigger that would cause reconsideration.

This creates a record that can later be compared with what actually happened.

Suppose a founder is considering a new sales channel.

Decision: whether to add the channel in the next 30 days.

Known: current sales are constrained by a small number of qualified opportunities.

Assumption: the new channel can produce qualified buyers at acceptable acquisition cost.

Option A: launch broadly.

Option B: run a narrow test.

Option C: improve the existing channel first.

Test: run a bounded pilot with a defined customer segment, budget and success signal.

Review: compare qualified opportunities, conversion, acquisition cost, delivery capacity and cash impact.

The framework does not tell the founder which option to choose. It makes the choice explicit and makes the evidence requirement visible.

At the review date ask:

1. What happened?
2. Which assumption was wrong?
3. Which evidence was stronger or weaker than expected?
4. What did the decision cost?
5. What did we learn?
6. Should the original decision remain in place?
7. What changes now?

A good decision process includes the review, not just the moment of choice.

This is SOE editorial synthesis informed by decision-making and decision-rights principles. It is a reasoning structure, not a guarantee of better outcomes.