The cost of features
One thing I've noticed over the years is that conversations about digital projects have a tendency to become conversations about features.
We discuss dashboards, search, account areas, payment systems, AI assistants and countless other additions because they're containable. They're easy to picture, estimate and compare. In digital work they’re perhaps the closest thing we have to making something tangible. You can point to them, demonstrate them and talk about them in concrete terms. Features feel like progress.
It's relatively straightforward to estimate the effort involved in building a feature, whether that's in time, money or complexity*. Estimating the value it might create is much harder. But that's the more interesting question. What is a feature actually worth?
That question becomes important as soon as there are choices to make. Do we improve the sign-up process or invest in reporting? Do we add another payment option or spend the money somewhere else in the business? Do we build this at all, or is there something more valuable we could be doing? The features themselves can't answer those questions.
Sometimes a feature is driven by necessity. Sometimes it’s driven by customer feedback, by competitors or simply by someone’s intuition. None of those are unreasonable starting points, but they all leave the same question hanging in the air: what are we actually trying to achieve?
That question matters more than it first appears. Not because features aren't important, but because they carry no inherent value on their own. A feature only becomes valuable when it helps us reach a goal.
That sounds almost obvious when written down, but it has surprisingly practical consequences.
Without a clear goal, choosing between features becomes difficult. They compete on visibility, urgency, internal enthusiasm or who shouts loudest. If there is a goal, however, the conversation changes. We can ask which feature is most likely to help us move towards it. We can decide whether a feature is the right investment, whether it belongs now or later, or whether there's a simpler way of achieving the same outcome.
It also opens up possibilities beyond the website or product itself. If a goal is to help people complete a task more easily, perhaps the answer is a better interface. Equally, it might be clearer content, a different process, better onboarding or something else entirely. Starting with the feature assumes we've already found the solution. Starting with the goal leaves room to discover one.
This becomes more important over time. Features accumulate. They begin to compete for attention, for development time and for space within a product. Without a clear sense of purpose they start to resemble Brownian motion, each one nudging the whole in a slightly different direction and hoping that, somehow, the overall result will be an improvement.
Goals provide that sense of direction. They don't remove the need to build features, but they give us a way to judge them. They help us prioritise, they make roadmaps more coherent and, perhaps most importantly, they give us a way of deciding whether something was worth building in the first place.
I’ve increasingly come to think of features as hypotheses rather than decisions. We believe this feature will help us reach this goal. If it doesn't, we should be willing to change it or replace it. The goal remains. The feature was only ever one possible route towards it.
I suspect that’s the distinction that matters. We become very good at estimating what features cost, but much less disciplined about asking what they’re worth. The better place to begin is with the outcome we’re hoping to reach, and to let the features follow from there. After all, features have cost, whereas goals have value.
*Albeit taking into account Brook's Law, Hofstadter’s Law and Hofstadter’s Law