The economics of product tradeoffs

The word tradeoff has become ubiquitously overused and misunderstood in product development.

The word tradeoff has become ubiquitously overused and misunderstood in product development.

A tradeoff is a balance achieved between two outcomes through compromise. You’re not really making a tradeoff unless you’re losing something in the process.

If I live in LA, should I trade a longer commute for a bigger and cheaper house outside of LA, or should I pay more to shorten my commute and have easy access to city amenities? Should I spend another $400 to upgrade to more cores on my laptop and will the benefit outweigh the expense? We’re used to making such economic tradeoffs in our personal lives, but I’ve found that this intuition is often missing in the world of product development.

How does one build intuition about making sensible economic tradeoffs in product development?

The economics of products

Reinertsen asserts that the activity of product development should optimize for the Gross Profit of a company. Removing for a minute any non-profit or philanthropic motives, the economic desired outcome of building a product is to generate a profit.

You can use the measures of profit to guide your tradeoff decisions. At the high level of strategy and features, it’s relatively easy to estimate profit. At the lower levels of implementation, it’s harder to correlate profit directly to activities, so we need good proxy variables.

Cost of delay

Cost of delay refers to the economic value of bringing a product or feature to market faster. What is the cost of 2 more months of developing this feature? How much time should we invest in a feature to reduce the cost of delay and maximize its ROI? Understanding the demand and supply side economics helps prioritize the work.

Lead times

Lead time refers to the time from conception to release of a product or feature. Lead time needs to incorporate all of the activities needed to bring a feature to market, including testing, deploying, bureaucratic approval processes, etc. Reducing lead times helps reduce the cost of delay.

There are two ways to optimize this. First, it’s critical to truly understand the problem you’re solving on the demand side, which in turn helps design an optimal solution and set scope boundaries. Scope can be managed by setting explicit time constraints for a feature’s lead time (more on that later). Second, it’s important to optimize and automate the DevOps process, which includes the development, testing, deployment, and infrastructure management.

Risk

We need to be able to quantify risk if we’re going balance it with reducing lead times. There are numerous risks like: the risk of having the wrong assumptions; the risk of introducing a quality defect and upsetting the customers; the risk of failure or cost overruns due to variability.

We can invest a lot of time in derisking, but we need to know at which point this investment outweighs the benefits. We pay for derisking with longer lead times.

Some industries, like SaaS software products, have higher risk tolerance. As my conversation with Justin illustrated, it’s important to acknowledge the different risk tolerances of different industries:

User acquisition

Acquiring users is a proxy for profits and should be used during the decision making process. Tradeoffs between prioritization, scope, and design can focus on its effects on user acquisition. Obviously, we can’t precisely predict how many users we’ll acquire, but if we understand the problem we’re solving, we should have some idea of the market. We should be asking questions like “Will cutting scope from this feature still solve the problem?” and “How will it effect user acquisition?”

User retention

Customer churn is a part of any product and new customer acquisition is frequently more costly than retention. In many cases, investing in keeping your current users happy is more profitable than trying to acquire new users.

Many companies focus on user acquisition as a priority over anything else, but frequently there are more opportunities for increased profits through current user retention. Understanding the profitability of new customer acquisition vs. existing customer retention can help you make better tradeoffs.

Forcing tradeoffs through time boxing

A hard deadline is a great tool for forcing tradeoff decisions. Without a time constraint, there is little incentive for compromise.

Ryan Singer’s book Shape Up describes this notion as “appetite”. How much time does it make sense to spend to deliver a satisfactory solution? Deciding on the upper limit of time, will force you into thinking of economic tradeoffs and deciding what’s crucial.

Time boxing is not about estimating how long it will take to deliver the solution. It’s about finding the balance between the the economics of the demand side (problem) and the time and money investment on the supply side (solution).

Economics of features

Let’s say we’ve uncovered a demand side struggle and are going to design and implement a feature. Before we go to deep into solution design, we should decide on how much time we’re willing to invest, which will in turn force design and scope tradeoffs.

While deciding on how much we are willing to invest in a feature, we can ask questions about its effects on user acquisition and retention. We can think about the costs of delay. We can think about risk in terms of quality and unknowns.

In some cases, cost of delay will drive the tradeoffs and make us cut scope to go to market faster. In other cases, minimizing risk might be the right call. In my experience, mistakes are more tolerable in SaaS software products than they are in industries with complex distribution models or mission critical products. Therefore, the cost of delay will most likely be the driving force of many tradeoff decisions for SaaS products.

But what about refactoring?

Feature tradeoffs are typically easier to reason about due to the ability to directly link its benefits to potential economic upsides. But what about tasks more technical in nature? Things that the user will never see directly? Refactoring comes to mind as a frequently planned activity, but teams can rarely explain a direct economic benefit. Is this refactoring worth pursuing?

Refactoring economics are typically centered around optimizing lead time and reducing risk. Sure, this part of the system causes longer lead times due to a bad design, but if we only touch it once a year for bug fixes or small changes, investing a 4-week cycle in refactoring probably doesn’t make economic sense. On the other hand, if it’s a frequently touched part of the system, which has a consistent effect on lead times and risk, investing in refactoring might be the most economically savvy decision, especially if we can measure its impact.

Conclusion

Understanding the economic variables of your product and how they relate to each other will help you make better tradeoffs. Making them a part of your decision checklist will help you prioritize work and better invest resources.