Next WrldThe scene repeats in almost every company. Meeting to review the internal tool, someone shares screen and in ten minutes ten requests appear.
Sales wants a field to record how each opportunity arrived. Admin wants another to distinguish billing type from the start. Marketing wants to classify origin in more detail. Management wants automatic notice when something delays. Nothing sounds strange. Each request, separately, seems reasonable.
And then the ordering question appears: they ask for ten improvements, do we make them all?
The quick answer is usually yes. Everything is noted, promised in stages and the product grows. The careful answer is another: it depends on whether each addition helps work better or just adds weight. Deciding what not to build is also part of the work.
“What if we add one more little field?”
The phrase seems harmless. A field is one more line. A notice is one more email. A new dropdown option doesn’t seem to change anything.
But no addition lives alone. It enters an operation with rushed people, incomplete information, chained decisions and little time to interpret screens.
There the question changes. It is no longer whether something can be added. It is whether the central journey is clearer after adding it. If the answer is doubtful, slow down.
Each addition is paid every day
Every feature has two prices. One is paid building it. The other is paid every day, for years.
That second price doesn’t appear in the meeting. It is time to understand what to complete, error from choosing wrong, doubt facing two similar fields and correction when data travels to quotation.
A confusing field costs seconds per operation. Repeated weekly, it becomes friction, unreliable data and decisions on half information.
A product improves when each addition beats that permanent cost, not when the list grows. The least complexity needed to correctly solve the problem is a working criterion.
From clear screen to instruction manual
Almost every internal tool is born clear. The opportunity is created in a minute. Quotation goes out with just data. Approval is recorded. Follow-up shows what is open and closed.
Then additions arrive. One for a special case. Another for one-off control. Another because once data was missing and nobody wants it repeated.
Each has its logic. Together they produce another effect: what was understood at a glance now demands explanations. Fields only one team uses appear, contradictory options, notices nobody reads because too many arrive.
If using the tool needs verbal explanation each time, the problem isn’t people. The product stopped supporting operations and started asking them to adapt to it.
Does that option avoid a frequent error or just document a fear? Does that step save coordination or move it elsewhere?
What is asked isn’t always what is needed
Whoever asks describes real annoyance. That must be respected. But their proposed solution doesn’t always solve the substance.
Someone asks for a field because information arrives late. Someone asks for a report because they don’t see pending items. Someone asks for extra approval because once a discount was wrongly applied.
The request is legitimate. The underlying need is another: timely coordination, clear visibility, a well-defined rule.
Building without that distinction costs dearly. The symptom is served and the problem stays. Before building ask what happened, when it repeats and whom it blocks.
Often what looks like a system gap is an unclear rule between people. And no feature orders what operations didn’t agree.
The commercial tool that wanted to please everyone
A commercial company had a simple tool for a known journey: opportunity, quotation, discount approval and follow-up.
At first it worked. Sales loaded opportunities with little data, generated quotations, asked approval if discounted and recorded follow-up. Enough to decide and coordinate.
Over time, each team asked its addition. Three changed daily use.
First, contact origin. Marketing asked replacing a simple option with a detailed list of over a dozen values, plus an open field. In practice, sales didn’t always know what to choose and completed to get past. Data became seemingly more complete and less reliable. Few clear categories and periodic review would have sufficed.
Second, discounts. Several combinable types were enabled, with different conditions, while real approval was asked through an informal channel to go faster. Result was confusion, observed quotations and delays. Few levels, conditions visible from quotation and a single approval path in the same place would have sufficed.
Third, follow-up. So nothing was lost, states, sub-states, reasons and notices were added. Intention was visibility. Effect was opposite: everything looked urgent and the team stopped distinguishing what asked for immediate action. Knowing what is open, what is stuck and who owns next action would have sufficed.
No request was absurd. But together they made the tool slower, harder to teach and less useful to decide. The journey was the same. What changed was the decisions needed to complete it.
When adding is worth it
It isn’t about freezing the product. Additions improving it exist and are recognized by concrete conditions.
Add when there is repeated, verifiable friction, not an isolated case. When the addition unblocks the central journey instead of decorating edges. When it reduces errors, rework or back-and-forth between teams. When the rule is already agreed and the tool only has to make it visible and easy to follow.
If quotations always stall for the same missing data, asking it upfront makes sense. If nobody knows who must approve, showing the owner in one place makes sense.
One thing is sustaining everyday work. Another is covering against the exceptional. The first simplifies. The second complicates.
Saying no is also managing
Dryly saying no breaks trust. Saying yes to everything breaks the product.
Two usual mistakes. One is measuring progress by delivered quantity, as if ten features were better management than three well solved. That metric rewards adding and punishes thinking. The other is designing for whoever insists most, although their case is minority. The product is shaped by the loudest voice, not real operations.
The middle path is firm: understanding annoyance, reviewing whether it repeats, testing an alternative before building and only then deciding. Often ordering the rule, removing a confusing option or unifying two similar fields suffices.
And when deciding not to build, explain it with the same care as a delivery: what was understood, why cost exceeds benefit, what is proposed instead and when it will be reviewed. A grounded no is also a professional answer.
A cared-for product builds trust because it doesn’t change with each request. People learn to use it and load information better. That stability is also a feature, although on no list.
Each feature has permanent cost. Only pay it when return is larger: fewer errors, less rework, clearer decisions, simpler coordination. Everything else is weight.