How to collect feedback before deprecating a feature

Why removing a feature needs its own feedback step

A deprecation is a decision made on behalf of people who use the feature. Some of them use it every day and will feel the loss immediately. Others use it once a quarter and will only notice when they need it. The team usually knows the first group and guesses about the second. Feedback before the removal date is the cheapest way to replace guesses with names, workflows and deadlines.

The goal is not to ask permission. You may still remove the feature. The goal is to learn who depends on it, what they do with it, and whether there is a simpler path you can offer before the change ships. A removal that surprises people costs more trust than a removal that was discussed in advance.

When should you announce the deprecation?

Announce early enough that people can respond, and late enough that the plan is real. For most features, that means four to eight weeks before removal, with a clear date. An announcement with no date invites people to assume nothing will happen. An announcement with a date two days away feels like an ambush.

Put the announcement in the place people already look: the feature itself, the changelog, and the email or in-app message your team already sends. Escuta Produto does not send emails to customers for you, so the announcement is written and sent from your own system or address.

How do you put a feedback entry point on the feature?

Place a feedback button next to the feature, with a label that names it. The button should say what is changing, not just "Feedback". Use the data-escuta-open attribute with the idea type, since the most useful answers describe a missing alternative.

<p>The old CSV import is being retired on 2026-12-01.</p>
<button data-escuta-open="idea">Tell us how you use the old import</button>

When the feature is rendered, set metadata that names it, so every report about it is easy to find later. The feature key should be a stable internal name, not the label in the interface, because labels change more often than keys.

window.EscutaProduto.setMetadata({
  feature: "legacy-csv-import",
  deprecationDate: "2026-12-01",
});

If the feature is used in many places, add the metadata on the screen where the feature lives, not on the whole app. A report from the settings page then tells you something different from a report from the import screen itself.

How do you find the users who depend on the feature?

Start with your own usage data. Your app logs which users triggered the feature in the last ninety days, or it can log them from now on. That list is the most complete source of who depends on the feature, and it does not depend on anyone choosing to write to you. Pair it with the reports that come through the widget, because a report often shows how the feature is used in practice.

Escuta Produto does not segment users by behavior, and it has no tags. Use the feature metadata to find the reports, then read each one and add an internal note with the workflow the person described. Export the inbox to CSV when you need the list in a spreadsheet, then filter the rows yourself by the feature name in the message text.

1. Pull the list of accounts that used the feature in the last ninety days from your own data.
2. Read every widget report that carries the feature metadata, and note the workflow described.
3. Match the two lists by account id, and sort the accounts by how heavily they used the feature.
4. Write down the workflow each heavy user needs, in one line each.
5. Decide which workflows can move to an alternative, and which need a longer transition.

What should the reports and the list change?

If the reports describe a workflow that the replacement already covers, write the steps for that person and send them. Name the new path clearly, and offer help with the first run. If the reports describe a workflow with no replacement, the deprecation is not ready. Either build the missing piece, or delay the removal and say so.

Keep a close eye on the heavy users. A small group of accounts can depend on a feature that the majority never touches, and losing them may be expensive. For those accounts, a short direct message from a person on your team is more useful than any public notice.

Deciding what to do with the answers

A clear decision should follow the reading. Either the feature goes on the removal date as planned, or the date moves because a real workflow was found that needs time. Either way, record the decision in an internal note on the deprecation item and share it with the people who reported.

The feature launch feedback guide covers the opposite moment, when a new feature ships, and the same metadata habit applies. For the wider question of when a product should stop supporting something, the sunset article explains how to plan the last months. The guide to saying no helps if a user asks you to keep a feature you have already decided to remove.

Running the deprecation through Escuta Produto

Create or open the product, copy its public key, and add the feedback button to the page that holds the feature. Use the setMetadata call with the stable feature key, and open the widget with the idea type from the button. Each report arrives in the inbox with the feature key and the deprecation date in its metadata, plus the page URL saved automatically.

Before the removal date, filter the inbox to the product, read every item that carries the feature key, and set the status of each one to planned or in progress as you act on it. The widget docs describe the open and metadata calls in full.