“What if I do nothing?”

Inaction has benefits.

There are many prioritization frameworks out there that aid thinking about what to build next. The two that I tend to fall back on are Kano and Cost of Delay, the former because it differentiates effectively between features that are basic expectations of customers and those that surprise to delight. Cost of Delay attempts to quantify the “economic cost” of delaying a feature to a later point in time as opposed to implementing it immediately. The quotations are there because you don’t necessarily need to compute a cost, and can use the framework to steer your intuition.

Lately, I’ve been asking myself another question when deciding whether to build a feature: What if I do nothing? What is the cost of inaction and not investing a single minute? Though this can’t be the only question you ask, it can be the first.

I like this question because it serves as a simple starting point from which logical reasoning can be applied, somewhat similar to the 5 Whys method used for root cause analysis. This question aligns with my favourite agile principle: Simplicity--the art of maximizing the amount of work not done--is essential.

Every line of code has a cost. It has an initial cost and a lifetime cost, with the latter exceeding the former by several orders of magnitude. Before we choose to incur both, we owe it to ourselves to think deeply if it’s worth it. This approach is related to second order thinking which encourages us to think about the secondary impacts of our action:

Failing to consider second- and third-order consequences is the cause of a lot of painfully bad decisions, and it is especially deadly when the first inferior option confirms your own biases. Never seize on the first available option, no matter how good it seems, before you’ve asked questions and explored.

Whereas second order thinking (earlier post) prompts us to think about the consequences of our actions, this question puts us in the mindset of the consequences of inaction. This is easier to reason about because the starting point is the current state which is understood, and not a future action whose consequences must be hypothesized.

Since I’m playing the role of developer, product manager, sales, marketing, ops, and customer support in my little hopeful startup, I’ve become acutely aware of the costs across the value chain since I’ve been doing what traditionally has been the responsibility of someone else, which has made me much more aware of the impact of developing features. Basically, I’ve been eating my own dog food.

Given this insight, I’ve found myself being far more critical of starting a new feature and ask myself, is it really worth it? Who is benefitting from it and by how much? Is any pain that’s caused by the absence of this feature acceptable? I don’t always kill features, but when I do, I feel really good about it.