Working In Bets

”What… happened?” you ask.

You spent months building your product and all you discovered was… you built the wrong thing. Nobody cares. Nobody wants it. Nobody is signing up. You burnt yourself out… and all your cash too. You’re flailing. Maybe you’re proud of what you built, but you still feel like a failure. How much longer can you keep trying before you just give up?

Let me tell you: we’ve all been there.

Protecting your mental state when building a company is possibly the most important thing you can do.

So many people build their companies on blind faith. It’s too easy to mindlessly work in a singular direction for months before you stop and question why it’s not working. Hell, we’ve been there multiple times ourselves. But it’s too late… you’ve already lost your confidence and your momentum.

We spent the first year of Arrows iterating on fruitless ideas with little to show for it. We gave up on multiple ideas, and almost gave up entirely. But now we’ve been successfully building this version, with happy customers and a successful launch. And while it’s still early days… we have conviction things are generally on the right path.

Multiple times while working on Arrows, we said to ourselves “If these next 2 bets fail, we’ll move on to the next idea.” Sometimes that’s what happened and we tried something new. But eventually it worked and we kept going.

What makes a “bet”?

A simple rule: all work, where possible, should be formed into the structure of a “bet”.

Think of a bet as a gamble you’re making with yourself. For the programmers reading this: you can think of “working in bets” as a “try…catch” function for how you spend your own compute cycles.

There are three critical components to how we make bets:

1. A clear win/lose senario. (e.g. Get 3 new paid customers)
2. A short, strict timeframe. (e.g. 2 weeks, ending next Friday)
3. Next steps for both win & lose scenarios, decided upfront. (e.g. If failed, we change the copy & try again; if succeeded, we double-down and go bigger.)

Optional: if it has a dollar cost, pick a firm budget too. (e.g. Max $250/week spent on an ad)

“Bets” force you to define what you’re trying to do, what you’re trying to learn, what you expect to happen and on what timeframe, and what you’ll do next whether or not it succeeds.

The only thing worse than not making forward progress on your company is to not be learning why you’re failing to make progress.

Optimize for rate of learning. By making bets, you’re making a hypotheses and then testing if it works or not. It’s good when bets fail! You want to kill ideas that aren’t working. Tweak some parameters and try again. If a goal continues to fail across multiple iterations, you now have clear points in time to reassess if you’re working on the wrong thing.

These ideas aren’t entirely new. We borrowed a lot from Annie Duke’s Thinking In Bets and Ryan Singer’s Shape Up, and surely were influenced subconsciously by more. But we’ve applied them more specifically to our work, specifically around the early stages of building a startup (sales + marketing particularly, not just product).

Win or lose outcomes

Start with the biggest challenge you have. What’s the number one thing in the way of where you need to go? It should be something that, once you unlock the solution, will make everything else a little easier.

Define what it is and what you need to learn. Turn these into a goal, but make sure the goal is achievable. Confidence is great, but overconfidence can be self-defeating. For example, don’t say “We want 100 paying users next week” if you currently have zero. Aim for 3-5 in 2 weeks. You can always increase the stakes of your bet if the first one goes well, but you need data first. All processes take consistent effort to formalize and ramp up to scale.

Bets must have clearly defined inputs, parameters, and outputs with an obvious win/lose scenario.

A good bet:
“We are going to publish one blog post per week for the next 2 weeks, with the goal of getting 3 customer calls scheduled on average each week.” This is good because everything is defined. The work expected is clear and the goals are very closely related to the work (there aren’t too many leaps from action->outcome). The ability to learn from this bet and improve on it is very obvious, whether or not it succeeds.

A bad bet:
“We are going to publish some blog posts and try to get customers.” This is bad because it’s not obvious what work is involved and what the goal is. You can’t look at this and know immediately if you’ve won or lost the bet, and so it’s also impossible to learn how to improve upon it during a future iteration. You want to define as much as possible without being overly constrictive.

Short, strict timeframes

Notice in the example above that we defined a 2 week long bet, with one blog post per week. It’s easy for people to imagine how much work is involved with writing a single blog post. You also have expectations around publishing one per week. You can’t publish two posts on the last day of the bet and say it “failed”, because you didn’t stay true to the bet as you defined it.

A strict time box keeps you moving forward consistently. Shorter timeframes make it easier to catch yourself before you spend weeks or months working on the wrong thing.

We prefer our bets to be 1-2 weeks long, as it’s a long enough to make progress but short enough that you have to move quickly. It’s also not so short that you’re constantly changing strategies. 3-4 weeks generally is the absolute maximum we’ll do, but those often are mega-bets that have smaller iterations inside.

Instead of setting a personal goal to “blog for the next 6 months to see if we get customers”, you can define success in ~2 week cycles and stair step to an outcome 6 months from now… which, you may discover, might not be blogging at all!

You’ll find you have conviction the entire way that you’re learning, instead of being worn down 3 months into your blogging habit because more people aren’t signing up (partially because you never defined what you expected to happen in the first place!)

