Your Feature Request Form Is a Bug Tracker in Disguise
TL;DR
Open your feature request form and read the fields: title, description, priority dropdown, category picker, an optional "additional context" box. Now open your internal bug tracker: summary, description, severity, component, steps to reproduce. It's the same form. Someone changed the page title, pointed it at customers, and called it listening.
A form built to triage defects extracts defect-shaped input. Customers file solutions ("add CSV export") instead of jobs ("I rebuild this report for my CFO every Monday"). The priority dropdown comes back "High" on every submission. The context box comes back empty. And the submissions meet the same fate as bugs: a triage queue, a label, and a backlog where they quietly expire.
Your feature request form is collecting symptoms. Your roadmap is supposed to solve jobs. Nobody's surprised the gap is real.
This post covers:
- The field-by-field autopsy: which parts of your request form are bug-tracker inheritance
- Why this happens (the Jira template was right there, and nobody rethought it for external input)
- What customers are actually trying to communicate: the job, the workaround, the alternative, the business impact
- Why most requests point at a handful of underlying jobs, and how honest that famous 80/20 framing really is
- Why the customer-facing priority field should die
- The replacement form, field by field, with a before/after table you can copy Monday
- How symptom-to-job mapping connects to the roadmap, which is the PM's actual job
Why Is Your Feature Request Form a Bug Tracker in Disguise?
A feature request form is a bug tracker in disguise when it collects product input through defect-tracking fields (title, description, severity, category) and routes submissions into a triage queue. That format was designed to move known problems toward a fix. Pointed at customers, it extracts solution-shaped symptoms and discards the job, workaround, and business context a roadmap decision actually needs.
Look at the lifecycle, not just the fields. A bug enters the tracker, gets a severity, gets a status, and either gets fixed or gets closed as "won't fix." A feature request enters the portal, gets a label, gets a status ("Under review," the politest coffin in software), and either gets shipped or sits in the backlog until the requester churns. Same intake, same pipeline, same fate. The only difference is that a bug report usually contains a diagnosable fact (the app crashed here), while a feature request contains one customer's guess at a solution to a problem they never got asked to describe.
Customers noticed a long time ago. In Microsoft's 2016 State of Global Customer Service survey of 5,000 consumers, 48% already said they didn't believe most brands take action on customer feedback. That number is a decade old, and the ritual it describes hasn't changed: the form files their input next to the bugs and never speaks of it again.
Which Form Fields Did You Inherit From Your Bug Tracker?
Every field on the standard feature request form maps one-to-one onto a bug-tracker field, and each mapping smuggles in an assumption that's true for defects and false for product discovery. Walk the form top to bottom and the inheritance is hard to unsee.
| Request form field | Bug-tracker ancestor | The hidden assumption | Why it breaks for feature input |
|---|---|---|---|
| "Feature title" | Bug summary | The requester has correctly named the fix | They've named a fix: theirs, invented alone, in your competitor's vocabulary |
| "Describe the feature" | "Describe the bug" | The problem is fully diagnosed; just implement | You get a spec for a solution, zero information about the problem |
| "Priority" dropdown | Severity field | The requester can rank against a backlog they can't see | Everyone picks High; the field returns a constant, not a signal |
| "Category" picker | Component tag | The customer knows your internal taxonomy | They guess, you re-tag, the data is noise either way |
| "Additional context" (optional) | Steps to reproduce | Context is optional metadata | It's the only field that mattered, and "optional" guarantees it arrives empty |
| Status: "Under review" | Ticket lifecycle | The request's fate is a queue position | The customer wanted a conversation and got a tracking number |
The deepest problem is the second row. "Describe the bug" works because a bug reporter witnessed a fact: I clicked this, it broke. "Describe the feature" asks the customer to have already done your product discovery for you: diagnose their own problem, survey the solution space, and write the winning spec into a text box. Jakob Nielsen, co-founder of Nielsen Norman Group, put the general rule in his first law of usability: "pay attention to what users do, not what they say". The classic request form collects only the saying and structurally excludes the doing.
So the form extracts symptoms. Not because customers are bad at feedback, but because you asked a bug-tracker question and got a bug-tracker answer.
How Did an Internal Jira Template End Up in Front of Your Customers?
The request form looks like a bug tracker because it usually was one: when a team decides to "collect feature requests," the fastest path is to clone whatever intake form already exists, and the form that already exists is the engineering issue template. Nobody redesigns it for external input, because the day it shipped, the goal was to have a form, not to have a good one.
The sequence is almost universal. An early-stage team tracks everything in one issue tracker. Requests from customers get filed there by hand. Eventually someone says "customers should be able to submit these themselves," and the internal template gets a public URL. The fields survive the copy-paste because they look professional: severity dropdowns and category pickers feel rigorous. What actually got copied is a workflow designed for a completely different input: reports about broken known behavior, written by people who share your context, ranked by people who can see the whole queue.
If you copied your feature request form from your Jira template, you're asking customers to file tickets against themselves.
And the ticket framing sets the political dynamics downstream. In the State of Product Management Report 2026 (ProductPlan and Product-Led Alliance), 60.2% of product teams cite leadership escalations as the most common way their prioritization framework gets overridden, while 35.2% cite sales-driven feature requests and 28.3% cite customer escalations as top causes of strategy-roadmap misalignment. That's what a queue of undifferentiated tickets produces: since no ticket carries the evidence to defend itself, the loudest sponsor wins. The form didn't just fail to capture signal. It manufactured the vacuum that escalations rush into.
What Are Customers Actually Trying to Tell You When They File a Request?
Behind every feature request are four pieces of information the customer is trying to transmit: the job they're trying to get done, the workaround they've built in the meantime, the alternative they'll switch to if the pain persists, and what the pain costs their business. The standard form captures none of them, because none of them fit in "describe the feature."
This is the core of Jobs-to-be-Done theory. As the Clayton Christensen Institute frames Christensen's insight: "just as people hire contractors to help them build houses or lawyers to build a case, people 'hire' products or services when 'jobs' arise in their lives", and "people don't simply buy or pick products or services; they pull them into their lives to make progress." Alan Klement, in When Coffee and Kale Compete, sharpens the definition further: "A Job to be Done is the process a consumer goes through whenever she aims to transform her existing life-situation into a preferred one, but cannot because there are constraints that stop her."
Read that against your form. The customer is mid-struggle, blocked from progress by a constraint, and your intake asks them to name a feature. So they translate the struggle into whatever solution vocabulary they have, which is usually a feature they saw somewhere else. The translation destroys the four signals you needed:
- The job: "Every Monday I assemble a revenue summary for our CFO" — the progress being blocked, and the only stable unit your roadmap can actually serve.
- The workaround: "Right now I export three reports and merge them in a spreadsheet, about 90 minutes." Behavioral proof the job is real, plus a free measure of how much it hurts.
- The alternative: "We're trialing a tool that does this natively." The competitive stakes, volunteered, before anyone thought to ask.
- The business impact: "Our board pack goes out late when I'm traveling" — the difference between a nice-to-have and a renewal risk.
Customers want to be understood at this level. In the fifth edition of Salesforce's State of the Connected Customer survey (2022), covering nearly 17,000 buyers, 73% expect companies to understand their unique needs and expectations, and 56% say most companies treat them like numbers. A ticket number in a triage queue is the literal version of being treated like a number.
Why Do Most Feature Requests Point at a Handful of Underlying Jobs?
Because many customers hit the same blocked job but each one names a different solution, request boards concentrate: a large share of submissions turn out to be restatements of a small set of underlying jobs. The ratio is Pareto-shaped in practice. And to be straight with you: nobody has published a rigorous public study proving an exact "80% of requests map to 20% of jobs" split, so treat any precise figure you read (including that one) as a working pattern, not a law.
Here's a composite illustration (not platform data, just the pattern anyone who has run a request board will recognize):
| What four different customers filed | The job underneath |
|---|---|
| "Add CSV export" | Get this week's numbers out of the tool and into the CFO's Monday deck without manual work |
| "Zapier integration please" | Same job |
| "Scheduled email reports" | Same job |
| "API endpoint for pulling metrics" | Same job |
Four tickets, four vote counts, four "Under review" labels — one job. On a symptom-sorted board these compete with each other and all four lose. Mapped to the job, they're a single roadmap item with four accounts of evidence behind it.
What is well documented is what happens when teams ship the symptoms verbatim. The famous version dates to the XP 2002 conference, where the Standish Group's Jim Johnson presented the finding that 45% of features in the studied systems were never used and another 19% rarely were, 64% combined. Quote it carefully: agile author Mike Cohn later chased down the provenance and found it rested on just four internal applications. But when Pendo re-ran the question in its 2019 Feature Adoption Report, across 615 product subscriptions, the answer came back worse: 80% of features are rarely or never used, waste the report sized at up to $29.5 billion a year for publicly traded cloud software companies. Two very different methodologies, two decades apart, same shape: most of what ships from a symptom queue doesn't get used.
Don't take the ratio on faith — run it on your own board. Pull your last 50 requests, ask "what was this person trying to get done?" for each, and count the distinct answers. If you get anywhere near 50 distinct jobs, keep your form; you've somehow attracted the most articulate customer base in SaaS. Most teams get a number closer to ten, which is the moment the feedback-chaos-to-clarity problem stops being abstract.
Why Should You Delete the Customer-Facing Priority Field?
Delete the priority dropdown because it returns a constant. Asking a customer to rate the importance of their own request is asking a rating-scale question with no trade-off attached, and the survey methodology literature has documented for decades what that produces: everything clusters at the top of the scale, and the field stops discriminating between requests at all.
This isn't a cynical read of customers; it's how rating scales behave for everyone. Sawtooth Software, whose research tooling underpins a large share of commercial preference studies, puts it plainly in its methodology documentation: rating data "often feature a lack of discrimination among items and scale use bias", meaning responses pile up at one end of the scale. That failure is the entire reason trade-off methods like MaxDiff exist: they force a choice between items rather than letting a respondent rate everything as important. Your priority dropdown is a one-item rating scale filled out by the one person on earth with the least incentive to pick "Low." The result isn't data. It's a formality that lets your triage view sort a column of identical values.
Severity works internally because an engineer ranks a defect against a visible queue and a shared rubric. A customer can't rank their request against a backlog they've never seen; they can only rank it against their own Monday morning, where it is, correctly, the most important thing.
Priority is your job, and you infer it from evidence the customer can't self-report: how many distinct accounts share the underlying job, how much revenue sits on those accounts, how costly the observed workarounds are, and whether the job blocks activation, retention, or expansion. That's the quantification layer the PM's guide to feedback-driven sprint prioritization builds out in full: "122 users, weighted by $1.4M of MRR" survives a roadmap meeting; a column of self-reported Highs does not.
What Does the Replacement Feature Request Form Look Like?
The replacement form asks four questions, in this order: what were you trying to get done, how are you handling it today, what happens if this never changes, and, last and optional, what solution would you suggest. It deletes the priority dropdown and the category picker entirely. Every field maps to a decision input instead of a queue label. The "After" column below is the feature request template to copy:
| Before (bug-tracker inheritance) | After (job-shaped intake) | What the new field extracts |
|---|---|---|
| "Feature title" | (auto-generated from the answers) | Nothing to extract — titles are your job, not theirs |
| "Describe the feature you'd like" | "What were you trying to get done when you hit this wall? Walk us through it." | The job, in the customer's own words |
| "Priority: Low / Medium / High" | (deleted) | Priority gets inferred from account behavior, shared-job counts, and revenue context |
| "Category" dropdown | (deleted; free text, tagged on your side) | Clean input; your taxonomy stays internal |
| "Additional context (optional)" | "How are you handling this today?" (required) | The workaround: behavioral proof, effort estimate, urgency signal |
| — (no equivalent) | "What happens if this never changes?" | Business impact and switching risk, volunteered instead of extracted on a renewal call |
| "Describe the feature" (again) | "If you have a solution in mind, we'd genuinely like to hear it." (optional, last) | Solution ideas as input, arriving after the problem instead of in place of it |
| Attachments | Attachments — "a screenshot of your current workaround is perfect" | The spreadsheet. It's always a spreadsheet, and it's diagnostic gold |
Three design decisions worth defending:
Workaround before solution. The workaround question is the highest-signal field on the form because it's the only one that asks about behavior rather than opinion: Nielsen's do-versus-say rule, applied to intake design. A customer who has built a 90-minute spreadsheet ritual has already proven the job matters; a customer with no workaround is telling you something equally useful about how much it doesn't.
The solution field survives, demoted. You're not forbidding ideas. Rob Fitzpatrick's rule of thumb in The Mom Test is that ideas and feature requests should be understood, but not obeyed, and understanding requires hearing them. The redesign just stops the solution from being the only thing you collect.
Fewer fields, on purpose. Every field you keep costs you submissions and data quality. The canonical cautionary tale: Expedia found that one optional "Company" field on its booking form was confusing customers into failed transactions, and removing that single field added $12 million a year in profit. Your request form isn't processing payments, but the mechanism is identical: fields that don't serve the person filling the form leak signal at every submission. Four questions that map to decisions beat nine fields that map to a triage view.
How Do You Route Requests Into a Conversation Instead of a Queue?
Treat every submission as the opening message of a short conversation, not a ticket to acknowledge. The operational version is one reply, sent within a couple of days, asking a single follow-up question: usually "can you walk me through the last time this happened?" That one exchange converts a symptom into a diagnosable job and costs about three minutes.
The queue model fails silently because the customer experiences it as a void. They typed a paragraph, received an auto-acknowledgment and a status label, and, per that Microsoft finding above, drew the statistically reasonable conclusion. The conversation model inverts the experience: a human asked a real question about their Monday morning. Even a "we're not building this, here's the workaround we'd suggest" lands better than eight months of "Under review," which is why closing the feedback loop is its own discipline with its own playbook.
Volume is the obvious objection, and it's real past a certain scale: fifty submissions a month can be five conversations a week; five hundred can't. That's where the clustering becomes the bottleneck: mapping incoming requests to the jobs underneath before deciding which conversations to open. This is the layer tools like FeedSense handle, grouping requests by the underlying job rather than the words on top, so "add CSV export" and "Zapier please" stop competing as separate line items. But the practice outranks the tooling: a spreadsheet with a "what were they trying to do?" column beats a beautifully triaged queue of unread symptoms.
How Does Symptom-to-Job Mapping Connect to Your Roadmap?
Symptom-to-job mapping is the roadmap job. A PM's core artifact isn't the ranked list of most-requested features. It's the translation table between what customers filed and what's actually blocking their progress, because roadmap items built at the job level are the only ones that consolidate evidence instead of fragmenting it.
Josh Seiden, co-author of Lean UX and author of Outcomes Over Output, draws the distinction that a symptom-sorted board erases: an outcome is "a change in customer behavior that drives business results". A shipped feature is an output. A customer who stops rebuilding that CFO report by hand is an outcome. A request form that collects features, ranks them by votes, and ships the top of the list is an output machine with a customer-facing UI: the output metric (requests closed) climbs while the outcome (the job, now done inside your product instead of a spreadsheet) goes unmeasured.
The needs-first alternative has a long track record. Tony Ulwick, founder and CEO of Strategyn and creator of Outcome-Driven Innovation, has spent three decades building the discipline of defining customer needs around the job before generating solutions. Strategyn's own tracking of ODI-based client projects reports an 86% success rate against a roughly 17% industry average. That's their number, from their own engagements, so apply the appropriate discount. Still, the direction of the gap matches everything else in this post: teams that start from the job outperform teams that start from the solution list.
Practically, the mapping changes what a roadmap line item looks like. "CSV export (47 votes)" becomes "Get metrics into external reports without manual work: 31 accounts, 4 distinct symptom requests, $610K ARR, 14 documented workarounds." The first is a feature with a fan club. The second is a decision with evidence, and it's the input format that every prioritization framework, RICE and Kano included, silently assumes you already have. Vote counts can't tell you why; jobs with evidence counts can. The deeper analysis layer (turning raw feedback across every channel into exactly these quantified themes) is the territory of our complete guide to feedback analysis.
What's the Honest Caveat? Don't Bug Trackers Work?
Bug trackers work brilliantly — for bugs. Severity fields, repro steps, and triage queues are the right machinery for reports about known behavior that broke, and nothing here argues otherwise. The argument is narrower: that machinery was designed for diagnosed problems, and product discovery is the practice of diagnosing, so running discovery input through a diagnosis-complete pipeline deletes the most valuable part of the signal.
Two more honest limits. First, don't overcorrect into a research questionnaire: a nine-field JTBD interrogation will crater your submission rate for the same reason Expedia's one extra field cratered conversions. Four questions is the ceiling; two ("what were you trying to do?" and "how do you handle it today?") is a defensible floor. Second, a redesigned form fixes intake, not synthesis: if nobody reads the answers, clusters the jobs, and closes the loop, you've built a more eloquent void. The form is the first move in the system, not the system. If you're choosing the tool for the rest of that system, see how a voting board like Canny compares with Productboard.
What's the One-Page Replacement You Can Steal?
Five moves, installable this week, no new budget required:
- Run the 50-request audit. Pull your last 50 submissions, write the job behind each, count the distinct jobs. That number is your case for change, and the evidence base every prioritization framework actually needs before RICE scores mean anything.
- Replace "describe the feature" with "what were you trying to get done, and why?" The single highest-leverage field swap on the form.
- Make the workaround question required. "How are you handling this today?" Behavioral evidence in, opinion theater out.
- Delete the customer-facing priority dropdown. Infer priority from shared-job counts, revenue context, and workaround cost instead; the quantification playbook is here.
- Answer every submission with one question. "Walk me through the last time this happened" turns a ticket into a conversation and a symptom into a job. Then close the loop when you decide.
The form your customers deserve isn't a nicer bug tracker. It's a structured way to say: tell us what you're trying to do, and we'll take it from there. That sentence, not the severity dropdown, is what listening actually looks like in intake design.
Frequently Asked Questions
What is a feature request form?
A feature request form is the structured intake channel a software company gives customers to ask for new functionality: typically a title, description, and category submitted through a portal, widget, or board. Its real job is to capture product signal. Most versions fail at that job because they reuse bug-tracker fields designed for defect triage.
What's wrong with the typical feature request form?
The typical form inherits its fields from an internal bug tracker: a describe-the-feature box (a solution spec), a priority dropdown (always set to High), and an optional context field (usually empty). It extracts the customer's proposed solution instead of their underlying job, workaround, and business impact, which are the three inputs a roadmap decision actually needs.
What fields should a feature request form include?
Four fields cover it: what were you trying to get done when you hit this wall (the job); how are you handling it today (the workaround); what happens if this never changes (the impact); and an optional solution-suggestion field placed last. Drop the customer-facing priority dropdown and category picker; infer both from behavior and account context.
Should customers set the priority of their own feature requests?
No. Survey methodology research shows rating scales suffer from scale-use bias and poor discrimination: responses cluster at the top of the scale, so every request arrives marked High. Priority is your call, inferred from how many accounts share the underlying job, the revenue attached, and what the observed workarounds reveal about urgency.
What is a job-to-be-done in the context of feature requests?
A job-to-be-done is the progress a customer is trying to make when they "hire" your product — the framing developed by Clayton Christensen and the JTBD school. A feature request is one customer's guess at a solution; the job is the blocked progress underneath it. Roadmaps built on jobs consolidate dozens of scattered requests into a few solvable problems.
How do you find the real problem behind a feature request?
Reply with one question: "What were you trying to get done when you reached for this?" Then ask for the current workaround. The workaround is behavioral evidence: it proves the job is real, shows how painful it is, and reveals what the customer already tried. Two asynchronous questions turn a symptom into a diagnosable job.
How many feature requests typically map to the same underlying job?
No public study pins an exact ratio, so treat any precise 80/20 figure as a working pattern. What teams find is Pareto-shaped concentration: a large share of requests cluster around a small set of underlying jobs, because each customer describes the same blocked outcome in their own solution vocabulary. Audit your last 50 requests to get your own ratio.
Do you need a feature request tool, or is a form enough?
Below roughly 50 requests a month, a well-designed form plus disciplined follow-up conversations is enough. Past that, the real work of feature request management becomes clustering: mapping hundreds of symptom-level requests to the jobs underneath, which is where dedicated feedback analysis tooling earns its keep. The form redesign matters at every volume; the tool only starts mattering at scale.
Tags:
Stay in the loop
Get the latest insights on customer feedback, product management, and building better SaaS products. No spam, unsubscribe anytime.
By subscribing, you agree to our privacy policy. We respect your inbox.