How would you price a feature that no customer asked for?

First explain the silence

"Nobody asked for it" is data, and pricing before you have interpreted it is how a feature ends up with a price sheet and a one per cent attach rate. There are four explanations and they lead to different answers.

The need may be latent but real, where customers experience the problem and have no vocabulary for the solution — this is the case for most infrastructure-shaped features, since nobody requests a permissions model, they request that a particular person stop seeing a particular report. The need may sit with a buyer you never talk to, typically security, procurement, finance or legal, whose requirements arrive as questionnaire rows rather than feature requests. The need may be anticipatory, driven by a regulatory date or a platform change that has not bitten yet. Or the need may simply not exist, and the feature is somebody's conviction.

Only the fourth case means do not build it. The first three all justify building, but they imply very different pricing, because they have different buyers and different alternatives. Say which one you think you are in and what evidence puts you there — lost-deal notes and security questionnaires for the second, a compliance deadline for the third, and workaround archaeology for the first. If you cannot produce evidence for any of them, the honest answer is that this is a pricing question you should refuse to answer yet.

Packaging decides more than price

The price is the last decision, not the first. Before it, choose which of three shapes the feature takes, because the shape determines who can buy it and what you are allowed to charge.

Making it core, available to everyone, is correct when the feature raises win rates or retention across the base rather than serving a segment — audit trails and single sign-on often belong here despite being classic paid add-ons, because gating them means losing deals you would otherwise win. Making it a tier upgrade is correct when the feature correlates with a customer characteristic you already price on, such as company size or seat count, so it strengthens an existing fence rather than adding a new one. Making it a paid add-on is correct when demand is genuinely narrow, willingness to pay is high among that narrow group, and the value is not correlated with anything you currently meter.

The add-on is the default choice and usually the wrong one for a feature with no demand signal, for a mechanical reason worth stating: an add-on has to be sold. It needs a listing, a sales motion, an objection-handling answer and a renewal conversation, and it earns nothing until someone actively chooses it. A feature nobody asked for has no pull, so it will not sell itself, and a small add-on line can easily cost more in sales attention than it collects.

Working the numbers

Take a mid-market analytics product with 1,200 paying accounts, an average of £900 a month each, and a proposed audit-log-and-access-review capability originating from security questionnaires rather than requests. Assume the annual base is 1,200 times £900 times 12, which is about £13 million.

For the add-on route, assume the feature appeals to the roughly 15 per cent of accounts in regulated industries, so 180 accounts, and that with active selling you attach half of them over a year, so 90. At £150 a month that is 90 times £150 times 12, about £160,000 a year. State the assumption that matters: attach rate, because at 10 per cent of the addressable 180 rather than 50 per cent the line is worth about £32,000 and is not worth a sales motion at all.

For the core route, the value is defensive and shows up in two places. Assume you lose deals on this requirement at some rate — if your notes show it named in 8 per cent of losses and you lose 200 qualified deals a year, that is 16 deals, and at an average first-year value of £10,800 that is about £170,000 of recovered new business if the feature converted all of them, and half that on the more sober assumption that it converts half. Then add retention: if it is the stated reason for even three regulated accounts leaving a year, that is three times £10,800, roughly £32,000 of preserved revenue plus whatever those accounts would have expanded to.

Route	Assumption driving it	Annual effect
Add-on at £150 a month	90 of 180 regulated accounts attach	~£160,000 new revenue
Add-on, pessimistic	18 accounts attach	~£32,000, below the cost of selling it
Core, win-rate effect	Half of 16 lost deals recovered	~£85,000 new revenue
Core, retention effect	3 regulated accounts retained	~£32,000 preserved

These figures are arithmetic on stated assumptions rather than observed values, and the useful output is not the totals but the finding that the two routes are within the same order of magnitude while the add-on route depends entirely on an attach rate you have no evidence for. When a defensive route and a revenue route are comparable in size, take the one whose key assumption you can actually verify.

Price against the alternative

Whatever the packaging, the price comes from what the buyer would otherwise do, never from what the feature cost to build. Development cost is sunk and irrelevant to the buyer, and cost-plus pricing on software reliably leaves money on the table for features with narrow high-value demand while overpricing broad low-value ones.

So enumerate the alternatives concretely. For the audit capability, a regulated account's alternatives are a manual quarterly access review costing some number of analyst days, a third-party tool with its own licence, or failing the audit. If the manual review is two analyst-days a quarter at a fully loaded £400 a day, that is £3,200 a year of labour, which puts a £150 a month add-on at just over half the cost of the status quo — defensible, and the sentence a salesperson can actually use. That is the anchor, and it is also the reason to state the price as a number the buyer can compare rather than as a percentage uplift they cannot.

The mistake that costs the most

The expensive error is not picking the wrong number, it is metering on something uncorrelated with value and then being unable to change it. Price on a dimension that grows as the customer gets more value — seats under review, accounts monitored, events retained — rather than a flat fee that a ten-person customer and a ten-thousand-person customer pay identically. And check the cannibalisation before you launch: if the new add-on is the main reason accounts currently upgrade to your top tier, selling it separately can lower revenue while every individual transaction looks like a win. Quantify that with the number of accounts on the top tier who cite this capability, and if it is most of them, the feature is not an add-on at all.

Interpret the silence, choose the packaging, then price against the buyer's alternative — and treat any add-on whose case rests on an unmeasured attach rate as unproven rather than promising.