Feature Request

Origin & evolution

The discipline around feature requests grew out of a long argument about how much to trust what customers ask for. The argument's mascot is the "faster horse" line, the claim that customers asked for faster horses would have missed the car. The line is almost certainly not Henry Ford's; Quote Investigator traces its earliest attribution to him only to 2001, decades after his death, and the Harvard Business Review noted there is no record of him saying it. The fabricated quote is still useful as a parable: a request names a solution ("faster horse") that points at a real underlying need (get places quickly, with less hassle) without naming it. The job🔨JobUserJob To Be Done: what the user is trying to accomplishView reference → is to recover the need from the request.

Lean and discovery practice gave the parable a method. Teresa Torres's opportunity🚪OpportunityDiscoveryA validated gap worth solvingView reference → solution tree, set out in *Continuous Discovery Habits* (2021), draws a hard line between an opportunity (a customer need, pain, or desire framed in the customer's terms) and a solution (anything you might build to address it). Her test for any incoming request is blunt: is this really a need or a pain point, or is it a solution in disguise? A feature request is, almost by definition, a solution in disguise. Treating it as the start of an investigation🔍InvestigationEngineeringAn investigation into an issue or incidentView reference →, never as an order on the backlog, is the shift the field made.

The vote-counting trap is the modern complication. Public roadmaps🛣️RoadmapProduct SpecificationA strategic plan of features and milestonesView reference → and feedback portals let requests accumulate upvotes, which feels like prioritisation but quietly biases toward the loud, the existing, and the easy to articulate. Counting votes on solutions tells you which solutions are popular among people who already use the product and bothered to post. It does not tell you which need, once met, would change the business, and it never hears from the people who left.

How it works in practice

A B2B tool collects 140 requests for a "duplicate project" button over a quarter. Vote-counting says build the button. The team instead reads the requests as clues and interviews a dozen of the requesters. The underlying need turns out to be setting up near-identical projects for new clients without redoing twenty fields each time. A duplicate button solves the narrow case. A reusable project template solves the actual need, serves people who never thought to ask for duplication, and opens an onboarding-acceleration opportunity worth more than the original feature⭐FeatureProduct SpecificationA product capability or featureView reference →. The 140 votes were a real signal of demand and a poor specification of what to build.

Feature request vs. its neighbours

• Customer feedback🔶Customer FeedbackCustomer SuccessVoice-of-customer inputView reference → is the raw input of any kind: praise, a complaint, a bug🐛BugProduct SpecificationA defect or unexpected behaviourView reference → report, a request. A feature request is the subset shaped as "build me X". Feedback is the stream; the request is one recognisable shape it takes.
• Need is the underlying motivation the request points at, stated independently of any solution ("set up new client projects fast"). The request is the customer's guess at a solution to that need. Many different requests can map to one need.
• Opportunity is the framed, prioritisable gap between current state and a met need, the level at which you actually decide what to build. A request creates an opportunity once you have recovered the need behind it; the opportunity, not the request, is what belongs on the discovery tree.

In the graph

In the Unified Product Graph, feature_request🙏Feature RequestCustomer FeedbackA user-submitted feature request sits in the feedback region as a clue, wired so it can never quietly become a roadmap line by itself. feedback_program_collects_feature_requestFeedback ProgramcollectsFeature Requesthierarchy and customer_feedback_becomes_feature_requestCustomer FeedbackbecomesFeature Requestcross-domain record where requests come from, and product_has_feature_requestProducthasFeature Requestcross-domain and feature_request_from_behavioral_segmentFeature RequestfromBehavioral Segmentcross-domain attach them to the product and to who is asking. feature_request_voted_on_by_feedback_voteFeature Requestvoted on byFeedback Votehierarchy captures demand without letting the count masquerade as a decision⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference →. The load-bearing edge is feature_request_creates_opportunityFeature RequestcreatesOpportunitycross-domain: it forces the request through the opportunity layer before anything gets built, which is the graph encoding the lesson the field learned, that a request is evidence🔎EvidenceValidationData supporting or refuting a hypothesisView reference → of a need and not an instruction to satisfy it.