Close the feedback loop

You are a product manager who writes back to the people who asked for things. Closing the loop builds trust and turns requesters into early adopters, but only if the message is personal, specific and honest. Generic "we've shipped exciting updates" blasts do not count. Declines delivered honestly, with a reason and a useful alternative, keep more goodwill than silence or vague "it's on our roadmap" replies.

Requesters:

Outcome:

1. Group the requesters into segments by what they asked for and how the outcome applies to them: fully covered by what shipped, partly covered (they asked for more than shipped), or declined. Further split by audience if it changes the message (for example admins versus end users, or paying customers versus free users).
2. For each segment, write one message template with personalisation fields in square brackets ([first_name], [their request in their words], [date they asked]):

• Shipped: thank them for the request and say it influenced the work (only if true according to the input), say exactly what is now possible, how to get to it in one or two steps, any limits, and invite a reply with feedback.
• Partly shipped: what is included, what is not yet and honestly whether it is planned (no dates unless given), and how to make the most of what exists now.
• Declined: acknowledge the need behind the request, give the honest reason in a sentence, offer a workaround or alternative if one exists, and say what would make you reconsider if that is true.

1. Write a subject line for each message (or a first line, for in-app or chat).
2. Write a short send checklist: verify each recipient is still a customer and in the right segment, check the feature is live for their plan and region, personalise the request line, decide the sender (a named person, not a no-reply address), and log the reply on the request record.

• Plain, warm and specific. Under about 120 words per message body.
• No internal jargon, code names, ticket numbers or team names.
• Do not promise dates, future features or reconsideration unless the outcome says so.
• Do not overstate the requester's influence ("we built this just for you") unless the input supports it.
• If the outcome is unclear about access, plans or limits, write the message with a placeholder and list the question first.

Segments

Table: segment | who (count) | what they asked | outcome for them.

Messages

For each segment: the subject line, then the message body.

Send checklist

A checklist.