An urgent feature request from a big client or sales: quick fix or reusable feature?

Settle the scope before anyone designs: are you buying a fix for this one client by a set date, or a capability the whole product will carry? Build the narrow fix when the date is real, the need is unlikely to recur and the fix is cheap to remove later. Build the reusable capability when other customers have the same need or the narrow fix would add a one-off setting or screen. Say "not yet" when one account would rewrite the roadmap. Either answer can be right; the mistake is not choosing, or letting the client's wording choose for you.

A product-wide bug is a different decision, closer to incident response, and is outside this article.

The scope decision comes before the design decision

An urgent request arrives as a name, a deal and a date, not as a scope question, and unless someone asks the scope question, the request's own wording answers it. One study of how a software company prioritises suggests which way that default leans. In a 2019 case study of one European software company (Dasanayake, Aaramaa, Markkula and Oivo, fifteen interviews with the people acting as software architects in its teams, published in the Journal of Software: Evolution and Process), the customer was the dominant factor in prioritising requirements: the bigger the customer, the higher the priority of its requirements. It could be very difficult to reject a request from a customer who was very important to the company. The company's prioritisation favoured market needs over architectural considerations, and the authors report that overlooking architecture when prioritising accumulates architectural technical debt. It is one company, so it shows a pattern rather than a rate, and it is about priority rather than scope. The pressure it describes is the same one, though: if nobody states the scope, the size of the account is likely to set it.

At Tcules, we once watched the same brief split two ways in an hour. In a one-hour design challenge, two teams of three of our designers were asked to add an AI feature to SurveyMonkey for restyling survey questions and changing their response types. One team solved the given use cases first and fast; the other built a more general feature that could carry other changes later. Our designer Varun Mashru, who narrated it, put the difference down to how each team saw "their goals and initial requirements", and said the quick approach suits a product manager who wants something fast without extending it to other areas, while the general one suits covering several use cases in one implementation. It was an internal exercise on someone else's product, not client work, and it shows no outcome. What it does show is that the brief alone did not decide the scope. The product manager has to.

A decision rule you can use the same day

Ask these before design starts. A request can show signals on more than one side; count them, and write down which way you went and why.

When the signals split, the answer can be both, in order: design the capability, and ship the client's case first as its first slice. At Tcules, we ended our exercise in a similar place: each team had valuable solutions that could be brought together in one final proposal. Hold the date and cut the scope to fit it, rather than the other way round.

Find out what is actually going wrong before choosing

A feature request is a proposed solution. Before it can tell you whether the need is one client's or everyone's, you need the problem underneath it. Ryan Singer's Shape Up, written from how Basecamp builds its own product, describes not taking a customer's request "at face value". In its calendar example the team asked the customer not why she wanted a calendar but when: what she was doing when the thought occurred. The question behind it, in the chapter's words, is at what point the current workflow breaks down without the thing being asked for. The same chapter sets an appetite, the time the work is worth, before any design: "Appetites start with a number and end with a design." For an urgent request the date can supply the appetite; the open question is what the work should be.

Clayton Christensen and colleagues frame the same move as the job to be done (2016): the progress a customer is trying to make in a given circumstance. If the job behind one client's request is one your other customers also do, the request is a reusable capability described in one client's words. If the job only exists because of how that client runs their business, it is a special case, however large the account.

Then check the record. Some product companies write this rule down: the PostHog handbook (checked 16 October 2026) says the company will not build a niche feature for a single big customer, and records and feeds back to product the requests it can see benefiting several customers. A request log searched by problem, not by feature name, tells you whether "other customers have asked" is true.

When to say no, or not yet

At Tcules, we put this question to Samy Melaine, Founder and CPTO of Eden AI (Eden AI is our client). In that conversation I described the pressure a sales-led product feels: the sales team brings an opportunity, the prospect wants a couple of features shown in the demo, and the product manager has a plan, and money on the table. Samy's answer was that this can cause a lot of bad decisions, especially when the money is large: you "change your roadmap for one client and regret that". Early on, he said, Eden AI had demanding big clients and had to say no to a lot of changes, and chose to build the product for a broader community instead. The same roadmap did move for users: he described it as a communication tool rather than a fixed plan, and AI detection came forward because many users asked for it. (Watch the episode.) The difference between those two decisions is the difference between one account and many.

Des Traynor of Intercom made the same argument in Product strategy means saying no (2013). He calls the "this customer is about to quit" request "feature blackmail", argues that "there are no small changes", and warns that making a feature optional is no escape: every optional feature, he writes, weakens the product's definition. That is why a one-off setting counts as a signal against the narrow fix in the table above.

The evidence does not say "never build for one customer". Paul Graham's advice to early B2B startups in Do Things that Don't Scale (2013) is to pick a single user and build as if for them alone, because fitting one user's needs closely is, in his view, how you find something other users want too. In a footnote he grants that you could end up making something only one user needs, and says the founder can generally see when that risk is real. The difference is stage. Before you know your market, one demanding customer may be the best evidence you have. Once many customers depend on the product, one account's demand is evidence about one account.

"Not yet" can be an honest answer, and a real one. Shape Up's default response to a raw idea is "Interesting. Maybe some day.", a soft no that keeps the option open. Tell the client and the sales team what would change it: other customers with the same job, or a version of the request that fits the product's direction.

When the quick fix is right, treat it as debt with a repayment date

Sometimes the answer is yes to the narrow fix, and that can be the right call. At Tcules, we heard the commercial reality put plainly by one guest in our Mastering Design Decisions conversation: a big project and a big client sometimes mean changing the product "even though it is not ideal". The same conversation separated the must-have from the good-to-have: start with the basic version that meets today's need, and work towards the ideal on a timeline.

Ward Cunningham coined the debt metaphor in his 1992 OOPSLA experience report. He was writing about shipping code before it is fully right, not about one client's feature, but the rule carries over: "A little debt speeds development so long as it is paid back promptly with a rewrite." The danger, he wrote, is debt that is not repaid. A narrow fix becomes that kind of debt when nobody records what was deferred. So, with the fix, write down:

• what the client's version leaves out compared with the capability you would build for everyone;
• who owns the follow-up decision, and when it will be made;
• how the fix would be removed or absorbed if the general capability arrives.

That note is what makes the guest's "work towards it with a timeline" a plan rather than a hope.

What a compressed cycle still has to include

At Tcules, we set even the one-hour exercise four deliverables: prioritised use cases, a written solution, the information architecture or user journey, and an interface showing both. As Varun describes it, the product manager learns of the urgency and brings the designer in to solve the problem "without creating new ones". A normal cycle has time to understand, research and analyse; for an urgent request, he says, the response is very different. Whatever else is cut, these should stay:

1. A written problem statement. One paragraph on what is going wrong and for whom, before any screen.
2. Prioritised use cases. Which cases the first release must handle, and which it can leave.
3. A written solution and the journey through it. The structure and flow, so engineering and the client can check the logic. Our information architecture and workflow design work starts here.
4. Solution fidelity before UI fidelity. Both teams in our exercise made sure the solution worked before matching it to the brand and polishing the interface.
5. A check that the fix creates no new problem in the parts of the product the client never mentioned.
6. A note of what was deferred, from the previous section, so the next decision has something to start from.

Deciding what the product needs to do, how it should be structured and how it should behave, before the interface, is the core of our Product Design work. An urgent request does not remove that step; it makes it shorter, and it makes skipping it more expensive.