Lessons from the Small Bets Cohort (Part 2/6)

Session 2 of the cohort starts with an important question:

In a world so dominated by randomness, how should you acquire knowledge?

How can you know whether you’re gaining insight or just reaching false conclusions from random noise?

Survivorship bias

We start with examples of founders who found success after many years of focused effort on a single project, who then conclude that persistently focusing on one thing is the secret to success.

Daniel proposes that while this is good predictor of success in the predictable world, applying it to the stochastic world is mistaking noise for signal.

What about all those who persisted and focused just as much, maybe even more, but didn’t succeed?

More Biased Advice

• “Just focus on solving a real problem.” • “Just build something useful.” • “Just follow your passion.” • “Just make your product 1% better every day.” • “Just obsess on your customers.” • “Just execute your best idea.” • “Just keep showing up.”

Just, just, just.

Daniel presents this as advice that is good enough in the predictable world, but not enough in the stochastic world.

The problem is mostly in the just. There is no recipe for success in the stochastic world, so while these are good things to do, they aren’t sufficient.

The definition of insanity

“The definition of insanity is doing the same thing over and over again and expecting a different result”

This quote sounds so truthy I never questioned it.

But this “rule” applies to a predictable world. In a stochastic world this is inverted. Expecting things to be predictably repeatable becomes insanity.

Because of the powerful and unpredictable random forces of the world, there’s no such thing as “doing the same thing.”

Even if you think you’re doing things the same, the world around you is different every time, in ways that are opaque to you and outside your control.

Probabilistic Knowledge

Daniel proposes that the best lessons to take away when we see a success in the stochastic world is to try to replicate as many of the environmental factors of that success as possible. He calls this “Probabilistic Knowledge”.

The idea is that we can’t fully understand why anything succeeds in the stochastic world, but we don’t need to. The more we closely we replicate the various factors around that success, as a way of improving your odds of success.

It’s not because we know those factors are necessarily important for success. In fact, even if we do our best and replicate as much as possible, it’s still no guarantee at all of success.

But it’s the best we can do to improve our odds in a world we can’t fully understand.

For example, he chose to sell his products with the default Gumroad landing page rather than making a custom landing page, because it’s already been proven to work in the market.

He suggests looking at examples of things that have worked and copying many parts of them.

Being novel and creative can actually backfire.

But what about creativity?

At this point in the cohort I felt my heart sinking.

Does this mean I just need to supress the part of me that likes to be creative and copy everyone else?

Do I even want to make stuff if it has to be unoriginal in order to succeed?

I asked Daniel about it in the chat.

He responded that you can still be creative, but you’re better off saving it for the product itself, rather than the marketing.

He also mentioned that in general he starts more conservative and then adds the creative stuff in small increments if things go well. This way he has a baseline to compare to, and can see whether the creative stuff is actually making things better, or just backfiring.

Negative visualization

Before starting a project, you should do a negative visualization of all the worse things that could happen, and how you will mitigate them.

Imagine if no one buys it.

Can you scope it down so that you don’t end up wasting too much time/resources?

_What if they buy it and hate it? _

Can you offer free refunds to alleviate the fear of this?

Think of your own worst case scenarios and and mitigate before you accidentally take on more than your risk tolerance.

To thrive, you must first survive

A few more bits of advice:

Don’t take on a project where failure will put you in your “game over” state. Be willing to sacrifice some of your upside in order to limit the downside.

Go for low-hanging fruit. Resist the grandiose stuff, go for small wins that build on each other. Each small-win gets you farther from the game-over, and improves the odds of your next project.

Alongside this, try to have a sense of urgency. I know I can always fallback to a 6 figure developer job, but Daniel proposes that getting comfortable with your fallback will prevent you from activating your full energy.

Small wins are better than failures

While Silicon Valley glorifies those who shoot for the moon and fail at something big, Daniel isn’t a fan.

He contends that failure is a very expensive way to learn, while being far less educational than small wins.

A small win, even one that seems inconsequential, gives you something that you can learn from and expand on, whereas a total failure just tells you that what you did wasn’t good enough.

A string of failures can also push you into a game-over state. How many big failures can you sustain before you get psychologically defeated and give up trying to win in the stochastic world?

I might send a newsletter sometime.