customer-feedback-triage

What this skill does

# 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 discovery-techniques separation of *request* from *opportunity* from *solution*, Noriaki Kano's model of feature-quality categories, Reforge's customer-development model, and ProductPlan's request-management playbook.

### 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).

## Frameworks

### Marty Cagan: Request → Opportunity → Solution

Cagan separates three things customers and the inbound stream conflate:

| Layer | What it is | Example |
|---|---|---|
| **Request** | What the customer literally asked for | "Add an export to PDF button" |
| **Opportunity** | The underlying job or problem | "I need to share results with my CFO who doesn't have a login" |
| **Solution** | The chosen response | "Shareable read-only link" or "PDF export" or "CSV + email digest" |

The triage workflow's job is to convert each Request into an Opportunity and route the Opportunity to the appropriate discovery / prioritization process. The literal Request is rarely the right thing to build.

### Kano Model (Noriaki Kano, 1984)

Kano classifies features by how their presence or absence affects customer satisfaction. The five categories:

| Category | Effect of having it | Effect of missing it | Example (SaaS analytics tool) |
|---|---|---|---|
| **Basic / Must-be** | Expected; satisfaction does not increase | Severe dissatisfaction | Login works; data export exists |
| **Performance / One-dimensional** | More is linearly better | Less is linearly worse | Query speed; dashboard load time |
| **Delight / Attractive** | Disproportionate satisfaction | Customer does not miss it | Natural-language query; collaborative cursors |
| **Indifferent** | No effect | No effect | Theme color picker (for most users) |
| **Reverse** | Causes dissatisfaction | Improves satisfaction | An overly chatty AI assistant |

Kano categories shift over time: today's delighter becomes tomorrow's basic. The categorization in this triage workflow is the team's current snapshot.

### Reforge: Layered customer development

Reforge frames customer development as concentric rings: stated needs → revealed jobs → underlying motivations. The triage workflow operates at the first ring (stated needs, captured in the request text). It explicitly routes high-signal items into deeper discovery work to surface the second and third rings.

### ProductPlan: Request management

Three principles, drawn from ProductPlan's request-management practice and adopted here:

1. **Always acknowledge.** Every request, even ones that get a "no", gets a response. Customer silence is the fastest path to lost trust.
2. **Sometimes commit.** Commit only when the item is scored, prioritized, and on the roadmap with a date the team will actually hit.
3. **Rarely promise.** Avoid "we'll definitely build that" in any external channel until the item is funded, scoped, and started.

## Workflow

### Phase 1: Intake & normalization

For every inbound feedback item, capture a normalized record with these fields:

| Field | Required | Notes |
|---|---|---|
| `id` | yes | Internal ID |
| `channel` | yes | One of: support, sales, social, nps, in_app, exec_ask, partner, customer_interview |
| `customer_id` | yes | Anonymous OK; needed for dedup and segment analysis |
| `segment` | recommended | e.g. SMB, mid-market, enterprise, prosumer |
| `raw_text` | yes | The verbatim ask — do not paraphrase at intake |
| `received_at` | yes | ISO-8601 |
| `submitter` | yes | The internal person who logged it (Support agent, AE, PM) |
| `opportunity_area` | optional | Coarse area, populated at triage (e.g. onboarding, reporting, integrations) |

Normalization rules:

- Capture the verbatim. Paraphrasing at intake loses signal. The PM can paraphrase at triage.
- One request per record. If a customer email contains 3 asks, create 3 records.
- Do not pre-judge at intake. Even off-topic items get logged and triaged later (they are signal about channel hygiene).

### Phase 2: Triage (run `feedback_triage.py`)

The Python tool ingests the normalized intake JSON and produces:

1. **Deduplicated clusters** — items grouped by similar opportunity, even if the literal requests differ.
2. **Kano category guess** — heuristic based on keyword signals (transparent and documented; the PM should override).
3. **Categorization** — Bug / Feature / Question / Strategy.
4. **Priority score** — combined Kano weight × volume × segment × strategic-alignment.
5. **Suggested response template** — Will-build / Won't-build / Exploring, parameterized by request and customer name.

### Phase 3: Categorization

For each clustered item, categorize:

| Category | Definition | Action |
|---|---|---|
| **Bug** | Existing functionality is broken | Route to engineering bug queue, not PM backlog |
| **Feature request** | New functionality | Continue to scoring |
| **Question** | Customer needs help, not a product change | Route to support / docs; flag if recurring (it's a doc gap) |
| **Strategy** | Item implies a strategic direction (new market, new pricing model) | Route to leadership, not the backlog |

### Phase 4: Scoring

Each Feature request gets three scores:

| Dimension | Range | Source |
|---|---|---|
| **Kano category** | basic / performance / delight / indifferent / reverse | Heuristic + PM override |
| **Volume** | count of customer requests | Tool aggregates after dedup |
| **Segment weight** | enterprise=4, mid-market=2, SMB=1 (configurable) | From customer record |
| **Strategic alignment** | 0-2 | Manual; does it advance current strategic theme? |

The composite priority is:

```
priority = (kano_weight × log10(volume + 1) × max_segment_weight × (1 + strategic_alignment))
```

Where Kano weights default to:
- Basic = 4 (gaps here are existential)
- Performance = 2
- Delight = 3
- Indifferent = 0
- Reverse = -3 (negative — actively avoid building)

This is a coarse score for triage routing, not a final RICE/ICE. Items above a threshold get routed to `prioritization-frameworks/` for proper scoring.

### Phase 5: Response

Every customer who submitted a request gets a response, even for "won't build". Three response templates (in `assets/response_templates.md`):

| Template | When | Tone |
|---|---|---|
| **Will-build** | Item is scored, prioritized, on roadmap with date | Specific, dated, conservative |
| **Exploring** | Item is interesting, not yet s