The Cost of a Feature
The sprint is the cheapest part. Support, performance, complexity and eventually removal arrive after launch, keep arriving, and are paid by people who were not in the planning meeting.
The ask, the obvious response, and how it goes wrong
Every lesson starts where the work starts: someone asked for something, and the first response that comes to mind has a problem.
What will this feature cost every month after it ships, and who pays?
Marketing asks for gift wrapping at checkout before the holidays: "It is just a checkbox and a note field. Two days, right?"
It really is a checkbox, a text field and a line item. Two days for the UI, half a day for the order model, done well before December.
The warehouse needs to know which orders to wrap, so the pick list changes — and the pick-list export belongs to another team with its own backlog.
- The warehouse needs to know which orders to wrap, so the pick list changes — and the pick-list export belongs to another team with its own backlog.
- Gift notes arrive with emoji and 800-character messages that the packing-slip printer truncates. Support gets tickets about missing notes; the fix is a character limit marketing did not want.
- A wrapped gift is returned by the recipient, not the buyer. Who gets the refund, and does the wrap fee come back? Finance needs an answer before the first return, and there is none.
- Every later checkout change now has to test the gift path. The checkout redesign in spring takes longer because of a checkbox whose reason nobody remembers.
- Outside December almost nobody uses it. Removing it means telling marketing, changing the warehouse process and migrating a column, so it stays — costing a little, forever.
What is really going on
- Build cost is paid once, by the team, visibly, in the sprint. Everything else is paid continuously, by other people, invisibly. Estimates only ever count the first.
- Support cost: every feature is a new way to be confused and a new question to answer. It grows with the number of shoppers, not the number of lines of code.
- Performance cost: an extra query, an extra script, an extra step. Each is small; together they land on the pages that matter most, and nobody owns the sum (Guardrail Metrics).
- Complexity cost: each feature multiplies the paths through the system. A checkout with gift wrap, guest checkout and three payment methods has combinations that every future change must consider. This is the cost that makes a team slower every year.
- Removal cost: taking a feature out is a project — someone relies on it, data depends on it, a process grew around it (Deprecating a Feature). A feature that is cheap to add and expensive to remove is a one-way door dressed as a two-way one (Reversible vs Irreversible Decisions).
- Opportunity cost: the days spent on it, now and later, were not spent on something else. It is the largest cost and the one nobody writes down.
Everything the checkbox touches
The checkbox is on one page. What it changes is spread across the business, most of it owned by people who were not in the meeting where "two days" was agreed.
None of these costs is large on its own, which is why none of them gets raised. Drawing them in one place is usually enough to turn "two days" into a more honest conversation.
Writing the running costs down
The artefact is small: a few lines in the ticket under the build estimate. Its value is that the people who pay later are named now, and that the removal bar is written while everyone still agrees on it.
- Support — what new question will shoppers ask, and what does support need to see to answer it?
- Performance — does it add a query, a script or a step to a page with a budget?
- Complexity — which future changes will now have to consider this path?
- Removal — how hard is it to take out, and what is the bar for doing so?
- Owner — who watches it after the launch week?
1## Build2Checkbox, note field, order column, line item: about 2 days3Pick-list export change (owned by Fulfilment): about 2 days, their queue4Packing-slip template: about 1 day5 6## Running costs7Support: questions about truncated notes. Asked them; they want the note visible in admin.8Performance: none measurable, one column on an existing query.9Complexity: gift path must be tested in every checkout change from now on.10Finance: rule needed for returned gifts before the first return. Open, owner: marketing + finance.11 12## Removal13Behind the gift_wrap flag. Offered December 1 to December 24 only.14Bar agreed with marketing: under 1 in 50 December orders -> off in January.15Owner after launch: checkout team.The open finance question has an owner who is not engineering. Naming it is the engineer's job; answering it is not.
Putting the price in front of marketing
The same facts can land as a veto or as help. The difference is whether the value is acknowledged first and whether a cheaper shape comes with the price.
Marketing asks for gift wrap in October and calls it a two-day checkbox. You have spent twenty minutes asking the warehouse, support and finance what it changes for them.
"It is way more than two days. It touches the warehouse, printing, returns, finance... honestly we should push it to next year."
"Gift wrap makes sense for December. The checkbox is two days; the whole thing is about a week and a half, because the pick list and packing slips change too. I would suggest notes up to 150 characters, offered from December 1, behind a flag — and we agree now that if fewer than one in fifty December orders use it, it goes off in January. Finance needs a rule for returned gifts; could you settle that with them this week?"
How much accounting a feature deserves
Pricing every feature in detail is its own waste. The accounting should scale with how much the feature touches and how hard it would be to take back.
How much cost analysis before building?
when Internal-only changes, anything behind a flag that is trivial to delete, and experiments with a fixed end date.
cost Now and then a throwaway becomes permanent without anyone deciding that it should.
when Any user-visible feature, especially in checkout, the cart, or anything touching money, stock or the warehouse.
cost A few messages and a paragraph in the ticket. Sometimes it finds nothing, and that is fine.
when Changes to the order model or payments, or anything customers will build habits or integrations on.
cost Days of other teams' time and a slower start that the requester will notice.
How to do it
Most important first.
- Estimate the life, not the sprint. List everyone who touches the feature after launch — support, warehouse, finance, the next team to change checkout — and ask each one question: what does this change for you?
- Write the running costs next to the build estimate in the ticket, even in rough words. A cost that is written down can be discussed; one that is not will be paid silently.
- Prefer shapes that are cheap to remove: behind a flag, in its own table, not rewriting existing data (Feature Flags as Product Tools).
- Agree a removal bar before launch, with a number and a date: "If fewer than one in fifty December orders use it, we switch it off in January." A bar set while everyone agrees is the only kind that gets honoured later.
- Name an owner for after launch. A feature with no owner collects every cost and none of the attention.
- Bring the costs back into the decision as information, not as a veto: "Two days to build, plus these three things. Still worth it?" Often it still is.
How to explain the decision
The sentences, the order, and what to lead with — for someone who did not make the call.
- Lead with agreement on the value, then the whole price: "Gift wrap makes sense for December. The checkbox is two days; the whole thing is closer to a week and a half, because the warehouse pick list, the packing slip and returns all change."
- Make the running costs concrete and owned: "Support will get a new kind of ticket about notes, and I have asked them what they need to see. Finance needs a rule for returned gifts before the first one comes back."
- Offer the cheaper shape: "If we limit notes to 150 characters, only offer it from December 1, and put it behind a flag, most of the ongoing cost goes away and we can switch it off in January."
- State the removal bar up front, as a question: "Can we agree now that if fewer than one in fifty December orders use it, it goes off in January?"
- "It is just a checkbox." The checkbox is two days. What it touches is the warehouse, the printer, returns and support. I am not saying no — I am saying the real number is about a week and a half, and here is a version that costs less.
- "We will deal with those problems when they come up." Some of them, yes. The returned-gift question will come up in the first week of January with an unhappy customer attached, and I would rather the rule exist by then.
- "You are overthinking a small feature." Possibly — the list took twenty minutes. If none of it matters we lost twenty minutes; if the printer issue is real we avoided a December incident.
What can go wrong
- Cost as a veto: listing every conceivable future cost to kill a feature you did not like. An honest list includes the costs that turned out small.
- Counting only engineering. Support time, warehouse process and finance reconciliation are real, and they are paid by people with less power to refuse.
- Promising to remove it later and never doing it, which teaches the organisation that "we will remove it if it does not work" means nothing.
- Over-building for removability: an abstraction layer so the feature can be unplugged, costing more than the feature itself.
- "Features are liabilities, so fewer is always better." Features are how the store earns money. The point is to buy them knowing the price.
- "The cost is engineering time." Engineering time is the part you can see. The rest is paid by support, operations and whoever changes this code next.
- "We can always remove it later." You can, it will cost more than adding it did, and someone will object. Decide the removal bar before launch.
- "Small features are cheap." Each one is cheap to build. Many of them together are the most common reason a checkout becomes hard to change.
Knowing whether it worked
- The ticket has a "who else pays" section, and the people named in it were asked before launch, not after.
- Support tickets about the feature in the month after launch are roughly what you predicted — and you checked.
- A feature is switched off on the date agreed at launch without a fight, because the bar was set in advance.
- Checkout performance stays inside its budget after the feature ships.
- The team can name the owner of every user-visible feature in its area.
- At a few hundred orders a week, the running cost of a checkbox is close to zero and arguing about it is waste. At 10x shoppers, support cost grows with every confused one and becomes the dominant cost of small features.
- At 10x team size, complexity cost turns into coordination cost: every feature in checkout is something another team must understand before it can change checkout.
- At 10x features, the product itself gets harder to use, and each addition makes the ones before it harder to find. The bar for adding should rise with the count.
- Honest cost accounting makes you the person who complicates simple asks. Do it lightly and often rather than heavily and rarely.
- Running costs are estimates, and you will sometimes be visibly wrong about them in both directions.
- Building for removal — flags, separate tables — costs a little up front, and that cost is wasted on the features that stay.
- Telling marketing "this costs more than it looks" before their busiest season spends goodwill you may want back in January.
Where this applies
Product advice is context-sensitive. These labels say what each claim is specific to, and where a different stage, team or product would differ.
- GENERALEvery feature has running costs beyond its build. How large they are differs sharply: a checkbox on an internal admin screen costs almost nothing after launch, the same checkbox in consumer checkout touches support, fulfilment and finance.
- STAGE-SPECIFICPre-product-market-fit, complexity and removal costs matter less because much of the product will be rewritten anyway. In a mature product with years ahead of it, complexity cost dominates and the bar for adding should be higher.
- PRODUCT-SPECIFICIn B2B with contracts, removing a feature a customer pays for is a commercial negotiation, not a flag flip, so removal cost is far higher than in a consumer store where most shoppers never notice.
Where the depth lives
This domain teaches the product-side judgement and hands the mechanism off.