Using feedback to choose which product to work on

Why the loudest product is a trap

The product with the most messages feels like the one that needs you most. It generates the most notifications, it is the one customers mention in support, and it is the one you open first. Following the noise is an easy habit, and it often sends a week of work to whichever app has the most chatty users.

Good product decisions start from a different question: where will a week of my work help the most people who pay me? Feedback can answer that question, but only if you read it carefully, separate messages from people and bring in the one number feedback cannot show you.

Count people, not messages

Start with unique people. Ten messages from one enthusiastic customer are one opinion repeated ten times. Five messages from five different customers about the same problem are a pattern.

In the product's inbox, use the text search to find the words each request uses, then count distinct senders. Email addresses help here when people give them. If you pass an email or an id with identify, you can also see whether the same person wrote again. Record the count in your notes for each product, with the date.

Read the direction of the rating

The average rating is useful for direction, not for a verdict. A product at 3.8 that fell from 4.4 last month needs attention. A product at 4.6 with only three ratings tells you almost nothing.

Look at the 30-day chart next to the rating. A drop that starts the day after a release points to a specific change. A slow decline with rising bug counts points to a product that accumulated problems over several months, and that needs a repair plan rather than a single fix.

Add the revenue fit from your billing tool

Escuta Produto does not know what your customers pay, so take that number from your billing tool or payment dashboard. Compare it with the unique-people count for each product. A product with strong revenue and many people asking for better onboarding is a strong candidate. A product with a lot of praise and little revenue may be a good place to test ideas, but a poor place to spend a whole month.

If you pass a segment value with identify, that metadata appears on each feedback item. You can then see whether the people asking belong to the segment you want to grow. That detail can decide between two requests that look equal in volume.

A worked example with three products

For example, suppose product A has 12 messages this month from 4 customers, mostly about slow exports. Product B has 3 messages from 3 customers, all asking for the same integration. Product C has 2 messages from 2 customers, both reporting a broken checkout, and those two customers are among your largest accounts.

A loud reading picks product A, because it has the most messages. A careful reading looks at each row. Product A has a real problem, but four people is a small group, and exports are a known pain point you can schedule. Product C has the smallest volume and the highest stakes, because a broken checkout stops paying customers. The right first move is C's bug, then A's export speed, with B's integration written down for a later month.

Write the decision down and recheck it

Write the choice in one internal note per product: the date, the signals you used and what would change your mind. For example, "Product C first, because checkout bugs block paying customers. Revisit if export requests reach 10 distinct people." Keeping the reason in writing stops you from reopening the same debate every Monday.

Recheck the decision at the end of each month. Use the 30-day chart and the New counts. If the numbers moved, change the plan and note the change. The habit matters more than the exact cadence.

What feedback cannot tell you

Feedback tells you what customers say, not what they would pay for. A product can have many vocal users who never pay, and a quiet product can have one large customer who writes once a quarter. Use feedback to judge demand and urgency, then check revenue and effort before you decide. When the signals disagree, say so in the decision note and start with the smaller, reversible bet.

What if two products are equally important?

Sometimes two products matter about the same. Do not split a week between them unless both bugs are small. Split work by stage instead. One product gets a fix this week and the other gets a discovery pass next week, where you read its ideas and write short specs. That keeps both moving without a context switch every afternoon.

How to choose with Escuta Produto

Use the product list in the dashboard as your starting point. For each product, open the inbox, filter to New bugs and ideas, count unique people with text search and read the rating trend on the 30-day chart. Put the result beside revenue from your billing tool, and write the decision in your notes. For the setup behind per-product signals, the hosted page docs explain how each product collects its own messages. The feedback routine for five products shows how to read each product on a schedule, and one feedback inbox for many products explains why the counts stay separate.