Why a 300 year old theorem matters to a one person business
I didn’t learn Bayes theorem in a statistics class and then go looking for a use for it. I ran into the problem it solves first: I’d see a number move on a dashboard, feel a jolt of “something’s wrong” or “something’s working,” and act on that feeling before asking whether the number was actually telling me what I thought it was telling me.
Bayes theorem is a formal way of doing something you already do informally: updating what you believe when new evidence shows up. The formula looks intimidating, but the idea behind it is not. It says your belief after seeing evidence should depend on three things: what you believed before, how likely that evidence is if your belief is true, and how likely that evidence is overall, including if your belief is false. Skip any one of those three and you can talk yourself into conclusions the data doesn’t support.
For a founder, that shows up constantly. A metric spikes. A test “wins.” A customer looks like they’re about to churn. The question isn’t whether the number moved. It’s whether the number moving actually changes what you should believe, and by how much.
The three pieces, in founder language
Strip the Greek letters out and Bayes theorem has three ingredients.
Your prior. This is what you believed before you saw the new evidence, based on everything you already know about your business. If you’ve run your product for two years and your monthly churn has hovered in a narrow band the whole time, that history is your prior. It doesn’t mean next month can’t be different. It means “different” needs real evidence, not just a bad-looking week.
The likelihood. This is how likely the new evidence is, assuming your belief is true, compared to how likely it is if your belief is false. A test result that a true winner would produce 95% of the time, but a coin flip would also produce 40% of the time, isn’t nearly as convincing as it sounds.
Your posterior. This is your updated belief after combining the prior with the likelihood. It’s not “the data proved X.” It’s “given what I already knew, plus what I just saw, here’s where I land now, and here’s how confident I am.”
The mistake most solo operators make (I’ve made it plenty) is skipping straight from evidence to conclusion and never bringing the prior into it at all. You see one good week and treat it as proof, when your own history should have told you one good week happens periodically even when nothing changed.
A worked example: the churn risk flag
Say you build or buy a tool that flags customers as “high risk of churning” based on usage drop-off. Suppose the tool is genuinely decent: it correctly flags 80% of customers who actually go on to churn, and it only misfires on 10% of customers who were never going to churn.
Those sound like good numbers. But whether a flagged customer is actually likely to churn depends heavily on how common churn is in the first place, which is exactly the piece a raw accuracy number leaves out.
Imagine your monthly churn rate is 5%. Out of 1,000 customers, 50 are true churn risks and 950 are not. The tool correctly flags about 40 of the 50 real risks (80% of 50). But it also misfires on 10% of the 950 who were fine, which is 95 people. So your flagged list has roughly 40 real risks and 95 false alarms, about 135 people total. Even with a genuinely useful tool, most names on the flagged list were never actually at risk.
This is the same math behind why rare-disease screening tests produce a lot of false alarms even when the test itself is accurate. The lesson for a founder isn’t “don’t use churn flags.” It’s: don’t treat “flagged” as “confirmed.” Use the flag to decide who to look at more closely, not who to panic about. The rarer the thing you’re detecting, the more false alarms a good detector still produces, purely from the base rate. That’s Bayes theorem doing its job, and it’s a specific, learnable reason to distrust your gut reaction to an alert.
A worked example: a small A/B test
Now take the opposite situation: a test that looks like a clear win. You try two versions of a signup page. Version B converts better over the test period. It’s tempting to declare a winner and move on.
Before you do, ask what your prior was. If your two versions are nearly identical (say, a headline reworded slightly), your prior should be that they probably convert at close to the same rate, because most small wording changes don’t move conversion much. A modest difference over a small number of visitors is exactly what you’d expect to see from ordinary noise even if the two pages perform identically. The evidence needs to be strong enough to overcome that prior before you should update your belief much.
If instead your test is something with a much larger, more plausible effect (removing a paywall step entirely, say), your prior allows for a bigger real difference, so the same evidence is more convincing.
This is why “it won by a bit, on a small sample, and it’s a subtle change” and “it won by a lot, on a decent sample, and it’s a structural change” deserve very different amounts of trust, even if both technically show version B ahead. Bayes theorem is the formal reason those two situations aren’t equally believable. I’ve killed tests I initially got excited about once I asked myself honestly what my prior should have been.
What this changes about how you read your own dashboard
Once you start thinking this way, a few habits follow naturally.
You stop treating single data points as verdicts. A metric that’s genuinely new information (a launch, a pricing change, a channel you’ve never tried) deserves more weight than one week of normal variation in a metric you’ve watched for years.
You ask “how rare is the thing I’m trying to detect” before trusting an alert. Rare events produce more false positives than intuition suggests, no matter how good the detection method is.
You size your confidence to your sample. A result from 40 visitors and a result from 4,000 visitors are not the same kind of evidence, even if the percentage lift looks identical.
You keep updating instead of anchoring. Your posterior belief after one week becomes your prior for the next. Bayesian thinking isn’t a one time calculation, it’s a habit of continually folding new evidence into what you already knew, rather than resetting your beliefs from scratch every time a new number comes in.
What Bayes theorem can’t do for you
It’s not a substitute for judgment, and it won’t tell you what your prior should be, that’s still on you, built from your own experience with your own business. It can’t fix a bad measurement, if your tracking is broken or your sample is biased, updating your beliefs correctly on top of bad data still gets you a wrong answer. And it doesn’t remove uncertainty, it just helps you reason about it more honestly instead of overreacting to noise or underreacting to a real signal. None of this promises a particular result for your business. It’s a way of thinking more clearly about the numbers you already have.
If you want more of this kind of plain English walkthrough of the metrics and methods behind running a one person business, take a look at the rest of what we cover on the home page.
Get new guides and videos first — join the Telegram channel.