Review mining with Claude: keep customer words traceable

Choose the question before collecting reviews

Name the product, relevant alternatives, customer group, market and period. Then choose a question that could change your work: “How do new note-taking app users describe planning their day?” gives you something to look for. Tell Claude which decision the answer will inform, and have it ask about missing scope before analyzing.

For repeated work, use a Claude Project with reusable company and customer context. Add the permitted review material there. For a bounded one-off batch, a regular chat with the permitted material attached is an option. Claude’s Project guide explains how uploaded knowledge and instructions are used across chats within a Project.

Find review pages and open the originals

Start with ordinary Google searches. For example, replace Notion with the product you are researching:

• "Notion" reviews
• site:g2.com/products/ "Notion" reviews
• "Notion" "daily planning" review

Quotation marks search for an exact phrase; site: limits results to a domain. Google’s search-operator guide explains both. Search broadly before adding a problem term: a search for complaints deliberately selects negative experiences.

Open each relevant original and check the product, publication date and surrounding text. A search snippet is a lead to inspect, not the passage to quote. Note whether you found a reviewer’s own account, a vendor-selected testimonial or a summary written by someone else. Keep those source types distinct.

Before copying or uploading reviews, check the source’s terms and your organization’s rules for the intended use. If that use is unclear, work with approved first-party feedback or suitably licensed material. An inaccessible original stays a research lead; leave it out of your evidence.

Keep the words beside the interpretation

Give each included review a short ID. Save its source, review date, the date you checked it, stated customer context and the relevant passage in a document or spreadsheet. Leave missing details unknown. A review written in English does not establish that its author is a US buyer.

Have Claude extract passages relevant to your question, preserving the exact wording and source ID, then place its interpretation beside each passage. Compare the extracted text with the original yourself, including qualifications such as “on mobile” or “after setup.” A useful paraphrase belongs in the interpretation column, without quotation marks.

Here is an invented illustration, not a real review. Suppose a reviewer writes that they forget to set daily intentions in one app, but seeing an intentions section in the journal they already open gives them a reminder.

An illustrative interpretation is: “This reviewer found it helpful to see daily intentions inside an existing journaling routine.” Writing “Customers need more notifications” would add a solution the passage never requests and an audience it never establishes.

Group themes without losing the exceptions

Once you have checked the passages, have Claude propose groups of related observations and list the supporting review IDs. Review those groups yourself, and keep opposing experiences beside the theme. Compare the stated role, plan, date and use case before deciding whether the disagreement has an explanation. If those details are missing, keep the explanation as a question.

Count each confirmed unique review once. Record exclusions, such as a wrong product or a date outside your period; investigate suspected duplicates before merging them. If you report a theme count, include the total eligible reviews and the IDs behind the count. It describes the material you read. Reviews selected for a particular complaint cannot establish how common that complaint is among all customers.

Also check actions carefully. A reviewer who considered another product and stayed has not switched. Preserve what the passage says even when it weakens the story you expected to find.

Turn a finding into something you can test

For the invented journaling illustration, the next question is where your intended customers already look when planning their day. Ask about their recent routine before suggesting a notification feature. Look for current evidence that supports the need and for people whose existing routine already works.

You can then ask Claude for wording based on the checked finding. Keep it labeled as proposed, and verify that your product delivers what the sentence promises. Customer language suggests what to investigate; product evidence supports what you can claim. Use the positioning-brief lesson when you are ready to connect those two kinds of evidence to a buyer and an alternative.

Save the checked passages and findings in a reusable review document. Keep proposed wording separate from approved messaging, and reference review IDs from competitor notes instead of duplicating whole reviews. When a source changes or a contradictory review appears, revisit the affected finding and message. Refresh any manually uploaded Project copies that depend on it.

When reviews leave the buying question unanswered

If the reviewer did not address a follow-up, that review does not answer it. List the missing questions before collecting more of the same material. For a small research task, the customer-interview plan explains how to define the decision, recruit appropriate participants, and keep interview evidence distinct from public reviews.

Review mining can remain a manual workflow: keep the corpus bounded, preserve the source beside each passage, and revisit only findings affected by new or contradictory material. Your team still chooses the research question, checks the evidence, and approves any message built from it.