Before You Build: A 30-Minute Competitor-Review Evidence Pass

Review2Idea — Wed, 15 Jul 2026 06:15:54 +0000

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?

DEV Community: Review2Idea