The Cost of Saying Yes to Everything
Each yes buys work once and charges you rent on it forever.
A sales lead asks for a small thing. Two days of work, they say, and it unblocks a deal. You look at the estimate, agree it is two days, and say yes. Eighteen months later that feature has a config flag, a support macro, a line in the onboarding tour, three open bugs, and a customer who will churn: The rate at which customers stop paying or stop using the product. if you remove it. It was never two days. It was two days plus rent.
Teams reason about features as purchases. They are closer to pets. The purchase price is the build cost and it is the smallest number involved.
What the yes actually costs
What a yes actually costs
- Build
- The estimate you argued about. Usually the only cost anyone writes down.
- Carry
- Every future change now has to work with this. Each new feature multiplies against the ones already there, in QA, in support, and in the mental model engineers hold.
- Attention
- Surface area competes for the user's eye. Adding an option makes every other option slightly harder to find. This cost lands on people who never asked for the feature.
- Commitment
- Once a customer relies on it, removing it becomes a negotiation. Reversibility drops to near zero within a quarter.
- Signal
- Saying yes teaches the requester how to get things. The next request arrives framed the same way, and now you have a process.
Worked example
Hypothetical: Corvid, an analytics tool
Corvid says yes to a custom CSV export format for one enterprise account. Build is four days. Over the next year: two days keeping it working through a schema change, a day of support tickets from other customers who found the option and assumed it did something else, half a day of QA on every release that touches exports, and a week of design time spent working around it during a settings redesign because the team could not remove it. Call it roughly three weeks against a four day estimate, and it is still there, and the account that asked for it downgraded in month nine. None of those costs appeared in the decision, because the decision only had a field for build effort.
The fix is not to become a team that says no more often as a personality trait. Reflexive refusal is its own failure, and it usually means the PM has no way to tell a good request from a bad one so defends the roadmap on principle. The fix is to make the full cost visible at the moment of the request, and to give the requester a real choice.
Yes by default
- Costed as build effort only
- Requester never sees what moved
- No expiry, no review
- Special cases accumulate silently
Yes with a price
- Costed as build plus carry plus the item displaced
- Requester picks what to drop
- Reviewed at six months against its stated outcome
- Special cases logged, counted, and reported
Three sentences that do most of the work. Yes, and here is what moves out to make room, which do you want. Yes, if it earns X by date Y, and otherwise we remove it. Not now, and here is the condition under which it becomes a yes. All three are agreements rather than refusals, which is why they hold up in a room where you do not have the most authority.
Notice that the second sentence is the strongest one and the least used. A conditional yes turns a permanent commitment into a bet with an expiry date, and it converts the argument from whether the feature is good into what evidence would settle it. Most requesters accept this readily, because they genuinely believe the thing will work and a review in six months sounds like vindication rather than a threat.
Keep a count, too. The number of special cases in the product is a metric, and a team that has never measured it is usually shocked by the total. Report it quarterly next to your other numbers. Nothing changes a culture of small yeses faster than a chart of them going up.
One caveat before you take this too far. The cost of a yes scales with how deeply it embeds. A standalone report that shares no code, no settings and no screen real estate with anything else carries much less rent than a new field on the core object that every screen has to handle. Ask where the request lands in the architecture, because that, and not the estimate, is what predicts what it will cost you in year two.
Quick check
Why is build effort a poor proxy for the cost of a feature request?
The takeaway
Every yes costs build plus carry plus attention plus commitment, so price it at the moment of the request, not at the retro.
Try this tomorrow
Next time someone asks for a small feature, reply with the cost plus the name of the item it would displace, and let them choose.
Answer the check above, then bank the day.
Where this comes from
- Good Strategy Bad Strategy, Richard Rumelt
- Escaping the Build Trap, Melissa Perri
- Inspired, Marty Cagan
Strategy is one of six tracks. These lessons summarise and build on the work above, they do not reproduce it. Buy the books, they are better.