Unsolicited User Feedback: From Raw Request to Product Decision

A message such as “Please add export to Excel” can enter a support queue and later appear on a roadmap as “Excel export.”

Almost everything needed for a product decision has disappeared.

Who was trying to export? What were they doing next? What failed in the current product? Were similar requests about the same situation? Did anyone imply that the feature would be built?

Unsolicited feedback is valuable because it arrives without a research prompt. It is also incomplete because the person chose the moment, language, and proposed solution.

Treat each submission as an intake event. The operating job is to preserve it, reconstruct the episode, qualify its limits, route it, and return an honest answer.

Make receipt different from agreement

The first response should confirm receipt without borrowing certainty from the user or offering certainty the team does not have.

Useful acknowledgement sounds like this:

Thanks for sending this. I understand that exporting the data matters in your workflow. We have not made a product commitment, but I would like to understand what happened the last time you needed it.

Three statements are doing separate work:

• the message arrived;
• the current interpretation may still be incomplete;
• receipt is not a roadmap commitment.

Avoid “Great idea, we will pass it to the roadmap.” The phrase is friendly, but it creates a debt another team may be expected to repay.

Avoid the colder failure too: an automated thank-you followed by silence. A submission form is not a feedback loop if the contributor cannot tell whether the message was understood, routed, or closed.

Preserve the signal before translating it

Store the user’s original words alongside any internal interpretation. Otherwise, a request can become more definite each time it is copied.

An intake record needs enough provenance to be useful:

• original message and attachments;
• channel and time received;
• product version, plan, device, or configuration when relevant;
• contributor role and relationship to the product;
• account or segment context that the team is allowed to retain;
• internal recipient and current owner;
• consent, privacy, confidentiality, and retention constraints;
• links to the support case, incident, research note, or related record.

Provenance is not permission to collect everything. Keep only the context needed for the stated purpose, restrict access, and follow the organisation’s retention rules.

The UK Information Commissioner’s Office describes purpose limitation for personal information under UK data protection law.

It requires organisations to specify why data is collected and assess compatibility before reusing it for another purpose.

That is UK guidance, not a complete legal rule for every product or country. Even outside that exact context, do not copy identifiable support conversations into a permanent roadmap repository by default.

GOV.UK’s research guidance also limits notes and recordings to the agreed purpose and calls for secure storage. A support message is not automatically a research session, so check which notice, agreement, and lawful basis actually apply.

Reconstruct the most recent episode

The proposed feature is often the least reliable part of a short message. Ask about the last time the problem occurred before discussing a preferred solution.

Use a compact follow-up:

• What were you trying to complete?
• What happened immediately before you needed the export?
• Which information did you need, and who needed it next?
• What did you try in the product?
• What happened instead?
• How did you continue, if you could?
• What consequence did the delay, error, or workaround create?
• Which part of Excel feels necessary: file format, calculation, sharing, audit, or another capability?

GOV.UK’s guidance for in-depth interviews recommends open, neutral follow-ups and stories from real examples rather than general accounts of how work “should” happen.

Its guidance is written for planned government research, not ad hoc commercial feedback. Borrow one technique: a recent episode supplies better context than a prediction about future use.

Do not turn every submission into an interview. A crash report may need reproduction details and an incident route. A clear accessibility barrier may require immediate remediation and specialist review.

Follow up when missing context could change the route, interpretation, or decision.

Separate the request into four layers

Keep the user’s proposed solution, but do not let it stand in for the problem.

Write four separate fields:

1. Intended outcome: what the person was trying to make possible.
2. Recent episode: the situation, sequence, actors, and product state.
3. Failure or constraint: what prevented progress and what followed.
4. Proposed response: what the contributor thinks should change.

For the export request, the outcome may be “give an external auditor a stable record.” The constraint may be that the auditor has no account and cannot access the live view.

Excel is one proposed response. A controlled report, temporary access, an API, or no product change may fit the evidence differently.

This separation also reveals requests that look alike but are not duplicates. Two people asking for “bulk export” may be solving regulatory evidence and offline analysis. One product response may not serve both safely.

The broader customer-centricity evidence standard explains how to compare requests with behavioural, research, service, and commercial evidence.

Qualify what the feedback can establish

One message establishes that one person reported an experience. It does not establish prevalence, market importance, causal mechanism, or the best response.

Label the evidence rather than inflating it:

• reported: the contributor described it;
• observed: someone saw the behaviour or product state;
• reproduced: the team recreated the failure under recorded conditions;
• corroborated: another evidence source supports part of the account;
• inferred: the team supplied an interpretation that remains testable;
• unknown: a decision-relevant detail is missing.

These labels are not a score. They make the next question visible.

The source also has a selection effect. People who submit feedback differ from people who stay silent, abandon the task, contact support through another channel, or never adopt the product.

Do not convert mention count into market size. Counts can help retrieve related records and notice recurrence. They cannot repair an undefined population or prove that the underlying mechanism is the same.

Use the nine decision-focused discovery questions when a cluster deserves deliberate investigation beyond a short follow-up.

Route by the action required

Feedback should not share one undifferentiated product backlog. Route it according to the work and authority it requires.

Incident, safety, security, or rights concern

Use the organisation’s urgent escalation path. Do not wait for theme review or popularity.

