Airlines, Not Widget Factories

At my dayjob I build a piece of software. The company that employs me works the way many, probably most, software startup and midsize shops work: we offer access to the software we build, then extract some value from our users by various strategies, making them pay, taking a cut on transactions, gathering and selling data, etc. The specific monetization strategy doesn't matter too much, more that the basic model here is that growth looks like getting more users onto the platform, or getting existing users to do more profitable activity.

If this sounds like a very general description of a business that's because it is. But when I discuss the business model internally, I think it's sometimes confused for a different, similar but distinct, business model. The obvious lever for attracting more business is to build more things, make the software fulfill more potential users' needs, and they will come! What this starts to look like if you go through a feature development cycle with at least moderate success is that you're building things and selling them. It's not unnatural to see your developers building a thing, getting some new business and revenue, and come to the conclusion that your business is a feature factory in the way that Kellogg's is a cereal factory: if the demand is there your goal is to produce more and lower cost, and the profit flows. More widgets, more sales, and sales cure all.

Developers have been griping about this mentality for a long time, "code is a liability, not an asset" has been an idea that's been bouncing around for a decade at least. It's absolutely true and I think it's penetrated the developer consciousness pretty well. I think it's an idea that's gotten less traction on the product and business sides of the house. An analogy I've taken to using of late is one I hope provides an easier mental model: this kind of business operates more like an airline than manufacturing.

For airlines, planes are obviously wholly necessary and central to the business, you don't have an airline without planes. But a plane is also a tremendous expense, it requires a boatload of capital to acquire and it requires continuing (increasing in fact!) investment to keep operational. The business of operating an airline isn't about acquiring more planes, it's about maximizing utilization. Expanding the fleet is a double edged sword: it creates the possibility of attracting more business but represents upfront investment and ongoing expense, it's an investment that only makes sense when weighed against utilization.

My thesis here is that this is exactly the same dynamic that applies to software. A feature in a product isn't a thing you build and sell and net development cost against revenue and take your profit and go home. It's an ongoing investment that is going to absorb engineering resources for as long as it exists. Expanding the feature set represents a bet that ongoing utilization of that feature is greater than the expense of maintenance. This seems obvious, but I've had conversations that boiled down to "I think this is going to take N dev hours per month to maintain or deal with, let's say our average cost to employ a developer is X, what do we think the chances of bringing in N*X new revenue a month by doing this?" that ended pretty quickly with "let's throw it into the backlog". And sometimes I'm surprised by that conversation in the opposite direction. Indeed, sometimes there is clear signal of upside, and bringing that to developer attention is great. The point here is regardless of the outcome, having this conversation with this framing is a worthwhile undertaking.

The proposal of removing features is a particularly challenging conversation between product and engineering where this view of things is useful. The product perspective on feature removal is understandably bleak: if there's any usage of the feature in question then that's an immediate and measurable cost, on top of engineering investment in removal. And of course anything that was built was done so in hopes that it would be used, so I often encounter unreasonable optimism that usage is going to pick up as soon as a few more features are piled on. Whereas the maintenance burden of a feature is much harder to quantify. I often have to resort to vagaries like "I feel like this is going to be an absolute bug farm" when trying to explain the ongoing costs of features. And indeed, if I could anticipate exactly how an implementation was going to produce a bug that would be factored into the design of the thing in the first place and a bug would never happen. But if we approach a proposal of feature removal with this software-as-airline perspective we can at least admit there is a possibility of upside: reducing the feature set is a matter of weighing that feature's utilization against the ongoing cost that it represents rather than sacrifice for no return.

The point of the metaphor here is to try to reframe the conversation about building features. A piece of software with no features isn't going to make anyone money, granted, but just as operating an airline isn't acquiring as many jets as possible, the business of building commercial software isn't about stacking up every feature that might produce a sale. If we can approach conversations about what we do or don't build from a perspective of cost analysis - rather than seeing it as an infinite field of revenue opportunities, some better than others, but always assuming more is better - we'll be able to spend limited engineering resources more effectively.