Customer Feedback

Origin & evolution

The systematic capture of customer feedback grew out of the quality movement. The phrase "Voice of the Customer" was coined by Abbie Griffin and John Hauser in their 1993 Marketing Science paper The Voice of the Customer, which treated customer statements as structured input to product development, with the rigour of any other engineering data. The method built a hierarchy of customer needs🫀NeedUserA user need, pain, desire, or constraintView reference → from verbatim language, and it established a principle that still holds: customers describe problems and experiences reliably, and they describe solutions🔧SolutionDiscoveryA proposed approach to address an opportunityView reference → poorly.

The channels multiplied as the discipline matured. Practitioners now divide feedback into solicited and unsolicited. Solicited feedback is what you go and ask for, through surveys, interviews, and tools like Net Promoter Score, and it is targeted and easier to quantify. Unsolicited feedback is what customers volunteer without prompting, through support tickets🆘Support TicketCustomer SuccessCustomer support request or issueView reference →, reviews, and social posts🐦Social PostMarketingA social media postView reference →, and it captures the issues you did not know to ask about. CX Network frames the trade as depth versus breadth: solicited feedback goes deep on what you chose to probe, unsolicited feedback spreads wide across what actually bothers people.

The current consensus is that neither type is a roadmap on its own. Mature programmes pipe both into one place, join them to usage and account data, and treat the merged stream as raw material for analysis. Qualtrics and most modern Voice of the Customer practice describe this as a pipeline: collect, unify, theme🎨ThemeProduct SpecificationA strategic grouping of related featuresView reference →, and only then prioritise. The discipline lives in the steps between hearing and shipping.

How it works in practice

A project-management product collects 1,400 pieces of feedback in a month: 600 from in-app surveys, 500 from support tickets, and 300 from app-store reviews. A naive count puts "dark mode" on top with 180 mentions, and a request-counting roadmap ships it.

The team instead runs the pipeline. Each piece of feedback becomes an observation👁️ObservationUser ResearchA specific behaviour or statement observedView reference →, a single tagged data point. Clustering the observations surfaces a pattern the raw count missed: 240 items across all three channels describe the same struggle, losing track of which tasks☑️TaskProduct SpecificationA unit of work within a story or epicView reference → belong to which client, expressed in a dozen different words and never once as a feature⭐FeatureProduct SpecificationA product capability or featureView reference → name. That cluster becomes an insight🔦InsightUser ResearchA synthesised finding from researchView reference →, a synthesised claim about a real problem. Dark mode is a preference; the client-tracking confusion is a job🔨JobUserJob To Be Done: what the user is trying to accomplishView reference → the product is failing at. The insight earns a roadmap slot; the dark-mode requests become a logged feature request🙏Feature RequestCustomer FeedbackA user-submitted feature requestView reference →, real but lower-value. The same 1,400 inputs produced a different and better decision⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference → because the pipeline sat between them and the roadmap.

Customer feedback vs. its neighbours

• Observation is a single piece of feedback tagged and stored, one data point. Customer feedback is the broader stream those observations are drawn from. An observation is atomic and traceable; feedback is the flow.
• Insight is the synthesised pattern across many observations, a claim you can defend. Feedback is the raw material; an insight is what survives clustering and interpretation. Counting feedback gives you volume; synthesising it gives you direction.
• Feature request is a specific ask for a specific solution, often customer-authored. Feedback is wider and frequently describes a problem with no solution attached. A feature request is one shape feedback can take, and the most dangerous to act on literally, because it names a fix without proving the underlying need.

In the graph

In the Unified Product Graph, customer_feedback🔶Customer FeedbackCustomer SuccessVoice-of-customer input sits in the Customer Success region as the entry point for qualitative signal. The inbound product_listens_via_customer_feedbackProductlistens viaCustomer Feedbackhierarchy ties it to the product it informs. The outbound edges trace the pipeline that turns it useful: customer_feedback_creates_observationCustomer FeedbackcreatesObservationcross-domain breaks the stream into atomic data points, customer_feedback_becomes_feature_requestCustomer FeedbackbecomesFeature Requestcross-domain records the ask-shaped subset, and customer_feedback_reveals_churn_reasonCustomer FeedbackrevealsChurn Reasonhierarchy captures the feedback that arrives at the exit. The cross-domain service_blueprint_contains_customer_feedbackService BlueprintcontainsCustomer Feedbackhierarchy places it back in the service context it came from. That structure enforces the lesson of the field, because feedback that creates no observation and reveals nothing is volume with no signal extracted, visibly orphaned in the graph.