← All entries
·11 min read·evidence-based decisions

Make Evidence Based Decisions: A 7 Field Decision Log for Founders

Use a seven field decision log to make evidence based decisions. Log each bet with a probability and falsification rule, review outcomes, and learn...

On this page

Evidence-based decisions, for a founder or product lead, means recording each significant choice as a bet before you know the outcome: the hypothesis, a probability, the trade-offs you’re accepting, and a date to check the result. This is decision journaling, built on Annie Duke’s “thinking in bets.” The payoff is calibration. You separate whether you decided well from whether you got lucky, and over time you learn which of your confident calls actually deserve that confidence.


TL;DR:

  • Recording decisions as bets with assigned probabilities and falsification criteria helps reduce hindsight bias and encourages honest calibration over time.
  • A minimal decision log should include seven fields: decision summary, context, options, rationale, assumptions, falsification criteria, and expected outcome with review date.
  • Logging only high-impact, hard-to-reverse choices within 24 to 48 hours prevents noise and maintains decision accuracy, especially by avoiding after-the-fact entries.
  • Regular review practices, from daily capture to annual pattern scans, help small teams identify biases and improve their judgment accuracy.
  • Using dedicated tools like Betlog can streamline this process, ensuring decisions are revisited systematically and that actual outcomes are compared to initial confidence levels.

Betlog
Make Better Bets With Betlog
Record your reasoning, confidence, trade-offs, and outcomes before hindsight can rewrite what your team knew.
Visit Betlog

Why Treat Decisions as Recorded Bets?

Most teams judge decisions by how they turned out. That habit, called resulting, is the fastest way to learn the wrong lesson. A pricing hike that coincided with a lucky viral mention looks brilliant in hindsight. A well-reasoned hire that didn’t pan out looks reckless. Neither verdict is accurate, because outcomes depend on the quality of the reasoning and on luck, and memory conveniently forgets the difference.

Two related failures make this worse:

  • Hindsight bias: once you know the result, your brain rewrites what you “always knew” would happen.
  • Motivated reasoning: teams credit wins to skill and blame losses on bad luck, protecting egos instead of learning anything.

A written record with a stated probability and a falsification condition, set down before the result arrives, gives you something neither bias can quietly edit. It’s an objective anchor a small team can point back to when memory starts revising the story.

Minimal Decision-Log Template and Capture Rules

A decision log doesn’t need to be elaborate. Practitioner templates converge on five to seven fields, and adding more than that is the fastest way to kill adoption. Here’s the minimum that actually holds up:

  1. Decision summary — one sentence, plain language.
  2. Context — what forced this call now.
  3. Options considered — the two or three real alternatives, not a brainstorm dump.
  4. Selected option and rationale — why this one, briefly.
  5. Key assumptions — what has to be true for this to work.
  6. Falsification criteria — what would prove you wrong.
  7. Expected outcome, confidence, and review date — a number and a date, not a vague hope.

Not every choice deserves an entry. Log only one-way-door or cross-team decisions that are hard to reverse or affect people beyond you. Skip the routine calls entirely, or the log turns into noise nobody reads.

Timing matters as much as content. Write the entry within 24 to 48 hours of committing, before the outcome starts shaping your memory of why you chose it, and keep each entry short enough that it doesn’t become its own project.

Decision log timing and field count comparison

Pro Tip: If an entry is taking longer than filling out a short form, you’re overbuilding it. A minimal decision log with five plain fields beats a fifteen-field questionnaire nobody finishes past week two.

How Do You Turn Confidence Into a Probability?

“I think this will work” tells you nothing you can check later. That’s the whole idea behind calibration, and it’s what separates a bet from a hunch.

The check itself is simple. Once you’ve closed a batch of entries, group them by stated confidence and compare against actual outcomes:

  • Bets logged at 90% confidence that only won half the time signal overconfidence, usually from skipping the falsification step.
  • Bets logged at 60% that won nearly every time suggest you’re underselling your own judgment, maybe from habitual hedging.
  • A clean match between stated probability and win rate across a batch is the sign your gut and your evidence are finally talking to each other.

Short, well-scoped decision records also pay off in a way founders underestimate. Teams that started writing 200 to 400 word entries recovered roughly 15 to 20% of meeting time they’d previously spent re-arguing choices that were already made.

When a gap shows up, don’t just note it and move on. Re-weight the kind of evidence that misled you, tighten a pre-commitment rule (a Ulysses contract, in Duke’s terms) for that category of decision, or flag it for the next team review.

A Worked Example: Pricing Change From Bet to Post-Mortem

A ten-person SaaS company wanted to raise its starter tier by $10 a month. Here’s how the entry looked, filled out the day the change shipped:

  1. Decision: raise starter plan from $29 to $39/month for new signups.
  2. Context: churn is flat, support tickets show price isn’t the top objection, competitors sit higher.
  3. Options: keep pricing flat, raise $10, raise $15 with a grandfather clause.
  4. Rationale: $10 is a small enough jump to test without a major backlash risk.
  5. Assumption: new-signup volume won’t drop more than 10%.
  6. Falsification: if signups fall more than 15% for two straight weeks, revert.
  7. Expected outcome: 65% confidence that net revenue rises within 60 days. Review date: day 60.

