How and why exploiting uncertainty makes products more profitable
Uncertainty is not necessarily bad. It’s not necessarily good either. Uncertainty simply exists, and it affects a product’s economics, regardless of whether you choose to ignore it — as many product developers do.
In software development, uncertainty is not the problem. Its economic impacts are. Nonetheless, uncertainty is precisely what puts money in product developers’ pockets, including yours. In this blog post, you’ll learn why and how.
First, I’ll explain uncertainty and why it’s not intrinsically evil. In this first part, I’ll show how uncertainty puts money in people’s pockets. For that, I’ll demonstrate how an intelligent gambler could make money on boxing matches so that you can learn how to punch an opportunity right on the nose when it appears.
Then I’ll compare manufacturing and software engineering to elucidate why trying to eliminate uncertainty at all costs is futile. In this section, you’ll understand how uncertainty adds another dimension of value creation to the products you build.
Finally, I’ll propose two ways of diminishing the economic impact of uncertainty without hindering its possible benefits.
At the end of this post, you’ll also find a small section summarising the previous three.
None of the content in this post should be considered investment advice. It should also not be considered betting advice. This blog post is about the dynamics of uncertainty and product development. The investing and betting examples are here for illustrative purposes only.
What uncertainty is and how it puts money on people’s pockets
Did you watch Logan Paul versus Floyd Mayweather? I didn’t. I don’t understand boxing and probably never will. That’s why I’d be a terrible bookmaker. Still, imagine you, and I are going to make a bet.
My bet’s odds are -800 for Floyd and +500 for Logan. Those are american odds, meaning you’d have to bet $800 on Floyd, the favourite, to make a $100 profit if he wins. If you were to bet on Logan, the underdog, you could make a $500 profit with a meagre $100 bet.
These odds represent uncertainty. If everyone knew who was going to win, there would be no bets to be made.
As the odds imply, this fight’s payoff is asymmetric. Placing a successful bet on Mayweather is more likely, but offers a small reward. Conversely, betting on Logan is riskier but yields a higher return.
Considering this asymmetric payoff, it’d be foolish for you to make a decision exclusively based on how likely you’d be to win. Sure, you could place a safe bet on Floyd, but you’d make less money and have to risk a considerable amount. Would you place an $800 bet to make a $100 profit? That’s only a 12.5% profit. Could the higher returns you’d have by placing a risky bet on Logan outweigh the safe bet’s benefits?
To answer that question, you need to get luck out of the equation. If you know what the actual probabilities were, and this fight was to happen an infinite number of times, what would be the most profitable bet to make?
Adopting this mindset turns gambling into a game of quantity, not luck. That’s because you can have a net positive outcome providing you make a large enough number of bets.
To show you how to get luck out of the equation, we’ll simulate your bankroll if you were to bet on Paul in ten thousand fights against Mayweather. In this simulation, I’ll assume Logan has an 11% chance of winning, which is why I’ve offered such a high payout if he wins¹.
Assuming my estimation is correct, here’s what your balance would look like after betting $100 on Logan Paul ten thousand times.
Bankruptcy. Not good. I’d have to write a lot of software and eat a lot of cheap ramen to pay back my debt.
What if I bet on Floyd instead? Considering I’ve estimated Paul’s probability of winning at 11%, Floyd’s must be 89%. Here’s my bankroll if I were to bet on Floyd ten thousand times.
Much better. No wonder Floyd’s middle name is “money”.
In this case, the bet’s “safety” compensated for the small payout. But what would happen if Floyd remained the favourite but were only a bit less likely to win?
To illustrate that, let’s assume you’ve got a PhD in boxing and are the Mike Tyson of statistics. Thanks to that skillset, you’ve built the perfect probabilistic model for this fight. This model determined Logan Paul actually has a 22% chance of winning, not the previous 11%.
Would it be worth it to bet on Logan in that case? Before we decide, let’s run both simulations and compare the results.
Assuming your model is correct, it’s now much better to bet on Logan Paul, even though his chances of winning are significantly smaller than Floyd’s.
As you’ve just seen, just because a boxer is unlikely to win, it doesn’t mean it’s not worth betting on them.
By the same token, in the product development world, just because a particular feature or product is unlikely to succeed, it doesn’t mean it’s not worth building.
When building a product, besides considering its chance of success, you must consider how much it will cost you to attempt and how big the payday will be. It’s only when you balance a task’s cost, payoff, and the likelihood of succeeding that you’ll know whether it’ll be worth trying.
Moreover, just as if you were betting on a boxing match, you shouldn’t judge your decisions by their outcome. You should evaluate your decision, considering whether it was the best decision you could’ve made with the information you had at the time. For that, you must get luck out of the equation. If you were to make the same decision over and over again, would it yield a net positive outcome?
Judging a decision by its outcomes is a bias known as the outcome bias.
To illustrate how to make a decision that’s statistically sound without having to simulate it thousands of times, let’s get back in the ring.
This time, we’ll still simulate ten thousand bets on Logan Paul again, but instead of plotting our balance over time, we’ll plot the average gain.
As the graph above shows, as you repeat a particular bet, the average gain converges towards a particular value: the expected value of the bet.
This value towards which your average gains converge is the bet’s expected value. Assuming you’ve got a good probabilistic model, the expected value is usually the most important factor in deciding whether you should take a particular bet.
To calculate that value, you can use the formula below, which balances the probability of winning, its payout, the probability of losing, and the total value of that loss.
One important caveat about the expected value is that it’s not the only factor to consider when making a decision. When deciding whether you’re willing to make a bet, be it on a boxing match or a new product, you must consider how much loss you’re willing to tolerate.
If you only have $100 to make a bet, I’d much rather bet on Floyd no matter how high Logan’s returns are. If I can only make a single bet, I’d much rather make the safe bet than risk ruin in exchange for a large payout.
Similarly, if your startup is running short on capital, you may want to make safer bets first. Those safer bets allow you to gather more information and capital to de-risk future product development opportunities. Additionally, the more you ship and talk to customers, the better you will be at determining the actual odds of a particular product or feature succeeding.
Why eliminating uncertainty is a futile effort
If everyone thinks Floyd is more likely to win, more people will bet on him. As a result, they’ll receive a smaller payout to compensate for their safe bet. This payout comes from the pockets of people betting on Logan, whose total staked value is smaller.
Conversely, there’s a larger value staked on Floyd. If Floyd loses, this large flows into the pockets of the small number of people betting on Logan. That’s why betting on Logan may yield higher returns.
It’s the uncertainty of whether Logan Paul can win that puts money on his bettors’ pockets.
If you eliminated uncertainty, there would be no bets to be made because all of the money would be on a single corner of the ring. On the other hand, the more uncertain a Logan Paul victory is, the higher will be the returns to those who bet on him.
Imagine, for example, what would happen if even more people were to believe in Floyd, pushing his odds towards -1200 and Logan’s towards 1200. Assuming Logan’s actual likelihood of winning was still 26%, the expected value of betting on him goes from $82 to $262 — that’s more than a 3x increase!
Similarly, you’ll make money in the stock market when you can predict events others can’t. If everyone thinks a particular stock will go up, that expectation will be built into its price. On the other hand, if you expect a positive event no one else does, that event will not have been reflected in the stock’s price, allowing you to buy it for less money, and enabling, possibly, a more significant profit — assuming your expectations are correct, of course.
Again, as uncertainty increases, returns increase too. Eliminate uncertainty, and you eliminate returns.
In the software development world, things are no different. Without uncertainty, there would be no innovation, and without innovation, there would be less profit to make.
In software, there are two vectors of value creation: replication and innovation.
Replication means selling the product to more people — making two of the same thing. Replication doesn’t depend on innovation, and, in the software world, it’s free. The more people you sell your software to, the more revenue you make.
Replication is how the manufacturers make money. Selling two cars generates twice as much money as selling one car.
Car manufacturers don’t want their factory workers to be “innovating” every time they make a new steering wheel. In fact, manufacturers want the exact opposite. They want as little uncertainty and innovation as possible during the manufacturing stage.
As the graph below shows, the value created through replication alone is linear. It’s a function of quantity and price (which is primarily constant over time).
Innovation changes the dynamics of value creation. As you improve the product’s “recipe”, each new product becomes more valuable.
When there’s innovation, besides making money by selling more units, you can increase the potential return of each unit sold.
Furthermore, in the fantastic world of SaaS, product innovation boosts the value not only of new products but also of the ones already sold. That’s because, in SaaS, a sale unit is a subscription. Consequently, if you add value, you’ll be able to raise next month’s price without incurring more customer acquisition costs.
In the software world, replication is virtually free, so we can afford to invest in innovation to boost our profits. Innovation is inherently uncertain, and thus why eliminating uncertainty is a futile effort.
Please notice I’m not saying you should celebrate or maximise uncertainty either. I’m just saying you should identify opportunities in which the uncertain bet’s payoff makes a bet worth making.
Diminishing uncertainty’s economic impact without hindering its benefits
There are two ways of diminishing the economic impact of uncertainty without hindering its benefits significantly:
- Breaking a large bet down into smaller bets
- Shifting uncertainty to where it’s cheaper
Breaking a large bet down into smaller bets
Imagine how much less risky it would be to bet $12.50 in each of the match’s eight rounds instead of betting $100 straight away.
Providing odds remain the same, being able to adjust your bet helps you diminish risk. If Logan shows up prepared and has an excellent first round, you could cut the likely loss you’d have on Floyd and bet on Paul instead.
When creating products, the same principle applies. If you’re uncertain a particular product will work, you shouldn’t spend months building it. Instead, you should make a small bet by developing a simple product. Then, you should go talk to your customers and see whether your product solves their problem.
Breaking a bet down into smaller bets allows you to manipulate uncertainty according to your risk appetite. Furthermore, it often doesn’t change the total payoff providing you iterate fast enough.
Shifting uncertainty to where it’s cheaper
Before I started writing this blog post, I put together a concise bullet-point list. I did that because it’s cheaper to validate my structure and ideas using bullet points than to write a full-blown article and refactor its large paragraphs a thousand times.
When building software, you could take a similar approach: you could move uncertainty to where it’s cheaper.
In the software world, at the beginning of a project, operation uncertainty is cheaper than designing uncertainty, for example.
Because of that difference, you can decrease overall costs if you spend less time designing a product and a bit more money operating it.
Imagine, for example, that you’re implementing a streaming platform. In that case, it would be too risky to spend months implementing a high-performance service if you don’t yet know whether anyone will pay for it.
If you were in that situation, it would be cheaper to ship an inefficient piece of software and give AWS or GCP a couple more hundred dollars a month than to pay a few more full-time senior engineers for longer to optimise the software.
That’s only until you’ve validated the product and customers are starting to increase, though. Once you’ve shipped something people want, the value of reducing operational costs will grow. You should only shift focus when the cost of operation uncertainty is about to become larger and more dangerous than the cost of design uncertainty.
Putting it all together
Just because a particular feature or product is unlikely to succeed, it doesn’t mean it’s not worth building.
When building a product, besides considering its chance of success, you must consider how much the attempt will cost you and the expected returns. It’s only when you balance a task’s cost, payoff, and the likelihood of succeeding that you’ll know whether it’ll be worth trying.
To get luck out of the equation, you must consider all those three factors to determine whether a decision’s outcome would be favourable if you were to make that decision an infinite number of times. That mindset helps you avoid falling prey to outcome bias because it enables you to determine whether you’ve made the best bet with the information you’ve had at the time.
One way to define whether a product or feature is worth shipping is to calculate its expected value using the formula below, which balances the payoff and losses and their probability of occurring. That formula determines the value towards which your average gain converges.
In addition to the product or feature’s expected value, you must consider your risk appetite. If you don’t have enough capital to make many more bets, it may be worth making the more certain bets first.
You should just be mindful that there’s a premium you pay for certainty. The larger the discrepancy between the market’s odds and the actual odds, the larger the opportunity to make a profit. You should look for those opportunities and invest in the ones in which you’re more confident the discrepancy is higher.
Alternatively, if you don’t have the capital to justify a high-risk appetite, you could try to diminish the economic impact of making these bets. For that, you can either break down a large bet into smaller bets or shift the uncertainty to where it’s cheaper.
Breaking down your bet into smaller bets allow you to cut losses earlier, and resize your bets as you acquire more information, making bets less risky.
Shifting uncertainty to where it’s cheaper allows you to pay less to validate the hypothesis early on and redirect cash flow towards operational aspects when they become riskier than the product’s market fit.
Footnotes
[1] If you were to calculate the Logan vs Mayweather actual implied odds, they’d be slightly different than the ones I’ve shown here. That’s because of the bookmaker’s vigorish. This blog post is not about sports betting, so I’ve glossed over a few aspects that aren’t relevant for talking about product development. I’ve also intentionally avoided mentioning the Kelly Criterion (although that might be a subject for another post).
Wanna talk?
I currently offer mentorship and consulting packages for individuals and startups wishing to ship more software in less time and with less stress. If you’re interested in improving your processes and pipelines, book a free introduction call here. I’d love to help you solve any problems you might be facing or answer any questions you might have.
Alternatively, you can send me a tweet or DM @thewizardlucas or an email at lucas@lucasfcosta.com.
