Three kinds of feedback

Looking at real app feedback examples, almost every review that asks for a change falls into one of three groups.

  • Bugs: "App crashes when I apply a coupon." Something does not work as designed.
  • Usability problems: "Couldn't find where to cancel my order." It works, but users cannot use it.
  • Feature requests: "Please add UPI autopay." Users want something that does not exist.

Each goes to a different place: bugs to the engineering queue, usability problems to design, feature requests to product discovery.

App feedback examples and the backlog items they become

Reviews: "Payment failed three times with PhonePe", "stuck at payment processing", "money deducted, order not placed". Backlog item (bug): Payment fails or hangs for some UPI wallets at the final step. Evidence: 140 reviews in 30 days, complaint share for payments up from 4% to 11% since version 8.4. Owner: Payments.
From reviews to a bug
Reviews: "where is the return button??", "took 10 minutes to find how to return". Backlog item (usability): Return option is hard to find in order details. Evidence: 60 reviews in 60 days, steady. Owner: Post-purchase design.
From reviews to a usability problem
Reviews: "please add dark mode", "dark mode needed". Backlog item (request): Dark mode. Evidence: 35 requests in 90 days, mostly in otherwise positive reviews. Owner: Product discovery.
From reviews to a feature request

What each backlog item needs

  • Problem statement in the user's terms.
  • Evidence: number of reviews, complaint share, trend, affected versions, languages.
  • Five or more representative quotes.
  • Where in the journey it happens.
  • Owning team.
  • A measure to check after the fix: the complaint share for this issue.

Prioritising review-driven items

  • Bugs with rising complaint share after a release go to the top.
  • Problems that block purchase or access (login, payment) outrank cosmetic ones.
  • Usability problems with steady, high volume deserve a design slot each quarter.
  • Feature requests are input to discovery, weighed against other evidence, not commitments.
Prioritising

How to prioritise customer feedback.

Prioritising cx fixes volume negativity and trend

Free review snapshot

Want this done for your own reviews?

No commitment. We use your details only to send your snapshot and follow up. Privacy policy

A weekly process

  1. Classify new reviews by product area and issue.
  2. Look at issues that are new or rising since last week.
  3. Merge them into existing backlog items where they match; create new items where they do not.
  4. Update evidence on existing items.
  5. After each release, check items marked fixed against the new version's reviews.

Common questions

Should every review become a ticket?

No. Tickets from individual reviews flood the backlog with duplicates. Aggregate reviews into issues first.

How do we handle vague reviews like "worst app"?

Count them, but they cannot become backlog items. Replying to ask what went wrong sometimes produces a specific answer.

Do feature requests in reviews represent most users?

No. They come from users motivated to write. Treat them as signals to investigate.

Who should do this work?

A product operations person or a rotating product manager can run it in an hour or two a week once reviews are classified.

Checklist

  • Bugs, usability problems and requests separated.
  • Reviews aggregated into issues before tickets.
  • Evidence and quotes on every item.
  • An owner for every item.
  • A check after each fix.

Pitfalls

  • One ticket per review, which floods the backlog with duplicates.
  • Treating the loudest request as the most important.
  • Losing the evidence: tickets that say "users complain about search" without counts or quotes.
  • Never closing the loop with the reviews after a fix.
  • Letting review work fall to whoever has time; give it an owner.

Useful tags on review-driven items

  • Source: Play Store, App Store, support.
  • Type: bug, usability, request.
  • Versions affected.
  • Languages seen.
  • Review count and trend at the time of creation.

Doing this with Falcon

Falcon classifies every Google Play review of your app into themes, sub-themes and specific issues with the sentiment of each mention, kept separate from your store reviews but on the same taxonomy. Negative share by topic and month shows which problems are new or growing, and every issue opens the reviews behind it, with the supporting words highlighted.