Most product ideas do not fail because the team cannot build them. They fail because a complaint was mistaken for a market.
Public app reviews are useful before you commit to a feature, but only if you treat them as evidence to investigate, not a vote count. A one-star review can reveal a broken experience; it cannot tell you whether a new product will be bought.
Here is the lightweight workflow I use to turn reviews into better customer-interview questions before building a SaaS feature.
1. Start with a decision, not a keyword
Write down the choice you need to make in one sentence.
“Should we build an onboarding checklist for teams moving from tool X?”
Then select three to five adjacent competitors. Do not collect every review in a category. The point is to compare the same job across products, not to create a giant sentiment dashboard.
2. Read low ratings, but keep the original wording
Begin with one- to three-star reviews. Save:
- the review text
- rating and date
- app version when available
- a link or source identifier
- the competitor where it appeared
Keep the raw text. It is tempting to immediately paraphrase complaints into tidy feature requests, but that removes the language you will need later in interviews and landing-page copy.
3. Cluster by the job that failed
“Login is broken” and “I cannot access my account after paying” are not two unrelated bugs. They are both failures of the job: get reliable access to something I paid for.
A useful cluster label has three parts:
- Job: what the user was trying to do
- Breakdown: what stopped them
- Consequence: what it cost them
For example:
| Raw complaint | Cluster |
|---|---|
| “It logged me out before my shift.” | Access reliability -> unexpected logout -> lost time |
| “I paid but premium features disappeared.” | Access reliability -> entitlement failure -> loss of trust |
| “Support never replied.” | Recovery path -> no human escalation -> abandoned subscription |
This avoids the common mistake of building a feature for every negative adjective.
4. Score patterns, not individual reviews
For each cluster, score four questions from 1 to 5:
- Frequency: does it recur across reviews and competitors?
- Severity: does it block a meaningful job or merely annoy?
- Specificity: can you state a testable workaround or outcome?
- Escape intent: do reviewers mention cancelling, switching, or paying for an alternative?
A cluster with many complaints but no consequence may be a support issue. A smaller cluster with a clear recurring consequence can be a sharper product wedge.
5. Write the counter-hypothesis before the feature idea
Do not jump from “people hate this” to “we should build that.” Write the alternative explanation first.
Example:
- Observation: several competitor reviews complain about repeated AI output failures.
- Easy conclusion: build a better AI generator.
- Counter-hypothesis: users do not need more generation; they need a way to check, retry, preview, and confirm a usable output.
The counter-hypothesis turns a review cluster into an interview prompt rather than a premature roadmap item.
6. Turn each cluster into a five-question interview
For the highest-scoring cluster, ask people who recently had the problem:
- What were you trying to finish?
- What did you try when the existing product failed?
- What did that failure cost in time, money, risk, or reputation?
- What workaround do you use today?
- What would make you switch or pay for a different approach?
The review gives you the starting language. The interview tells you whether the pain is current, expensive, and owned by someone who can buy.
7. Make a one-page evidence memo
Before building, keep one page with:
- the cluster name and raw examples
- competitors where it recurs
- your counter-hypothesis
- interview evidence and disconfirming evidence
- the smallest test you could run next
This memo is more valuable than a long feature list. It makes it easy to explain why a problem is worth testing and easy to abandon an attractive idea when the evidence weakens.
A faster way to do the first pass
I built Review2Idea for the mechanical part of this workflow: grouping public App Store and Google Play complaints into source-linked clusters and producing a starting point for an opportunity memo. The first competitor report is free and does not require a card.
Use any tool you like for the clustering. The important discipline is unchanged: keep the source, look for recurrence across competitors, write a counter-hypothesis, and validate it with people before you build.
What is the last competitor complaint you decided to investigate rather than immediately turn into a feature?
Top comments (0)