Product feedback

# Product feedback

## Goal

Turn customer, prospect, support, usage, current-product, and bounded observational evidence into product input the engineering team can use without letting the loudest account, the latest lost deal, public-web volume, or an unevidenced segment drive the roadmap.

Feedback is evidence about jobs, friction, and missing outcomes. It is not a voting system and not a promise.

This is synthesis. Do not change product code. Do not tell customers a feature is coming.

Complete the analysis autonomously. Do not stop to ask clarifying questions. When evidence is thin, keep the backlog short and the unknowns visible.

## Prerequisites

Read the implemented product and, when present, the latest ICP (GREEN / YELLOW / RED), positioning, pricing, onboarding, retention, support, usage, interview, pilot, win/loss, and issue records; existing roadmap or decision logs; and any existing `docs/gtm/feedback.md`, `docs/gtm/feedback.yaml`, and `docs/gtm/feedback-changelog.md`.

Also inspect, when present, the no-contact intelligence handoff in `docs/product-intelligence/opportunity-ranking.md` and `.yaml`, plus its cited `problem-patterns.*` and `evidence-ledger.*` artifacts. Consume an observational handoff only from `NOMINATE` or `NOMINATE NARROWLY` and inherit the exact nomination and evidence ceiling. An observational `HOLD` or `REFUSE` forces `HOLD` here unless independent first-party product or customer evidence supports a separate bounded input. Do not reopen public sources or extend collection inside this synthesis prompt.

GTM artifacts and segment colors strengthen the analysis but are not prerequisites. If they are absent, use the working product, authorized customer or support evidence, and current job boundary; keep ICP and segment color `UNKNOWN`. Do not invent GREEN status or create missing GTM artifacts as a side effect.

The implemented product and the beachhead job are the reference. Requests that would create a different product are adjacent bets, not default work.

## Evidence standard

Label every material claim with exactly one shared evidence label:

* `OBSERVED`: directly present in an identified product behavior, authorized record, event, measurement, or dated statement
* `DERIVED`: calculated or logically synthesized from cited observations; show the inputs and method
* `ASSUMED`: a narrow, falsifiable working premise used because direct evidence is insufficient
* `UNKNOWN`: missing, contradictory, stale, inaccessible, unauthorized, or too weak to support a conclusion

A feature request proves someone asked. It does not prove the job is frequent, costly, or on-ICP. A lost deal proves a deal was lost, not that the missing feature would have won it. Usage absence can mean the feature is unused, undiscoverable, or unnecessary. A public post proves the statement was published, not that the underlying claim is true or representative. Search rank and repetition do not prove prevalence. Official competitor material proves a claim or documented behavior, not customer value.

Keep `source_kind` separate from the evidence label: `owned_behavior`, `customer_record`, `public_behavior`, `public_statement`, `official_claim`, or `synthetic`. Synthetic scenarios, personas, objections, quotes, and outcomes are always `ASSUMED`; they may expose questions or edge cases but may never increase frequency, source count, confidence, demand, or priority.

When reliable GREEN / YELLOW / RED segmentation exists, weight in descending order:

1. repeated behavior on GREEN accounts (paid, activated, retained)
2. failed attempts and workarounds on GREEN accounts
3. delivery cost and support burden created by the gap
4. lost GREEN deals where the gap was the named reason
5. YELLOW experiments
6. opinions, surveys, competitor checklists, RED requests

When segmentation does not exist, do not simulate it. Weight authorized first-party product behavior and outcomes above bounded independent public behaviors and workarounds; weight those above public statements, search surfaces, official claims, request volume, stakeholder rank, survey scores, and competitor checklists. Synthetic material never contributes evidence weight. Keep affected-segment fit `UNKNOWN` until the evidence supports it.

## Step 1: Collect and tag

Build a ledger of atomic feedback items. One request, one row.

Tag each with: stable ID, source and inherited observation IDs, date, deidentified account, cohort, or bounded public sample, segment color or `UNKNOWN`, role, job, current workaround, frequency within its defined sample, economic consequence, whether it blocked activation, value, renewal, or close, evidence label, source kind, directness, independence, and limitation.

Do not drop negative or inconvenient items.

De-identify if the repository is public or visibility is unclear.

## Step 2: Cluster by job, not by UI

Group items into job-level themes: a failed outcome, a risky handoff, a missing input, a broken time-to-value step.

Refuse clusters that are only “make it easier” or “add integrations” without a job.

For each theme:

* who feels it
* GREEN / YELLOW / RED mix when evidenced, otherwise the explicit segment unknown
* what they do today
* what would change if it were fixed
* product surface implicated
* whether it is a defect, a missing beachhead capability, or a new product

## Step 3: Recommend without capturing the roadmap

For each theme recommend one of:

* `FIX NOW`: evidenced defect or broken current-product path
* `SHAPE`: real job, needs a tighter problem statement
* `HOLD`: insufficient evidence
* `REFUSE`: off-ICP, uneconomic, or would distort the product
* `EXPERIMENT`: time-boxed YELLOW test with a kill criterion

A `FIX NOW` must name the customer outcome and the smallest change boundary, not a solution architecture. It is product input, not implementation authorization.

Engineering still decides implementation. This prompt supplies the commercial and customer case, constraints, and what not to build.

## Step 4: Close the loop design

Specify how decisions are recorded and, when appropriate and separately authorized, how affected customers could hear that a request was refused or completed. Do not contact anyone, draft a promise, or design a public changelog as a substitute for the decision log.

## Step 5: Desk-test

1. Evidence quality and current-product relevance outrank request volume; when valid segmentation exists, GREEN evidence outranks RED volume.
2. Lost-deal features are not automatic work.
3. Each `FIX NOW` serves the current product job, not a tour of competitor pages.
4. Refusals are explicit.
5. No theme silently rewrites the ICP.
6. Public observations remain bounded to their sample, and synthetic challenges add no evidence weight.

## Decision

* `PUBLISH INPUT`: the ledger and recommendations may go to product
* `PUBLISH NARROWLY`: defects and activation blockers only
* `HOLD`
* `REVISIT ICP` if the strongest themes imply a different customer

Lead with:

“As of [date], product input for [current product job] contains [N] themes: [N] fix now, [N] shape, [N] refuse, at evidence ceiling [ICP version or product-evidence boundary], decision [PUBLISH INPUT / PUBLISH NARROWLY / HOLD / REVISIT ICP].”

## Deliverables

### 1. `docs/gtm/feedback.md`

Method, ledger summary, themes, recommendations, refusals, desk tests, questions for product.

### 2. `docs/gtm/feedback.yaml`

`version`, `status`, `decision`, `items`, `themes`, `recommendations`, `refusals`, `weighting_rules`, `assumptions`, `unknowns`, `sources`.

### 3. `docs/gtm/feedback-changelog.md`

Append only.

If item volume is high, also write `docs/gtm/feedback-ledger.csv` with one row per item and stable IDs.

## Boundaries

* Do not modify application code or promise dates.
* Do not contact customers, prospects, teammates, or third parties.
* Do not invent quotes or frequency.
* Do not reopen public research, extend a registered sample, or treat search visibility as demand.
* Do not let synthetic material increase evidence strength, counts, or priority.
* Do not let one large prospect redefine the product.
* Do not treat survey scores as a roadmap.
* Do not hide refusals.
* Preserve uncertainty.

## Done when

* Items are tagged by job and by evidenced segment color or explicit `UNKNOWN`.
* Recommendations use the five classes above.
* Desk tests passed or forced `HOLD`.
* The files agree and can be handed to engineering without translation theater.