How to weigh feedback from paying vs free users

Payment is one signal, not the whole answer

Paying customers have committed money, so their requests deserve weight. They are also the people your roadmap should serve most directly. But payment alone does not tell you whether a request matches your target customer. A large account can ask for things your product will never do, and a free user can describe the exact blocker that keeps a whole group from ever paying.

Weigh each request on three questions: is the sender in the group you are trying to serve, how many distinct people from that group asked, and how well the request fits the direction you have chosen?

Send a segment field with identify

Escuta Produto stores extra keys you pass to identify as metadata, so you can attach a segment to each sender. Use a name that fits your business:

EscutaProduto.identify({
  email: user.email,
  name: user.name,
  id: user.id,
  segment: user.segment,
});

Pick a short list of values, such as "paying" and "free", and use the same values in every product. Write down what each value means. A free account might be one that never paid, or one that stopped paying, and those two groups behave differently. Decide which meaning your field uses before you read any counts. Set the field from your own records after login, and send only what you are comfortable storing with the feedback. The full options are in the widget docs.

If you submit feedback from your server through the REST API, put the same field in the metadata object of the request body. The hosted feedback page cannot receive identify data, so requests from it arrive without a segment unless you add one another way.

Compare requests across segments

For each request, count the distinct senders in each segment and place the numbers side by side. Read them against the size of each segment. A request asked by two of ten paying accounts means something different from a request asked by two of a thousand free users.

Here is an invented example to show the shape of the comparison:

Request (invented example)	Paying senders	Free senders	What it suggests
Single sign-on for teams	9	1	Matters to larger accounts already paying
Template library	2	6	Blocks new users from reaching their first result

The single sign-on request belongs on the roadmap for the paying segment. The template library deserves a closer look, because free users cannot reach value, and that affects who ever becomes a paying customer. Neither row settles the decision alone, but together they show where to look next.

When free users matter more

Free users matter most in three cases:

• They describe the first-run experience. If they stall during setup, the paying segment never grows.
• They cannot reach the feature that makes the product worth paying for.
• They are the next group you want to win, so their requests show what that group needs.

A concrete case helps. Consider a free user who stops during setup because the import step rejects their file format. Few people may hit that problem, but each one is a lost chance to grow the paying group. A paying account asking for advanced reporting is a larger request, yet it serves a group you already keep. Both can be right, and fixing the import usually costs less and opens a path to growth.

When free users reject a change, do not assume paying customers want the opposite. Ask a few paying customers directly before you reverse a decision.

Avoid the loudest-segment trap

The biggest risk is letting one segment set the roadmap through volume alone. Write the rule before you start, for example: "paying customers decide scope, and free-user feedback decides onboarding fixes." Review the rule once a quarter.

A weighted score can help, but only if you can explain every weight. A simple rule that the team can defend is worth more than a precise formula nobody understands.

When segments disagree

Sometimes paying customers ask for one thing while free users ask for the opposite. Do not settle that by counting who is louder. Write both positions in one internal note, with the distinct counts for each segment and the problem each group describes. Then ask which group the next quarter's work is meant to serve. That answer usually settles the trade-off.

If the direction is still open, run a few short conversations with people from each segment before you commit to either side. Record what you learned in the same note, so the decision and its reason stay together when the team changes.

Segment the inbox with Escuta Produto

1. Send the segment field with identify for logged-in users, and in the REST API metadata for server-side submissions.
2. Filter the product inbox to type idea and praise, and read items from both segments.
3. Write the segment counts for each request in an internal note, or in your weekly sheet.
4. Export the CSV each week and compare segments with a pivot table, using how to analyze customer feedback in a spreadsheet.
5. If you run several products, use how to choose which product to work on to compare the segments across them.

For the request-level scoring that follows, see the problem behind a feature request.