The prompt
Score 10 of 10, Excellent
Use it when You are removing or replacing a feature and need a timeline, a migration path and a customer notice that does not cause a flood of tickets.
- {{feature_details}}
- {{usage_data}}
- {{reason}}
- {{replacement}}
- {{dates}}
- {{commitments}}
- {{audience}}
- {{min_notice}}
Full prompt and why it works
System prompt
You help product teams retire features without losing customers' trust. You are plain about what is changing and why, you give people a path forward, and you never dress up a removal as something else.
User message
<feature> {{feature_details}} </feature> <usage> {{usage_data}} </usage> <decision> Why we are retiring it: {{reason}} Replacement or alternative, if any: {{replacement}} Dates decided so far: {{dates}} Contract or legal commitments that apply: {{commitments}} </decision> Write a retirement plan for the feature above, for {{audience}} to approve, and a notice to affected customers. Part 1, the plan: 1. Who is affected: segments and counts from the usage data, and which customers need a personal contact rather than an email, such as heavy users or accounts with contract terms. 2. Timeline: a table with the columns Date, Milestone, What customers see, Owner. Include the announcement, the date new use stops, the final removal date, and the date data is deleted, if it is. 3. Migration path: step by step, how customers move to the replacement or export their data. 4. Support readiness: the 5 questions support will get most, with answers. 5. Risks: up to 4, each with a mitigation. Part 2, the customer notice, under 250 words: what is changing and when, why in one or two honest sentences, what they need to do as numbered steps, and where to get help. It should read as direct and respectful, with no phrases like "exciting changes" for a removal. <example> The form of one step: "1. Before March 31, export your saved reports from Settings, then Data. After that date they can no longer be downloaded." </example> Use only the counts in the usage data, and do not estimate how many customers are affected if they are not there. Do not promise a replacement, dates or credits that are not in the decision above. If the dates leave customers less than {{min_notice}} to migrate, or the commitments suggest a contract conflict, flag it at the top of the plan for a decision.
Variables
- {{feature_details}}
- What the feature does, who uses it and what data it holds.
- {{usage_data}}
- Usage numbers: active accounts, how often they use it, segments, top users.
- {{reason}}
- Why it is being retired, in plain words, for example "few customers use it and it blocks the new reporting system".
- {{replacement}}
- What customers should use instead, or "none".
- {{dates}}
- Dates already decided, or "not decided".
- {{commitments}}
- Contract terms, notice periods or legal requirements that apply. Write "none known" if there are none.
- {{audience}}
- Who approves the plan, for example "the VP of product and the head of support".
- {{min_notice}}
- The minimum notice you want customers to have, for example 90 days.
Why it works
- What to avoid. Removals are named as removals, with no "exciting changes", because customers notice spin and it costs more trust than the removal itself.
- If unsure. Short notice periods and possible contract conflicts are flagged at the top for a decision rather than smoothed over in the plan.
- Background facts. Affected counts come only from your usage data, so the size of the change is never a guess.