A public feature request shows that someone cares about a workflow, but it does not prove that they are evaluating a product or inviting a sales response. The same sentence can belong to product research, retention risk, future demand, or an active purchase depending on who owns the decision, what alternatives are visible, and whether a next step is underway. The representative scenarios below make that boundary explicit.
Requested capability and purchase motion are different axes
A highly specific request can still come from a student, existing user, consultant, or curious observer with no authority or intent to buy.
Movement creates the stronger signal
Comparing options, replacing a workaround, preparing a shortlist, or naming a deadline provides more buying evidence than enthusiasm about a feature alone.
Existing-customer requests need a different route
A current user's missing feature may signal retention risk or roadmap input. Sending it to acquisition without account context can produce a confusing response.
A useful classifier can return neither
Some posts are hypothetical discussion, support questions, or category education. Do not force every mention into product feedback or sales intent.
Classify the job before assigning the owner
Use the visible decision state, not the presence of a feature noun, to choose the next action.
| Focus | Primary evidence | Default route | Recommendation |
|---|---|---|---|
| Product feedback | A user describes a missing capability, failed workflow, or desired improvement with no active evaluation. | Product research or customer success, with the workflow and impact preserved. | Do not label it a new-business lead without separate buying evidence. |
| Evaluation criterion | A buyer says a capability will determine which option enters or leaves the shortlist. | Buying-intent review and product-fit assessment. | Record the capability as a criterion and confirm the buyer, timing, and invitation state. |
| Active buying motion | The conversation includes alternatives, a current workaround, decision timing, and an owned next step. | A qualified reply or research queue depending on fit and permission. | Respond to the decision, not by promising an unverified roadmap item. |
| Support or hypothetical discussion | The author asks whether something is possible or debates an idea without a concrete workflow decision. | Support, education, or no action. | Keep the classification provisional when ownership and consequence are missing. |
Representative: an existing user asks for export controls
The post describes a repeated operational blocker but contains no alternative search or purchase decision.
Why it matters: Route it as product feedback and possible retention context, not as a net-new buying opportunity.
Representative: a buyer makes the feature a shortlist gate
The author is comparing three tools and says source-level approval controls are required before a trial can proceed.
Why it matters: The feature is now an evaluation criterion inside visible buying motion. Confirm product fit before replying.
Representative: a category discussion asks what would be useful
Participants propose features for an imaginary product but nobody owns an implementation or purchasing decision.
Why it matters: Treat the discussion as exploratory research and avoid assigning false urgency.
Score movement separately from pain
Keep workflow severity, decision ownership, alternative search, timing, and next step in separate fields. Strong pain without movement is not the same as active buying intent.
Check the relationship before routing
Determine whether the author is a current user, former user, evaluator, practitioner, or observer before assigning a product, success, or acquisition action.
Never promise the roadmap to win the thread
If a requested capability is absent or uncertain, state the current fit honestly. A public promise made for acquisition can create product and trust debt.
Keep product feedback useful without turning every feature request into a sales lead.
ReplyRadar groups public pain, feature requests, recommendation asks, complaints, and buying motion so a founder can choose the right next action.
Is every public feature request a buying signal?
No. It becomes stronger buying evidence when the author owns a decision, compares alternatives, names timing or constraints, and shows a concrete next step.
Can a feature request still be valuable without buying intent?
Yes. It may reveal workflow pain, roadmap input, retention risk, support needs, or language worth testing in research even when no acquisition action belongs.