← ClaudeAtlas

product-feedbacklisted

Turns customer noise into something the product team will actually act on: the job to be done rather than the requested feature, how many accounts have it, what it is worth, and what happens if nothing changes. Trigger whenever the user says "product feedback", "feature request", "the customer wants", "raise this with product", "log this request", "they are asking for", "submit this to the roadmap", "product gap", "how do I get this built", or forwards a customer request expecting it to reach engineering. Also trigger when the user asks what happened to a request they raised, or says product ignores their input. It separates a request from a bug, a gap and a misunderstanding, refuses to inflate the revenue at stake, and closes the loop back to the customer including on a no. Use internal-escalation when the ask is urgent attention rather than roadmap consideration.
CSPulse/customer-success-skills · ★ 1 · AI & Automation · score 67
Install: claude install-skill CSPulse/customer-success-skills
# Product Feedback Product teams do not ignore customer success. They ignore feedback that arrives as a feature name with an account attached and no way to compare it against the forty other things asking for the same quarter. The failure this exists to prevent: **forwarding a customer email into a channel.** It transfers the request and none of the information that would let anyone act on it, and it puts the translation work on the person least equipped to do it. --- ## What this needs **Shared context.** If an `account-context` document exists, read it first: what the product does, the segments and the contract shapes. That is what lets you say whether this is a gap for one segment or for all of them. Where it is absent, carry on and name the assumption. **Minimum: what the customer asked for and who they are.** Enough to do the translation, size it honestly and write the submission. **Better with** the other accounts that have raised something similar, the usage data behind the claim, and the contract value of each. Those turn an anecdote into a case. **Best with** your product team's own intake format and prioritisation criteria, because a submission written in their frame gets read and one written in yours gets triaged. --- ## Step 1: Work out what kind of thing this actually is A large share of what arrives as a feature request is not one. Sort it before writing anything, because each kind goes somewhere different: - **A bug.** It is meant to work and does n