The honest post-mortem: the bet won, but a chunk of the lift came from an unrelated marketing push that landed the same week, not the price change alone. Recorded verdict: Won, partial luck. That distinction, made possible only because the falsification criteria were written down first, is what actually teaches you something about your pricing instincts.

Common Pitfalls That Kill a Decision Log

The template above is simple. Sticking with it is where most teams fail. Watch for these:

  • Over-logging. Writing an entry for every small choice buries the decisions that matter under noise nobody has time to review, which defeats the entire point of the triage rule.
  • Writing after the fact. An entry drafted once the outcome is known isn’t a bet anymore, it’s a story dressed up as one, and hindsight bias will quietly edit every “assumption” you claim you had.
  • Skipping falsification. A decision without a stated condition for being wrong can never be closed honestly. It just gets a shrug.
  • Skipping the review. An entry with no scheduled follow-up becomes a “zombie decision,” sitting in the log unresolved and teaching nothing.

Pro Tip: Set the review date the same moment you write the entry, not later. A follow-up you have to remember to schedule is a follow-up that quietly disappears.

How Often Should You Review Your Decision Log?

A log only builds calibration if someone actually revisits it on a schedule. The lightest sustainable version looks like this:

  1. Daily or weekly capture. Log entries as they happen, keeping each one short.
  2. Monthly surface check. Pull up entries with a review date in that window and mark them Won, Killed, or Inconclusive.
  3. Quarterly pattern scan. Spend 30 to 90 minutes looking across closed entries for a bias, like consistently overconfident growth bets.
  4. Annual corpus review. Reread the full year’s entries in one sitting. Patterns that never show up quarter to quarter often surface only at this scale.

A quick pre-mortem before a new high-stakes bet, asking “what would make this fail,” belongs in this same cadence rather than as a separate ritual.

Why I Trust This Practice for Small Teams

I’ve watched enough founders confuse a lucky quarter with good judgment to believe the resulting problem is real, not academic. The fix isn’t more analysis. It’s a habit of writing the bet down before you know how it lands.

Why I Trust This Practice for Small Teams — overview diagram

The stages Idea, Prioritized, Running, Reviewing, Decided, exist because a decision without a status is a decision nobody revisits. The minimal fields aren’t a design shortcut; they’re the fewest fields that still force a falsification sentence and a probability, which is the part that actually changes behavior.

If you’re starting from zero, don’t roll this out to the whole team on day one. Log your own bets solo for a couple of weeks, protect the honesty of the entries even when a verdict is unflattering, and only then measure whether your stated confidence matches your actual hit rate.

— Cesar

Try Betlog for Your Next Consequential Call

Betlog is built for exactly the workflow this guide describes: log the bet, state the probability, set the falsification condition, and let the platform hold the review date so nothing quietly turns into a zombie decision. Instead of a spreadsheet you forget to open, entries move through explicit stages, Idea, Prioritized, Running, Reviewing, Decided, and close with an honest verdict that separates skill from luck.

Betlog

If your team is still re-litigating the same calls every quarter, that’s the exact pattern a structured decision journal is meant to interrupt. Betlog runs on one plan at $39 a month or $390 a year, and you can start logging your first bet today to see whether your gut and your track record actually agree.

Sources

For deeper practitioner detail beyond this guide, look at field notes on cutting re-litigation, a breakdown of why product managers keep decision logs, and how teams running advisory or bid work handle capture with BidBlock.

FAQ

What Counts as a Decision Worth Logging?

Log the one-way-door calls: choices that are hard to reverse or affect more than one team, like pricing changes, hires, or roadmap pivots. Routine operational choices create noise and should stay off the log entirely.

How Long Should a Decision-Log Entry Take to Write?

A good entry should take a couple of minutes, not an hour. If you’re spending longer than that, the template has too many fields, and practitioner sources suggest four to six is the sustainable range.

What Is a Falsification Criterion, and Why Does It Matter?

It’s a sentence stating exactly what result would prove the decision wrong, written before you know the outcome. This single field is what turns a decision into a testable hypothesis instead of a story you tell yourself afterward.

How Much Does Betlog Cost?

Betlog runs on one plan priced at $39 per month or $390 per year. There’s no tiered pricing to compare, just the single plan built around the decision-journal workflow.

How Often Should a Small Team Review Its Decision Log?

Aim for a monthly check on entries due for review, plus a quarterly pattern scan of 30 to 90 minutes to catch recurring bias. An annual read-through of the full log often surfaces patterns the quarterly scans miss.

Keep readingMore from the ledger
Your move

Put the ideas on the record. Log your next bet.

Create your free workspaceFree while in beta · No credit card required