Big Bets

A ‘Big Bet’ is a rapid push into a new market space, typically championed by an executive and led by experienced engineers. While the term ‘bet’ suggests a risk, these initiatives often fail and come with hidden costs, like draining morale and neglecting other key products.

I witnessed multiple big bets at Square and had the misfortune of being part of a couple. I worked on the Square Wallet team, which was Square’s first attempt to create a B2C product. Later, I got picked to implement the doomed “Square 275” feature where we charged merchants a flat fee for unlimited credit card processing. Both were big bets mandated by the CEO, bypassing the best practices of product research.

I saw the same pattern at Gusto¹ when we tried to expand from B2B into B2C with features that employees would appreciate. My CTO once asked me to lead “Modern Bank”, a flexible payment schedule for employees. I recognized the signs of a big bet and politely declined, exaggerating how much I was needed in my current role.

Anything to avoid joining a big bet.

The properties of a Big Bet

You can spot a big bet by its three qualities:

1. The executives talk as if there’s only execution risk, not strategic risk
2. It’s staffed as a mature product, even in it’s earliest stages
3. It’s important to the larger company strategy

This is a terrible project to lead. Sure, you might get lucky. More likely you’re about to spend a lot of company money failing directly in front of your executives on something they’re convinved can only fail if the execution sucks. Which is you.

The problem with Big Bets

All product development is risk, but we have ways to reduce that risk. We’ve built a fierce and exhausting discipline among product leaders to do just that: Business strategy that informs product strategy, supported by market research, product research, user research, UX research, prototyping, and financial modeling.

A big bet skips steps in the Product Maturity Lifecycle. If funding something as if it will be successful made it so, YCombinator would write checks for $100M to everyone.

Big bets often try to target customers the company has little experience with (or legally can’t sell to). For example, Square excelled at serving sellers but the Square Wallet targeted buyers². And Gusto’s employee features relied on using the employer relationship as a mediator, awkwardly triangulating Gusto between an employer’s needs and their employees'.

Sometimes, a big bet is a solution to a poorly-diagnosed problem. When Square was a tool for garage sales, Jack Dorsey’s product intuition was stellar. But as Square moved up to brick-and-mortar stores his intuition didn’t work as well. The underlying problem was that a key company resource (the CEO’s intuition) was no longer sufficient. There are cheaper ways to address this than redirecting the product roadmap to leverage his gut fully.

In 2018, Gusto’s leaders didn’t have an answer they liked to “why aren’t you innovating in the payment space?” and their roadmap of US payroll features was moving very slowly. The solution to a sluggish roadmap is usually to extract an internal product platform that accelerates feature development, not a side quest into territory where the company is unlikely to win.

Big bets can also be a covert tactic to retain pet engineers. If someone is a flight risk and executives want to keep them engaged they sometimes end up on (or leading) a big bet that’s off to the side of the product roadmap. This feels exciting at first — a startup-within-a-startup means you get to leave your job but keep vesting the equity, right? In reality, this divides the engineering team. One group is left struggling with under-resourced real products while the other is set up to fail in the spotlight.

What to do instead of Big Bets

Maybe you’ve seen a ‘big bet’ pay off but as I tried to think of any I came up with a list of regular successful products. Square’s customer management features and then CashApp, Gusto’s time tracking features and state-level agency integrations. The longer my list got I realized that every successful product I could remember had the same, boring, wonderful pattern:

1. They explored a market opportunity with a prototype.
2. A product owner championed it with clear milestones, metrics, and reasonable staffing.
3. It only matured in budget and executive attention as it grew in maturity.

In other words, modern product development work by professionals.

Reflecting on this I realize how allergic I am to ‘big bets’. If something is worth staffing then there must be some articulable plan for how it’ll address each of its strategic risks. And if the plan doesn’t work out we needn’t throw good money (and senior engineers) in after bad.

Avoid the other extreme, too

I should mention that the polar opposite of a big bet is just as bad. It’s a project that cannot proceed until every piece of it is proven. Leaders blocking forward progress until there’s better data, for every hypothesis to be proven, for exhaustive market testing before trying anything real. It sounds safe but, just like an overly ceremonial development process, it’s too easy to forget that teams either ship or die. And the same goes for companies.

One way to stay somewhere in the middle of these extremes is to measure whether real product value is actually getting shipped.