How We Decide Whether to Build a Feature
By Maksym Bardakh Ivko · Chief Executive Officer
In short
Deciding what to build is the most consequential thing a product team does. Doing it well takes a deliberate test applied to every request, whoever made it and however recently. The test asks whether a feature serves the product’s purpose, whether its lasting benefit justifies its lasting cost, and whether it fits what the product is meant to be. Saying no well is part of the discipline.
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 product team without a deliberate way of deciding accumulates features that each seemed reasonable in the moment and together fail to form a coherent product.
The remedy is a consistent test applied to every proposed feature, so the decision rests on the product’s purpose. The test can be short. It has to be applied honestly and every time.
Does it serve the purpose?
The first question is whether the feature serves what the product is 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. A feature that is merely possible, or that one person wants, has to earn its place like any other.
- Ask whether the feature advances the product’s core purpose.
- Separate what would 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 effort to build it is the smallest part of that cost. 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 no test at all. The hardest part of deciding what to build is declining things that do not pass, including reasonable requests. No team can 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 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. Building a feature to avoid the discomfort of declining it is the costlier choice. A product is defined as much by what its makers chose not to build as by what they did.
Key takeaways
- What to build shapes a product more than how well any single feature is built.
- Replace reactive feature decisions with a consistent test grounded in the product’s purpose.
- Ask whether a feature advances the core purpose or pulls the product away from it.
- Weigh a feature’s lasting benefit against its lasting cost, which far exceeds the effort to build it.
- Saying no to features that would dilute the product keeps it coherent.
Frequently asked questions
- How should a team decide what features to build?
- With a deliberate test applied every time: whether the feature serves the product’s purpose, whether its lasting benefit justifies its lasting cost, and whether it fits what the product is meant to be.
- Why consider a feature’s cost beyond building it?
- Because every feature must be maintained, tested, documented, and accounted for in future decisions for as long as it exists, so the lasting cost can far exceed the effort to build it.
- Why is saying no important?
- Because no team can build everything, and a product stays coherent only when someone declines features, even reasonable ones, that do not serve its purpose or justify their cost.
About the author
Maksym Bardakh Ivko
Chief Executive Officer
Maksym leads product at BBMM Technologies. He designs Flowo’s scheduler and writes most of what ships in it.