How to notify the exact customer who asked when their feature ships
"The feature you asked for in March shipped today" is the highest-impact message a product team can send. It tells a customer their input steered the product — Savio's guide to closing the loop covers why this beats any broadcast announcement for retention and for reviving stalled deals.
It almost never gets sent, for a boring reason: by ship time, nobody remembers who asked. The fix is not diligence at ship time; it's bookkeeping at ask time. Four steps.
1. Record the requester when the request arrives
The notification is only possible if every request carries a person and a company from the moment it's captured. When "Acme keeps asking for SSO" lives in a PM's memory or a bare Jira ticket, the loop is already unclosable.
Concretely: when someone writes in #acme-shared-slack "any chance of SAML before our security review?", the tracked request needs their name, their company, and a link to that thread attached — not a paraphrase filed under "auth improvements". Do it manually with a spreadsheet column if you must; the mechanics of pulling requests out of channels are in how to mine feedback from Slack. Voting boards like Canny get you this for free, but only for requests that arrive as board posts — most conversational feedback never does.
2. Keep the request linked to the work item
The second break point: the request is recorded, but the Linear issue or GitHub issue that implements it doesn't reference it. When the issue closes, nothing connects back to Acme.
The rule is one hop: every engineering issue born from customer requests links to the request(s), and transitively to the requesters. Turning conversations into linked, tracked issues is the same plumbing covered in turning feedback into Linear issues.
3. Trigger on the ship event, not on memory
Decide what "shipped" means mechanically — the PR merging, the deploy going out, the issue moving to Done — and make that event produce a task: "SSO shipped; notify these 4 requesters." If the trigger is "someone remembers during launch week," you've rebuilt the failure you started with. Status-triggered notification is how the board tools do it; Gleap, for instance, notifies everyone who upvoted when a request is marked shipped.
This step is where we should disclose: we build Modem, and this exact trigger is its core mechanism. Modem captures requests from Slack, Discord, and support with requesters attached (step 1), links them to issues (step 2), and when the resolving PR merges in a connected repo, matches the merge back and drafts the follow-up to each requester (steps 3 and 4). The matching holds up across channels because everything lands in one context graph — the same person recognized in Slack and email, linked to their company — so nobody gets two follow-ups, or none. If all your requests already arrive as board posts with voters, a board's built-in status notifications cover this and you don't need us.
4. Send it in the channel they asked in, personally
The message that works is short, specific, and lands where the request originated — the Slack thread, the Zendesk ticket, the email chain. Not a generic changelog blast; Enterpret's loop-closing guide and Savio both come down on the personal reply over the broadcast.
A workable shape: "Hi Dana — you asked in March about SAML before your security review. It shipped today; docs here. Anything missing for your setup?" Three sentences: the ask, the ship, a question that reopens the conversation. The last sentence matters — the reply frequently surfaces the next request.
Still publish release notes for everyone else; the requester message complements the broadcast, it doesn't replace it. See how to write release notes people actually read for that half.
What it's worth
Skip the abstract ROI math and count concretely: requests where you could name the requester, and follow-ups actually sent within a week of shipping. Those two numbers expose whether your break is at capture (step 1), linking (step 2), or sending (steps 3–4) — and each has a different fix.
The smallest version this week
Take the last feature you shipped. Search Slack and your support tool for who asked for it — you'll usually find two or three people in ten minutes. Send each the three-sentence message above. Then, going forward, add a "requested by" field to new issues so the search isn't needed next time. That's the whole loop, closed once, this week.