The end date is also when you’ll assess your progress against the win/lose outcome and anything you learned along the way. Then you’ll take your predetermined plans for “next steps” and reassess if they’re still the correct plan.

Decide “what’s next” upfront

Last, you should make a plan for what you will do next in each the win and lose scenarios for every single bet. Deciding “next steps” upfront should give you peace of mind and to help maintain a positive attitude that there is always a path forward, even if you lose this bet. If you can’t decide what to try next, then that’s a much bigger issue.

Deciding “next steps” upfront should give you peace of mind and to help maintain a positive attitude that there is always a path forward.

Making future plans reminds us that all discovery-based work like this is iterative and will take many cycles to get right. So by defining the chain of cycles you are able to more properly define iterations, learn from past successful/failed cycles, and more confidently know when to parachute out of a strategy that is consistently failing.

If we take the blog post example from before: you can decide upfront how to tweak the parameters based on each win/lose scenario. But it’s important to only change 1 or 2 parameters for each bet so you can learn what’s working and what’s not. If you change too many things at once, it will be difficult to know why a bet succeeded or failed. These are science experiments, not wild “all-in” changes.

Let’s say that in the “win” scenario of 3 customer calls booked each week, you now want to get more than 3 calls each week. Maybe you write a different format of post, maybe you write 2 posts per week, maybe you change how you promote and market each post, etc. Pick one and iterate again. See what the next outcome is.

In “lose” scenarios, you can try all the same ideas or more, but you should either keep your goal the same or reduce it so that it’s more achievable. Your goal is to find what works, and then build upon that.

Finally, it’s important to know when to call it quits on a strategy. Let’s say you’ve run 3 to 6 cycles of using blogging to get customer calls booked, and you’ve failed all of them. This is a good time to decide that blogging might not work at this stage, and that your efforts should likely be placed on a wholly new strategy.

Remember, the goal is to realize there’s always a path forward. There’s always more work to do. A successful bet is just one step forward… it’s not success in itself. And a losing bet is inevitable, shouldn’t be feared, and should always result in something learned.

You can always restart the bet with new information, new strategy, new parameters, a new expected outcome, etc. Failing on a bet should be quick, so you can reassess the best path forward. Hell, you might fail multiple bets in a row, and that’s fine.

The goal is to notice when a strategy is failing, reassess, and then start again… all while keeping your emotions and psychology in a good state. A failing bet is okay, because you’ve already decided there’s other stuff you can to try after. It’s horribly demotivating to work on something for months only to realize it’s not going well and have to start all over from scratch. We’ve done this multiple times and often flail for around a month as we build up our momentum again.

Staying accountable to yourself

We’ve found it to be extremely helpful to find ways to stay accountable.

1. First, we always write down our bets. Often this is just in Slack or our own notes, so we can never retcon what a bet was and lie to ourselves that it was actually a win. Our bets are always easy to reference.
2. The next most important thing we do is send a monthly advisor update via email. This is an email we send to some folks we know and respect (founders, investors, friends, etc) who know what we’re working on and who occasionally provide help. The number one reason we do this is for the accountability benefits of actually having to do something that’s worthy of sending an email to this group of people every month. (The emails are stored in a text file, and we BCC everybody. It’s that basic. To start it, we just sent the first email without asking and added a note at the top that we’d happily remove people if they wanted. In each email we recap what we planned to do this month, what we actually did, what’s going good/bad, customer quotes, and ultimately we set a plan for the next update.)
3. Last, we record a weekly podcast as cofounders which lasts 12-15 minutes. It’s primarily a quick check-in about what we’re working on each week, and is a pretty honest behind-the-scenes look at what we’re doing to build Arrows. This is been great to have an explicit record of what we’ve tried and how it made us feel. Give it a listen!

Real “bets” we’ve made

At a company that’s early stage like ours, it’s critical all of our work is pointing in the right direction. So we try to focus on “rate of learning” as much as we can, which is why working in bets has been so useful to us.

In the next two posts, we’ll share how we used customer research and sales tactics in conjunction with “bets” to discover and validate the idea for Arrows, ultimately getting preorders based solely on design mockups.

Here are a few real bets in 2020 we made while building Arrows:

• Email >40 people who work in SaaS in the next 2 weeks, with the goal of scheduling 10 customer research calls with customer success team members. If it fails, we will change our email tactics to get people to agree to a call.
• Get 3 companies to preorder Arrows for $100 in the next 2 weeks. If we get 3+ preorders, we can start coding the product. If we don’t get 3 preorders, we need to either A) change our design mockups or B) change our pitch.
• Schedule 3 customer demos in the next 2 weeks from the free Google Sheets template we put on our website. Win scenario: we continue to promote the template in new places to see if we can get 5 demos (Google ads, forums, LinkedIn etc). Lose scenario: we create a new free tool or piece of content and try to get 3 demos again.

It’s important to note that during the research and preorder bet cycles, we regularly discussed as cofounders how many failure cycles we would allow until we moved on to a new idea!

The process forced us to be less emotionally attached to what we were making and to focus on the work itself.

Hopefully that helps you get some ideas for how to start working in bets at your company.

‍