How We Decide Whether to Build a Feature

Feature decisions deserve a method

The choice of what to build shapes a product more than how well any single feature is built. Yet feature decisions are often made reactively: the loudest request, the most recent competitor, the idea that happened to come up. A small studio without a deliberate way of deciding tends to accumulate features that each seemed reasonable in the moment but do not add up to a coherent product.

The remedy is a consistent test applied to every proposed feature, so the decision rests on the product’s purpose rather than on who asked. The test does not need to be elaborate; it needs to be applied honestly and every time.

Does it serve the purpose?

The first question is whether the feature serves what the product is fundamentally for. A product has a purpose, a particular problem it solves for particular people, and a feature either advances that purpose or pulls away from it. Features that serve the core are candidates; features that merely could be added, because they are possible or because someone wants them, are not automatically worth building.

• Ask whether the feature advances the product’s core purpose.
• Distinguish what would genuinely help the product’s users from what is merely possible.
• Be wary of features that broaden the product away from what it does well.

Is the benefit worth the lasting cost?

A feature that passes the purpose test still has to justify its cost, and the cost is not only the effort to build it. Every feature must be maintained, tested, documented, and accounted for in future decisions, for as long as it exists. The honest comparison is between the lasting benefit and this lasting cost, and many appealing features do not survive it.

Saying no is part of the job

A test that never rejects anything is not a test. The hardest and most important part of deciding what to build is declining things, including reasonable requests, that do not pass. A small team in particular cannot build everything, and a product stays coherent only because someone is willing to say no to features that would dilute it.

At BBMM the decision comes down to a few honest questions asked before building: does this serve the product’s purpose, is its lasting value worth its lasting cost, and does it fit what the product is meant to be. When the answer is no, the discipline is to say so and explain why, rather than building it to avoid the discomfort of declining. A product is defined as much by what its makers chose not to build as by what they did.