When a Feature Request Displaces a Better Investment

The business situations in this article are fictional illustrations, not accounts of Parikh Advisory client engagements.

A large prospect asks for an advanced dashboard. Sales says the deal depends on it. Engineering can deliver it in three sprints, so the founder agrees. When the dashboard launches, almost nobody uses it. Meanwhile, new customers still struggle to finish onboarding.

Illustrative scenario, not a client result. Low use does not prove the dashboard was pointless. Perhaps the account team never trained the right people, the data could not be trusted, or the buyer valued having the capability available for an occasional audit. The mistake happened earlier: a request became a roadmap commitment before the team established what decision it would improve and what work it would displace.

A feature request contains several possible problems

Ask the prospect for the last occasion when the missing dashboard caused trouble. What were they trying to decide? Which information was unavailable? Who needed it and by when? What did they do instead, and what did that workaround cost? “We need visibility” can mean a manager needs a weekly comparison, an operator needs one overdue item flagged, or a buyer needs evidence for procurement. These call for different responses.

A dashboard is appropriate when people repeatedly inspect changing information, compare it, and act on it. If the immediate job is to alert one owner when a task is late, a targeted notification or exception queue may be more useful. If the data is stale, a beautiful dashboard can make the wrong answer easier to see. The request deserves investigation, not dismissal.

Also ask who requested it. A buyer may want a contractual assurance; a daily user may need an entirely different workflow. The person paying, the person using and the person maintaining the data are not interchangeable sources of evidence.

The price includes what the team cannot do

Three sprints of engineering are visible. The onboarding improvement postponed by those sprints may be less visible and more consequential. Compare both opportunities using the same questions: whose problem, how frequent, what consequence, what evidence of value, and what effort to deliver and maintain? Avoid pretending either estimate is precise when the team has not measured the baseline.

The prospect may still justify a special investment. A signed commitment, strong strategic fit and a repeatable need across similar accounts could make the dashboard worth building. If the value belongs mainly to one buyer, call it a customer-specific commercial decision. Discuss price, maintenance, ownership and effects on the common product. Do not quietly reclassify a bespoke request as evidence that the entire market wants it.

The cost of an unnecessary feature continues after launch. Someone must maintain data definitions, permissions, documentation and support. The feature also becomes part of the promise sales makes to the next customer. That ongoing commitment can exceed the initial build effort.

A small test that could change the answer

Before committing, watch a few relevant users perform the underlying job with their current tools. A handful of sessions can reveal where information is missing and whether the proposed dashboard would be consulted; it cannot estimate demand across the whole market. Review support requests or sales notes for similar cases, and verify whether those records describe the same problem or merely repeat the prospect’s wording.

Then test a narrower response. For the overdue-item case, send a timely status notification or provide a simple exception list. Observe whether the intended person takes the needed action and whether the data is reliable. For recurring comparative analysis, prototype the dashboard with actual decisions and realistic data. Ask users to act, not merely say whether they like it.

Agree on a disconfirming result in advance. If the prospect cannot name a decision the dashboard enables, or the narrower response resolves the observed delay, the case for a permanent surface weakens. If users repeatedly make a valuable decision that cannot be supported by a simple alert, the case strengthens.

Give sales an honest answer

A product team cannot respond to a consequential prospect with “we need more research” and leave sales without a path. Write down the buyer’s underlying requirement, what the current product can do, the proposed short test, the decision date and what has already been promised. Sales can then discuss a specific route to the outcome without promising a feature the company has not approved.

If the contract explicitly commits to the dashboard, the question changes. The team must assess the obligation, negotiate a responsible scope if necessary, and deliver or resolve the commitment. The earlier discovery mistake does not erase a promise already made.

Return to the roadmap meeting

Put the dashboard and onboarding problem side by side. For each, name the affected customers, evidence, expected consequence, confidence and maintenance cost. The founder owns the trade-off. Engineering estimates delivery; sales explains the commercial stakes; customer-facing teams describe the work users actually do. None of those perspectives alone determines the answer.

The decision might be to build the dashboard, to sell a narrower customer-specific solution, to fix data and notifications first, or to protect onboarding work. What matters is that the decision remains visible and revisitable. Record the signal that would cause the team to change course after release.

Five questions before funding a feature

• What real decision or job does the request help, and who performs it?
• How often does the difficulty occur, and what does the current workaround cost?
• What smaller response could test the need without creating a permanent product obligation?
• Which committed work would this displace, and whose customers bear that delay?
• Is this a repeatable product bet, a customer-specific commercial commitment, or an unsupported assumption?

Research note: Silicon Valley Product Group’s discussion of product planning identifies opportunity cost as a central consequence of weak feature choices. Its discovery guidance separates testing value and usability from feasibility and business viability. The dashboard story is fictional; the decision questions above are Parikh Advisory’s editorial synthesis.