Building Through Uncertainty

Product-building is just not as easy as we think it is, both before and after it’s done. Before we start, it seems easier than it will be. And after we’re done, it seems easier than it was.

Cognitive Biases

Whenever we build something, we face constraints:

We don’t know what problems to solve. And even if we knew that, we don’t know how to solve them. And even if we knew that, we don’t know how well we can deliver those solutions. And even if we knew that, we don’t know how our users will receive them.

Each successive level of uncertainty is dependent on the previous level. Solving the wrong problem endangers the entire project; choosing the wrong solution endangers the implementation; and building a poor quality solution endangers its reception. The uncertainties don’t simply add together independently – they multiply. And on top of it all, we have limited resources and time to figure everything out.

Yet in hindsight, we tend to discount the uncertainty and constraints of the past. You’ll hear this whenever someone says “we should have built Y, not X”, “whoever built X was stupid”, or “whoever built X was lazy.” But the truth is more often that “whoever built X faced constraints that I can’t see right now.” This discounting tendency is known as the hindsight bias.

This bias is usually accompanied by another prevalent bias: the fundamental attribution error. We tend to criticize others’ decisions as wrong, stupid, or lazy; whereas our decisions are “the best we could do, given our constraints at the time”. We see our own challenges better than anyone else’s; similar to how we see all chores that we do, and not all the chores done by our roommates.

The consequences of these biases aren’t superficial: they’re harmful. For fear of “getting it wrong” in hindsight, we’re encouraged to demand full certainty and resources before starting a project. Since resources and certainty are always limited, this demand only wastes time and good will. These biases also encourage us to build everything we could possibly ever need, so that our future critics can’t call us lazy or stupid. But everything we could possibly need is usually much less than what we’ll actually need (and you aren’t gonna need it), so this approach forces us to bear that extra weight unnecessarily. And lastly, these biases hurt team morale. People dislike even the most valid criticism, so critiques stemming from our own cognitive biases lead to the worst of defensiveness and endless counterfactual arguments..

An oversimplification of the point is that we’re unfair to our past selves. But our past selves aren’t completely off the hook…

Less, but Better

When we look at our past, we shouldn’t criticize ourselves for what we didn’t build, but for what we didn’t build well.

There’s an age-old tradeoff between scope, quality, and resources. But on many teams, resources are always constrained. We can’t simply double our team’s productivity overnight, and we can’t double the length of deadlines without significant cost. Therefore, we’re left to choose between scope and quality. Given that choice, the best approach is to build less, but better.

Why not build more, but of lower quality?

First, “less but better” conserves our limited resources. Poor quality doesn’t just take energy from today; it taxes our future as well. We have all these constraints and uncertainty, and poor quality just makes the problem worse. That could actually be a definition of poor quality: that which produces more constraints and uncertainty down the road.

Second, “less but better” helps us to iterate, reducing uncertainty over time. Building through uncertainty is like playing a game of dice with the future. We ship, and the future rolls its dice, resolving some uncertainty from before. With each roll of the dice, we learn which features were worth it and which weren’t. When the “worth it” features are built on solid ground, we’re capable of expanding on them before the next roll. And when the “not worth it” features have limited scope and high quality, they tax us very little going forward. On the contrary, high quality work (and at the very least, our learnings from it) can more easily be repurposed than low quality work.

And third, “less but better” maximizes our chances of capturing potential value. It’s so frustrating when we feel like we’ve found the right problem and chose the right solution, only to botch the implementation and get ambushed by an embarrassing release. Rather than gaining an iteration to collect information and reduce uncertainty, we lose an iteration and our resources get further constrained for the next roll of the dice.

Time-Based Design and Probabilistic Decision Making

All of the best product builders I’ve worked have a secret trick that make all of their design decisions better: they include time as a variable. They make decisions that perform the best over time, adapt the best over time, and fail the best over time.

Naive builders go all-in on the single moment in front of them, and then get sent back to the drawing board when the dice doesn’t roll their way. They don’t account for the inevitable, unlucky rolls of the dice. Instead, they fight to their last breath to convince you that their solution is the most likely to be right, instead of asking themselves “and what will we do if I’m wrong?”

By contrast, skilled builders show how their decision can adapt to any roll of the dice. Like a chess master, each decision is evaluated several moves ahead. The best decisions are those that perform best across all future rolls of the dice. No matter how the dice rolls, it’s no surprise: just look at the contingency plan they included in their proposal.

And contingency plans are best when each step maintains optionality. As Jeff Bezos wrote, decisions can either open two-way doors or one-way doors. You can always walk back through a two-way door if you don’t like what you see. One-way doors aren’t so: you’re stuck with them and are forward to move forward. One-way doors aren’t always avoidable. But under uncertainty, two-way doors buy us the extra dice rolls we need to eventually find our way.

Conclusion

Each team I’ve been on has sought to build long-term, high-value solutions to uncertain problems. Some teams, like design labs, may alternatively seek to build quick and short-lived solutions. And other teams, like contractors, may have very clearly demanded and scoped problems to solve. But in most product-centric software teams, our goal is to build the right thing to solve the right problem. Ideally, we build up a variety of these solutions over time, which form a product we’re proud to ship to our users. The principles I’ve shared here apply to that context, and not others.

So whenever we find ourselves complaining about our past decisions, we can ask: are we discounting how tough this was, and how little we knew, at the time? When we’re in the trenches, faced with the question of building more or building better, we can focus on better. And when we find ourselves looking towards the future, we can ask: if the dice rolls in different ways, how can our plan evolve?

Whenever we build through uncertainty, the best builders aren’t those who can perfectly predict the future, building everything that could be needed, and going all-in on. The best are rather those who make the most of the little resources and certainty we have.