Defect or reliability failure

Capture environment, expected behaviour, actual behaviour, consequence, and reproduction evidence. Engineering or support may need to act before product discovery begins.

Support, documentation, or enablement gap

The product may work as intended while its path, explanation, or operating guidance fails. Route immediate help and retain the signal about product friction.

Account-specific service or configuration

An account may need migration, permissions, policy, or expert work that is valuable but not a reusable product capability.

Product opportunity

The episode may expose an unmet outcome for a relevant group. Attach it to an explicit discovery question, not a promised solution.

Positioning or fit problem

The product may have been sold or understood for a result it cannot responsibly provide. That needs a proposition or commercial decision, not another feature vote.

The same submission can create more than one route. A support owner may recover the user today while product investigates a recurring capability gap.

Deduplicate by mechanism, not wording

Text similarity is a poor definition of duplicate feedback.

Merge records only when the actor, intended outcome, failure mechanism, and relevant conditions are materially the same. Keep each source attached to the primary cluster so its differences remain available.

GitLab publishes a customer-feedback process that distinguishes new, accepted, and declined requests. It also records a primary issue while preserving references and labels from merged duplicates.

Its process belongs to a particular GitLab product area and operating model. It is useful as an example of explicit states and traceable consolidation, not a template every team should copy.

GitLab’s broader issue-triage handbook also separates support questions, product feedback, and duplicates, and warns maintainers against forward-looking milestone statements.

Public open-source issue management differs from private customer feedback. What matters here is visible routing and consolidation, which prevents the report from changing meaning in silence.

Attach feedback to a decision, not a roadmap item

A cluster becomes decision-ready when it can answer:

• which actor and outcome are in scope;
• which episodes show the same mechanism;
• which sources disagree or remain absent;
• what consequence and strategic relevance are credible;
• what the evidence does not establish;
• which decision is open now;
• who owns that decision;
• what evidence or event will trigger review.

The possible decision may be to recover an account, fix a defect, change guidance, run discovery, change positioning, defer, or decline.

If the answer is a product investment, it still enters prioritisation with other work. The feedback explains the opportunity; it does not reserve capacity.

The prioritisation guide shows how to compare investments without turning a score or request count into the decision.

Close the loop without promise debt

Use states that describe what the organisation has actually decided:

• received;
• needs context;
• routed to support, incident response, or another owner;
• under investigation;
• no product change planned, with a shareable reason;
• candidate for discovery;
• committed within a stated scope;
• released and awaiting outcome evidence;
• closed because it is resolved, obsolete, or cannot be pursued.

“Under consideration” should not survive indefinitely. Give it an owner and review trigger, or close it honestly.

Match the reply to the state. A contributor may need immediate recovery, an explanation, a link to the primary record, or a clear decline. They do not need internal ceremony presented as progress.

Do not reveal another customer’s identity, confidential evidence, security detail, or commercial negotiation to explain a decision.

When work ships, return to the episode. “We released export” closes delivery. “The auditor received a stable, authorised record” begins to test whether the outcome improved.

A fictional feedback path

Consider a fictional scheduling product. A studio coordinator submits: “Please let us colour-code every session type.”

The team preserves the message, subscription tier, role, and current configuration. A follow-up reconstructs the last episode.

During a busy shift, staff assigned a recording session to a room without the required equipment. The coordinator uses colours on a paper schedule to identify equipment needs at a glance.

The request is split into an outcome, episode, constraint, and proposal. The outcome is compatible room assignment. The constraint is that equipment needs are invisible during scheduling. Colour is the proposed response.

Another colour request concerns personal calendar preferences. It is not merged into the same cluster because the actor, consequence, and mechanism differ.

Support provides a temporary configuration guide. Product investigates how equipment compatibility should be represented and validated.

The reply acknowledges the immediate workaround and the investigation. It does not promise colour-coding.

This example is invented. It demonstrates the path and makes no claim about prevalence or business results.

The minimum useful feedback record

For each submission, keep:

1. Receipt: original words, source, time, owner, and permitted use.
2. Context: actor, product state, relevant account or segment, and recent episode.
3. Interpretation: outcome, constraint, consequence, and proposed response.
4. Evidence status: reported, observed, reproduced, corroborated, inferred, and unknown.
5. Route: immediate action, responsible owner, and linked records.
6. Cluster: shared mechanism, differences, and primary record.
7. Decision: open question, current state, rationale, and review trigger.
8. Reply: what the contributor was told and what was not promised.
9. Outcome: what happened after recovery, closure, or release.

Good feedback operations preserve the user’s reality without pretending that every message is research or every request deserves a feature.

Listening becomes useful when the organisation can show what it understood, what it decided, and what it still does not know.

Sources

• Using in-depth interviews: GOV.UK Service Manual
• Taking notes and recording user research sessions: GOV.UK Service Manual
• Purpose limitation: UK Information Commissioner’s Office
• DAP Customer Feedback Framework: GitLab Handbook
• Issue Triage: GitLab Handbook

Read next

Practical Customer-Centricity for Product Teams places individual feedback inside a broader evidence standard for product decisions.

How to Prioritise Product Work Without Hiding the Trade-offs helps once a qualified feedback cluster competes for investment.