A founder story helps other people understand your company, but once you use it to make decisions, it can start filtering the evidence you see. The same account can record what happened without establishing why it worked or what you should do next. The narrative defense keeps those three questions apart, so you can keep telling the story while you test the claims inside it.
Suppose your story is, “We grew because we kept the product simple.” It sounds like one conclusion. It contains at least two: the company grew, and simplicity caused that growth. A roadmap built on the sentence may add a third: refusing the next feature request will protect that growth. A record of the first does not settle the other two.
Chapter 8 of The Evidence-Aware Life offers six moves for auditing a narrative. Applied to your own company, they begin with a concrete question: which claim in your story is making the next decision for you?
Why do good stories beat data, and how do founders guard against their own?
A story gives events an order and a meaning. Put a difficult decision immediately before a recovery, and the sequence can imply that the decision caused it. Chapter 8 asks you to inspect that added explanation. Every event in the account could be documented while the connection between them remains uncertain.
Stories do not always beat statistics. A 2020 meta-analysis by Traci Freling and colleagues examined 61 papers comparing anecdotal and statistical information. It reported a persuasive advantage for anecdotes in contexts associated with stronger emotional engagement, such as severe threats, health issues or decisions for oneself, and for statistics when engagement was relatively low. The authors caution that their analysis cannot definitively establish why those differences occurred.
That finding concerns persuasion. It does not tell you which account was accurate or whether a founder’s preferred explanation is correct.
For your own story, inspect both its appeal and its support. Perhaps the explanation vindicates a lonely decision or gives a difficult year a satisfying ending. Name that feeling, then ask which claim it makes easier to accept. Pride in the work can be justified while the cause of its success remains open. The guard is to keep the events, state the inference, and look for evidence that could distinguish it from a credible alternative.
When does a founder story become a decision rule?
A founder story is your account of the company’s origins, choices and purpose. It is useful when it helps other people understand what you care about and why you chose this work. It becomes a risk when the same storyline starts deciding, inside the company, which evidence you take seriously. The narrative defense separates the story you tell from the factual and causal claims you test before a decision.
Consider how you answer an awkward customer request. “We choose to serve a narrower market” states a business choice. “Customers never need this capability” makes a factual claim that customer evidence can challenge. Neither sentence follows automatically from “we have always valued simplicity.”
Notice whether your explanation can survive every possible outcome unchanged. If growth proves your strategy and falling growth proves customers need more time to understand it, write down what result would count against the explanation. If none would, the sentence is not yet useful as a testable claim.
If questioning the explanation feels like questioning your worth, identity fusion vs commitment addresses that adjacent concern. Here, keep the question on the decision: what evidence would you require if another founder offered the same account?
Use the same standard when you tell the story to colleagues, customers or investors. Its factual limits travel with it.
Worked example: does simpler onboarding justify refusing a feature?
The company, records, requests and proposed checks in this example are hypothetical. A software founder tells the latest quarter’s story in three sentences:
We removed the advanced options and made the product simple. More new teams completed their first project because we trusted that instinct. We should keep refusing requests for advanced features.
The founder is about to close a request for an optional approval step without investigating it. The story makes refusal sound like a lesson already learned. The team first sets out the record for this exercise:
| Recorded event | Explanation or lesson added by the founder |
|---|---|
| At the start of April, advanced options were removed from onboarding. | Removing complexity caused the improvement. |
| At the same time, a new referral partner began sending teams already familiar with this kind of workflow. | The change in arriving customers was incidental. |
| A larger share of April’s new teams completed a first project within seven days than March’s teams. | Future advanced features would undermine that progress. |
Both months use the same definition of completion, and every team has seven days of follow-up. The improvement is a fact of the hypothetical record. Its cause remains open: simpler onboarding, more experienced arrivals, or both could have contributed.
The first check concerns the past. Compare completion before and after the change within each existing acquisition source. Keep the numbers of new teams visible alongside the completion rates, and check whether their prior experience also changed.
An improvement among those existing sources would weaken an explanation based solely on the new referral partner. If the overall gain comes chiefly from that partner’s experienced teams, customer mix deserves more weight. Neither pattern isolates the product change from everything else that happened. If prior experience was never recorded, leave that gap visible.
The second check concerns the proposed feature. An optional approval step used after a first project differs from advanced options imposed during setup. Ask which customers need it, what task it serves, and where they would encounter it. Even evidence that simpler onboarding helped would not settle whether this particular capability belongs elsewhere in the product.
The founder can now write:
First-project completion improved after we simplified onboarding and added a referral partner. We have not separated their contributions. That improvement does not yet justify rejecting an optional approval step.
The next action is bounded: the product lead reviews the acquisition records and approval requests by Friday, before the founder decides whether to investigate the feature further. The example supplies no result from that review.
Case study vs evidence examines how far one success can support a wider claim. Here the immediate problem is the founder’s own account turning an unresolved cause into a rule for the roadmap.
How do you run the narrative defense?
These six moves adapt chapter 8’s audit to a company story shaping a decision. Keep the original wording beside your notes.
1. Notice the story and name its claim
Find the struggle, turning point and resolution. Then write the conclusion you are about to act on. In the example, a simpler setup becomes a reason to refuse a feature. Name the assumption connecting those statements so you have something specific to check.
2. Separate events from interpretation
Make two columns: supported events with sources, and explanations. Retain dates, sequence, definitions and uncertainty. A release log records a change; its effect needs separate support. A customer’s report belongs in the record as that customer’s report, with its context intact.
3. Name the emotional hook
Write what you gain from the explanation being right. You might feel vindicated for holding your course under pressure. Acknowledge that, then identify the claim the feeling makes easier to accept. Pride cannot tell you how the old and new onboarding flows compare.
4. Test the satisfying fit
Look for a relevant observation the account struggles to accommodate. Which customer, period or change has disappeared from the telling? Inspect inconvenient records with the same care as supportive ones. Clear storytelling is no reason to reject an explanation; missing support is a reason to keep checking.
5. Build a credible alternative from the same facts
Preserve the observed events. Propose another explanation and name something the two accounts predict differently. An imagined rival does not deserve equal weight merely because you wrote it down. Several causes may operate together, and you should not invent a second alternative if only one is credible.
6. Write the supported conclusion and next action
Set aside the persuasive flourishes while retaining sources and context. State what the record supports, what remains unresolved, and one useful next check. Give it an owner and a date. If the decision must come sooner, record what you can justify doing with the evidence available.
The result should be inspectable by someone who did not hear the pitch. If the story reveals several other assumptions worth examining, the belief-audit exercise helps you collect them and choose one for further attention.
How do you stop the ending from rewriting the beginning?
In Baruch Fischhoff’s hindsight experiments, receiving outcome information increased how likely the reported outcome was judged to have been and changed which details in the passage seemed relevant. Participants were largely unaware of that influence. These were experimental judgments, not a measured error rate among founders.
Chapter 8’s practical response is to reopen a dated forecast, meeting note or draft. What possibilities were still open? What did you expect, and which reasons did you record? Later evidence may help explain the result, but it cannot become something you knew earlier.
For the hypothetical founder, reopen the note proposing simpler onboarding. Did it predict easier setup, acknowledge a trade-off, or describe an attempt to reduce maintenance? Preserve the original reasoning beside today’s explanation. A successful change does not need to become a story about having known all along.
What can this exercise establish?
The audit gives you a claim to inspect, its support and a next check. The original explanation may hold up. Several explanations may remain, or the records may be too thin to distinguish them. Missing support alone does not prove the story false.
The book presents this as a proposed practice. Neither the cited research nor the hypothetical example establishes that this founder exercise improves decisions or business results. Checking one source today can narrow a claim without settling its cause.
Reserve the work for stories carrying a consequential choice. Apply the same scrutiny to a cynical account that makes every success look accidental. That explanation needs support too.
Try this today
Write your company story in three sentences, as you would tell it to a new colleague. Underline every factual claim, including any claim about why something worked or what customers will do next. Keep choices about what matters separate from predictions about what happens.
Pick one underlined claim shaping a decision this week and check it as if a stranger had said it. Open a dated record that could support or challenge it: a release note, customer conversation, forecast or product report. Read the record before rewriting your sentence.
Leave yourself these five lines:
Claim I am using to justify a decision:
Record I opened and what it actually supports:
Plausible alternative that preserves the recorded events:
Observation that would help distinguish the explanations:
Sentence I can support now; next check, owner and date:If you cannot obtain the record, write “not checked” and name where you will look next. Record when no credible alternative fits. If the record supports the event but leaves the cause open, narrow the sentence you take into the next meeting. For the example above, “completion improved after we changed onboarding” is a claim you can support while investigating why.
Cite this:Narrative defense vs founder story: when your own story decides for you.Len P. van der Hof. https://lenvanderhof.com/en/blog/narrative-defense-vs-founder-story/ ·