Customer Feedback Triage

Customer Feedback Triage

Overview

Most PMs sit on a chaotic inbound stream — Slack DMs, support tickets, sales call notes, CSAT comments, NPS verbatims, in-app feedback widgets, partner emails, exec one-liners — and have no system for converting that stream into prioritization signal. The default mode is reactive: whoever shouts loudest wins, the loudest channels (sales, executives) dominate, and the actual user job stays invisible.

This skill provides a workflow and a Python tool for handling that stream. Inputs are raw feedback items from many channels. Outputs are deduplicated, categorized, scored, and routed items, plus acknowledgment responses for the customers who sent them.

The frameworks behind it are Marty Cagan's separation of request from opportunity from solution, Noriaki Kano's model of feature-quality categories, a layered customer-development model, and an acknowledge/commit/promise request-management discipline. Detail lives in the references below.

Core Capabilities

• Intake & normalization — one verbatim record per ask across 8 channels (support, sales, social, NPS, in-app, exec, partner, interview)
• Dedup & clustering — group items by underlying opportunity even when literal requests differ
• Kano + Cagan classification — Basic/Performance/Delight/Indifferent/Reverse, and Request → Opportunity → Solution
• Segment-aware scoring — kano_weight × log10(volume+1) × segment_weight × (1 + strategic_alignment) as a coarse router (not a final RICE)
• Response discipline — Will-build / Exploring / Won't-build templates; always acknowledge, sometimes commit, rarely promise
• Feed-forward routing — to prioritization, discovery, backlog, bug tracker, or strategy

When to Use

• You have a backlog of customer feedback that is not being processed.
• Sales or Customer Success is constantly forwarding feature requests and expecting a per-request answer.
• An executive is acting as a request channel and the roadmap is drifting accordingly.
• You are setting up a new feedback intake process (post-launch, post-funding, scaling beyond founder-led product).
• You need to respond to a customer who sent a feature request and you have to say "yes", "no", or "exploring" in a defensible way.
• You want a defensible audit trail for "we heard you but said no" decisions.

When not to use

• For genuine product discovery (do not let feedback triage replace discovery — see discovery/interview-synthesis/).
• For prioritizing already-triaged items against each other (that is prioritization-frameworks/).
• For bug triage (use the bug triage process in your tracker — though the workflow here applies to feature-request items).

Clarify First

Before triaging the feedback, confirm these inputs. If any is unknown or vague, ASK — do not assume:

• Feedback items with channel + segment tags — the verbatims and where each came from (drives clustering, volume counts, and the Kano guess)
• Segment weights — which customer segments count more (sets segment_weight in the score, i.e. whether enterprise asks outrank long-tail volume)