A feature can be useful on its own and still make a product harder to use. That is an uncomfortable possibility when implementation has become easier. The cost visible in a task tracker is the work required to add the feature. The cost a user encounters may be another choice, another state to understand, and another place where the product behaves differently. I would like a feature budget that makes those costs visible before the implementation begins.
Karri Saarinen’s October 15 essay, Someone behind the software, reflects on the judgement behind a coherent product. It is the author’s perspective, not evidence about users of a product I have measured. The essay led me to a practical question for a small project: how can a person deciding what to build account for interactions between features, rather than evaluating each request as a self-contained improvement?
Start with one job the product should make easy
Imagine a hypothetical notes application whose central job is to capture an unfinished thought and find it later. The current interface has an inbox, a search field and an archive. Three proposed additions arrive: mandatory tags, automatic summaries and a shared team workspace. Each has a plausible benefit. Mandatory tags can support organisation, summaries can help scanning, and a team space can support collaboration. None of those benefits establishes that the three belong in this particular application at this particular stage.
I would compare each proposal with the capture-and-retrieve job first. Mandatory tags add a decision before saving. An optional summary adds a representation that can differ from the original note. A shared workspace adds questions about visibility and ownership. These are not reasons to reject the ideas automatically. They are costs to place beside the benefits. The person who wants to record a thought in a hurry experiences the mandatory tag differently from the person organising a research library.
Next comes the pairwise comparison. What does a summary show when a note moves between personal and shared space? Are tag names private, team-wide or both? Does search rank the original note, the summary or two entries? A short table with the three features on both axes can expose these questions. The diagonal holds each feature’s own complexity. The other cells hold the interactions. This table is a reasoning aid for our hypothetical product, not a measured complexity model or a universal formula.
Budget for the explanation
One useful constraint is the explanation a newcomer needs. Suppose the product currently teaches saving and finding a note in one short example. After adding the team space, the explanation needs a warning about where a note will be visible. After adding summaries, it needs another explanation about generated text and the original. Those explanations may be worth having. I would simply count them as part of the feature, along with the interface, storage rules and support work. Shipping code does not finish the explanation.
A feature budget can therefore be written in ordinary language. For the next release, the imaginary project might allow one new concept that improves retrieval while leaving capture unchanged. Under that constraint, optional tags could be a more focused experiment than mandatory tags plus a team workspace. This is an illustrative choice, not a recommendation based on customer research. The value of the constraint is that it forces a comparison. A proposal must explain why this is the concept worth spending the next release on.
The experiment also needs a way to disappoint us. If people cannot find their original notes after using the new organisation scheme, the retrieval promise has not been demonstrated. If the capture path now demands explanations that the intended audience does not understand, the change may be interfering with the core job. In an actual project, these observations would require real task sessions or appropriate usage evidence. A team’s enthusiasm during a demo cannot stand in for that evidence, and this hypothetical example does not supply it.
Make removal a normal outcome
I would decide before launch what can be removed and what data must remain readable if the experiment ends. Optional display features are often easier to withdraw than new ownership rules or mandatory data structures. That difference belongs in prioritisation. Reversibility is not free, but it can make a small experiment genuinely small. A feature described as temporary should not force users to adopt a permanent new way of storing their work without a clear path back.
There is no shortage of things a notes application could become. A knowledge base, a collaboration tool, a writing environment and a task manager are all plausible directions. The difficult work is choosing which promise the current product can keep clearly. My feature budget would begin with one sentence describing that promise, followed by the new concept I am willing to introduce. If I cannot explain how the addition earns its place beside the existing experience, building it faster will not settle the decision.
