पाठशाला Pathshala · उत्पाद Utpād, The product · Lesson 16 · Build
Feature requests and the discipline of saying no
Every request is evidence and almost none is an instruction. Log each one with the job behind it and who asked, weigh it by the segment you serve, and say no in a way that keeps the customer.
Pathshala, The Founder Library · 11 October 2026 · 7 min read
The most dangerous customer a young company has is the one who pays well and asks for a lot. Each request is reasonable. Each takes a week. A year later the product does forty things for six customers and nothing quite well for the segment it was built for. Saying no is not a temperament. It is a system.
This lesson builds that system: why every yes costs more than it looks, an intake that weighs a request by who asked rather than how loudly, the arguments for yes that should be refused on sight, a way to decline that keeps the account, and the narrow conditions under which yes is right. The figure shows what a habit of yes does to a team’s capacity over three years.
Why every yes costs more than it looks
A feature’s cost is not the week it took to build. It is the share of the team it consumes for as long as it stays: the bugs it produces, the support tickets about it, the tests that must cover it and the redesign that has to carry it. Des Traynor’s Product strategy means saying no answers the objection that a change will only take a few minutes with four words: there are no small changes. Each addition brings complexity that is paid for later and by everyone.
Two numbers say how often that price buys nothing. Pendo’s 2019 Feature Adoption Report, drawn from 615 of its customers’ products, found that 80 per cent of features in the average software product are rarely or never used. And the Microsoft experimentation paper by Ronny Kohavi and colleagues found that only about one third of ideas improve the metrics they were designed to improve. A request is an idea someone else had. It is no more likely to work than yours.
At the defaults, six engineers saying yes to four requests a quarter, each costing four per cent of an engineer to keep, spend almost a third of the team on upkeep by the end of year three, and the curve keeps rising. Halve the yes rate and half of that capacity comes back, about one engineer’s worth, every quarter from then on. The upkeep figure is your estimate; last quarter’s bugs and support tickets, grouped by feature, will tell you roughly what it is.
An intake that weighs the request, not the volume
Requests arrive by WhatsApp, on sales calls, in support tickets and in the founder’s inbox. Put them in one place, a form or a sheet that everyone who talks to customers writes to, and record six things for each. Who asked, by account. Whether that account is in the segment you serve, using the [ideal customer profile](/library/ideal-customer-profile-on-one-page). What they asked for, verbatim. What they were trying to do when they asked, the job behind the request. What they do today instead. And how much revenue the account represents. Never promise a date at intake.
The job column is the one that matters. Customers ask for solutions; the team needs problems. A distributor asking for an Excel export usually wants to send a statement to a retailer or to reconcile with their accountant, and either may have a better answer than an export. Ask “what were you trying to do when you needed this?” and write the answer down.
Then weigh by segment. A request counts when it comes from an account inside the profile and counts again when another such account asks for the same job. Requests from outside the profile are logged and given no weight, however large the account. Traynor’s line on “713,000 people want it” applies at every scale: the question is not how many asked but whether the feature is valuable, within scope and useful to most of your customers. The [segmentation lesson](/library/segmentation-that-changes-what-you-build) shows how to draw the line.
Do not turn the log into a backlog to be groomed. Basecamp’s Shape Up argues that backlogs are a weight the team does not need to carry, that anyone can keep their own list of requests, and that really important ideas will come back. The log is a tally, not a queue. Items that keep returning from the segment you serve earn a spec; items that never return were not a problem.
What a quarter’s log looks like for a billing app serving distributors with 40 to 300 retail accounts. Ninety-two requests arrive. Thirty-one come from accounts outside the profile, mostly large wholesalers and two retail chains, and are logged with no weight. Of the sixty-one that remain, the jobs cluster: eighteen are some form of “record a part payment”, eleven are “send a statement to a retailer”, and the rest scatter across thirty-two different asks, none more than twice. The loudest request of the quarter, a custom GST report from the largest wholesaler, does not appear in the count at all. Part payments go to a spec. Statements go into the tally for another quarter. Everything else gets a decline.
The arguments to refuse
Traynor lists the arguments that get bad features built, and four come up in every Indian B2B company. This customer is about to quit. He calls it feature blackmail: building for one customer takes value from all the others and drifts towards what he calls consulting-ware. It will only take a few minutes. There are no small changes. We can make it optional. An optional feature still surfaces everywhere, in settings, in support, in every later design decision, and it weakens what the product is. Our competitors have it. They may be testing it, or regretting it, and copying them means delivering yesterday’s idea tomorrow.
A fifth belongs to the founder: we have nothing else planned. Traynor’s answer is that idle engineering time is better spent paying down debt than inventing a feature to stay busy. A team with nothing planned has a roadmap problem, which the [roadmap lesson](/library/roadmap-as-set-of-bets) addresses, not a shortage of requests.
A request is evidence about a problem. It is almost never an instruction about the solution.
Saying no without losing the account
Most customers do not leave over a declined request. They leave over feeling unheard. A decline that keeps the account has four parts. Restate the job in their words, so they know you understood what they were trying to do. Say plainly that it is not planned, and the reason, which is usually focus: “we are putting the next two quarters into faster collections for distributors”. Offer what exists: a workaround with the current product, an export, an integration, a partner who does it well. And promise one thing you will keep: to tell them if the answer changes.
Then keep it. When a request that was once declined later ships, because it recurred across the segment, tell every account that asked, by name, the same day. The [shipping lesson](/library/shipping-weekly-cadence-that-compounds) builds that message into the weekly changelog. A customer who has been told no honestly and later told yes has learned that the company listens and decides, which is the reputation a focused product needs.
The hard case is the large account outside the segment, say a distributor worth 15 per cent of revenue asking for a custom approval workflow. Ask whether the job is one the segment shares. If it is, it belongs in the tally like any other request. If it is not, the honest options are a workaround, a paid integration built outside the core product, or accepting that this account may outgrow you. What does not work is a special version of the product for one customer, because every later release must now be tested twice.
When yes is right
Say yes when four things are true. The request comes from accounts inside the profile. The same job has come back from at least three of them. It serves a bet already on the roadmap or makes the case for the next one. And it fits an appetite the team can name in people and weeks. The [prioritisation lesson](/library/prioritisation-rice-and-one-question) ranks what survives. Say yes, too, to requests to remove things: a customer who asks for less is doing the team a favour.
The monthly request review
Once a month, forty-five minutes, the founder and whoever owns product read the log. Count requests by job, inside the segment only. Promote any job with three or more accounts to a spec’s problem block, with the quotes. Send a decline to every request older than a month that will not be built, using the four-part message. Tell everyone whose request shipped. And once a quarter look at the features nobody uses and remove one, because the upkeep tax is paid on everything left in the product, including what nobody asked for twice.
The figure is a model with assumptions you set; the adoption and experimentation figures are from the sources below.