decision rule

A decision rule is a simple if-then statement you write down before you run a test, launch a pilot, or make an investment decision:

If [metric] exceeds [threshold], then [action A]. Otherwise, [action B].

The threshold is the line between "change course" and "stay the course." Two important properties:

1. 1)You set it before you see results. This prevents post-hoc rationalization - the human tendency to move the goalposts once you are emotionally invested in an outcome.
2. 2)"Stay the course" is not the same as "the current approach is good." It means you did not find enough evidence to justify the cost and risk of changing. Your base case might still be mediocre - you just do not have grounds to bet on the alternative yet.

In formal terms, this maps to the logic of [UNDEFINED: hypothesis testing]: you start by assuming the status quo holds (your base case), define a threshold that reflects how much evidence you need before abandoning it, then compare your observed result against that threshold. If the result clears the bar, you reject the status quo and act. If it does not, you fail to reject - meaning you lack sufficient evidence, not that the status quo is proven correct.

Every operator makes dozens of go/no-go calls per quarter: ship a feature or kill it, hire or hold, expand into a market or wait. Without a decision rule, three things go wrong:

• •Meetings become debates. Without a pre-agreed threshold, every stakeholder interprets the same data differently. The optimist sees signal, the pessimist sees noise, and you burn an hour reaching no conclusion.
• •Sunk costs creep in. If you spent $30K on a pilot and the results are ambiguous, the temptation to "give it one more month" is enormous - unless your Exit Criteria were locked before the spend.
• •P&L impact compounds. A bad $5K/month decision left running for six months because nobody defined "when do we stop" costs $30K. A decision rule would have killed it at month two.

The rule itself is cheap. Writing "we pull this campaign if Cost Per Unit acquisition exceeds $18 after 1,000 impressions" takes five minutes. Not writing it can cost months of wasted Budget.

Building a decision rule takes four steps:

1. State your base case

What does the world look like if you do nothing? This is the benchmark from your prerequisite work. For example: "Our current checkout converts at 3.4% and generates $12.50 Revenue per visitor."

2. Pick your metric and threshold

Choose one metric that captures the outcome you care about, and set a number that justifies the cost of changing. The threshold should reflect:

• •Implementation Cost of the change (if it costs $10K to rebuild the checkout, a 0.5% lift on $12.50/visitor needs a LOT of volume to pay back)
• •Risk appetite (how much downside can you absorb if the change backfires?)
• •Time Horizon (a small lift matters more if you have 100K visitors/month than 1K)

3. Define the sample or observation window

How much data do you need before the result is meaningful? Running a test for two days on low traffic tells you almost nothing. You need enough observations that random variation will not fool you. Common mistake: stopping a test early because it looks good. That is exactly the rationalization the rule prevents.

4. Commit to the action

Write the full rule: "If Revenue per visitor on Variant B exceeds $13.75 (a 10% lift over our $12.50 base case) after 2,000 visitors per variant, ship Variant B. Otherwise, keep the current checkout and revisit in Q3."

The rule has two branches - one for each outcome. Both branches are actions, not open questions.

Use a decision rule whenever you are about to spend money or time to learn something:

• •A/B tests and pilots - the classic case. Define the lift threshold and sample size before launch.
• •Hiring decisions - "Hire a second sales rep if Pipeline Volume exceeds 2x current capacity for 3 consecutive months." Otherwise you are hiring on vibes.
• •Capital Investment gates - "Proceed to Phase 2 if Phase 1 ROI exceeds the Hurdle Rate of 15% on $50K deployed."
• •Kill decisions - "Shut down this product line if it fails to reach break-even within 9 months of launch." This is the hardest rule to honor, and the most valuable.

You do not need a formal decision rule for every small call. Use it when the cost of being wrong is material to your P&L, or when multiple stakeholders need to agree on what "good enough" looks like.

A decision rule is the natural next step after building a base case. The base case gives you the benchmark - what does the world look like if you change nothing? The decision rule tells you how far reality must deviate from that benchmark before you act. Without a base case, your threshold is arbitrary; without a decision rule, your base case is just a number sitting in a spreadsheet.

Downstream, decision rules feed directly into Sensitivity Analysis (what happens to your threshold if your assumptions shift?), Exit Criteria (decision rules applied to ongoing commitments - when do you walk away?), and Expected Value calculations (where the threshold is derived from the probability-weighted outcomes of acting versus not acting). They also connect to risk appetite - two operators looking at the same data might set different thresholds because one can absorb more downside than the other. The rule makes that difference explicit rather than leaving it as an unspoken disagreement in a meeting room.