Using feedback to decide when to sunset a product

Signals that a product is fading

A product that is fading rarely announces it. The signals show up in the feedback first. Watch for falling volume over several months, a growing count of questions about features the product no longer has, bugs nobody can reproduce because the environment changed after a release, and customers who say they are moving to another tool.

Look at the mix as well as the total. A product that gets fewer messages but more bugs is in trouble. A product that gets fewer messages with calm ideas and occasional praise may simply be stable and small. Those two cases need very different decisions.

A quiet inbox is not proof

Low volume alone does not justify a sunset. Some products are quiet because they work. Happy customers rarely write in, and a small tool used every day by a few people can be worth keeping. Before you decide, read the text. Are people still asking for new things? Are they still reporting bugs they care about? Are they writing from pages you still maintain?

Use the mix of signals to answer one question: will the next six months of work on this product help the people who still use it? If the answer is no, you have a sunset case. If the answer is only maybe, keep the product and give it a small, fixed weekly slot instead of a full-time effort.

Write the decision down with dates

Write the sunset decision in your notes app with four facts: the signals you used, the date you will announce it, the date the product stops accepting feedback and the reason. Keep the reason honest. "Not enough time to maintain it alongside the other products" is a valid reason. You do not need to justify the decision to customers in detail, but you do need to be clear about the timeline.

Tell customers early and in writing

Tell the people who use the product early enough that they can move. A notice a few weeks ahead is kinder than a surprise, and it gives them time to export their own data or switch. If people depend on a particular data format or integration, name the export format in the notice so they can plan the move. Reply to each person who wrote about the product, from your own email, with the closing date, the reason in one or two sentences and a recommended alternative if you have one.

A short notice on the product's website or hosted feedback page helps too, but it reaches only the people who visit. Email the people who wrote in, because they are the ones who told you they use the product.

Collect exit feedback in the product

Before the product closes, ask the people still using it what would make them leave or what they would need to stay. The widget can do this with one button. Add it to the sign-in area or the settings page of the product. The widget script must be on that page for the button to work, and the data-escuta-open value sets the type so the form opens already on the right choice:

<button type="button" data-escuta-open="other">Tell us what would make you stay</button>

Exit feedback is most useful when it is specific. Ask one question, such as "What would you need to keep using this?", and read every answer in your weekly slot. Some answers will point to a replacement you can recommend. Others will show a feature the product never delivered, which is useful to know before you write the final notice.

Export before you delete

Before you delete anything, export the product's feedback as CSV. The file holds every item with its status, type, rating and metadata. That record is what you need for a contract, a dispute or your own archive, and it is easy to lose once the product is gone. Open the file and check that its row count matches the dashboard total before you delete anything, so you know the export is complete.

Then delete the product from its settings and remove the widget snippet from every site that used it. Store the export and your notes together in a folder you can find in a year. Check that the folder is private, because the export contains names and email addresses.

When should you not sunset?

Do not sunset a product that still has a small group of loyal users who depend on it, unless you can give them a clear replacement. Do not sunset it because the feedback is uncomfortable, either. Negative feedback that describes a fixable problem is a reason to fix it, not to close the product. Sunset when the cost of keeping the product going is clearly higher than what it returns to the people using it.

How to run a sunset with Escuta Produto

Use the product's inbox to read every item from the last six months with the status and type filters, and export the CSV before you change anything. Put the exit question on the widget button, write the notice, and reply to each person from your own email. The widget docs show the options for the button and the trigger, and the hosted page docs cover the link you can share with people who still need to write in. For the routine that makes these calls possible, read using feedback to choose which product to work on. Your weekly slots, described in a feedback routine for five products, are where the exit feedback gets read.