Hey 👋 this is Luca! Welcome to a ✨ monthly free edition✨ of Refactoring.

Every week I write advice on how to become a better engineering leader, backed by my own experience, research and case studies.

You can learn more about Refactoring here.

To receive all the full articles and support Refactoring, consider subscribing 👇

Become a better tech leader ✨

If you work on a digital product, chances are you are familiar with Retention.

Retention stands for the continued use of a product (or feature) by your customers. Good retention improves monetization, lowers acquisition costs, and gives you an edge over competition.

One of the most popular ways of studying Retention is cohort analysis.

Cohort analysis groups users by batches of time (typically days, weeks, or months) based on their first interaction with the product, and shows how these cohorts stay engaged, displaying the share of users that continue using the product over time.

But you may ask — why are we talking of retention and cohorts?

📈 Feature Costs and Retention

In many ways, the retention distribution is similar to the way development costs behave.

For each feature, you can roughly divide such costs in two steps:

• 🚚 Delivery Costs — costs you sustain to develop the feature until the first deliverable.

• 🏃‍♂️ Operating Costs — costs you sustain to maintain and evolve the feature until...forever!

If you work in small batches and iterate fast (which you should), the line between these two steps is blurred, but the costs follow a predictable distribution nevertheless.

They go from being higher before delivery, to become lower when your team moves on to new initiatives.

Here comes the obvious difference with retention: on the long run, good products want to keep retention high. Good engineering wants to keep costs low.

In particular, good design should minimize both delivery and operating costs. And I would argue that, out of the two, it's vastly more important to minimize operating costs, as they — in contrast with delivery costs — compound over time with those of other features.

Just like good retention makes companies thrive by making customers come back, bad operating costs may sink it, by taking up most of your team capacity.

🏃 Operating Costs

In my experience, the bulk of operating costs, for any feature or product area, is caused by three offenders:

1. 💼 Business changes

2. 🐛 Bug fixing

3. 🔨 Tech Maintenance

Let's see them more in detail, together with strategies to reduce their impact.

💼 Business Changes

These are feature updates and changes prompted by business needs.

The frequency and magnitude of these depend on the market and the environment you are in — whether you are in a fast growing startup, a consolidated business, or anything in between.

Frequent changes lead to misalignment between what business wants and what the code represents, that is the true nature of technical debt.

Strategy:

• Invest more time on design — To reduce the impact of future changes on your development costs, invest time in understanding both the current requirements, and potential evolutions. Spend time with stakeholders to map the possible scenarios, and create your design accordingly.

🐛 Bug Fixing

This is time spent on regressions and mistakes made by developers.

Mistakes are inevitable. The best strategy to reduce their impact is to catch them early and frequently.

Strategy:

• Make your code safer — To catch bugs early, it goes without saying that an efficient testing pipeline is really important. Based on your team and your codebase, you may also evaluate static typing options (e.g. Typescript over Javascript).

• Invest in Continuous Delivery — To catch bugs frequently, you should release frequently. Companies that work in small batches are also faster at recovering from regressions (it's been proven).

🔨 Tech Maintenance Costs

This is under the hood work related to the specific design or technologies. Like scaling issues, framework and dependencies updates.

Strategy:

• Invest more time on design — Just like for business changes, many issues can be solved upfront by better understanding what the business needed in the first place. Many scaling issues happen because developers don't expect something to need to scale, at all.

• Minimize technology risk — This often means: choose boring technology. For critical product parts, choose tech that is proven, well supported, and works (and fails) in a way that is well understood by your team.

• Buy instead of Make — "Don't reinvent the wheel" is common advice. If you don't believe something should become a core IP of your company, then chances are you shouldn’t be building it, but you should look for ways to buy the functionality.

📚 Resources

• The Basal Cost of Software — This recent article by Eduardo Ferro greatly inspired this post, drawing a comparison between feature costs and the basal metabolic rate of human body. Very Recommended.

• How Much Does a New Feature Cost? — Spoiler: more than you think. A great short post by John Cutler that enumerates all the hidden costs caused by new features. It's one of those that should be printed and hung on the wall.

• The One Growth Metric that Moves Acquisition, Monetization, and Virality — If the retention metaphor sparked your curiosity and want to learn more about retention itself, this is an amazing post by Brian Balfour, one of the absolute OGs of product growth.

And that's it for this week! What's your experience with maintaining features over time? Let me know in the comments or via email 📮