INCIOGet INCIO Reviews1. Frame a decision, not a vague topic
Avoid asking, "What is wrong with this product?" Define the product, variation, rating range, time window, and decision you are evaluating. A useful question is: "Which durability complaints recur in verified one- to three-star reviews for the largest size, and which appear to trigger returns?"
| Weak question | Stronger research question |
|---|---|
| What do customers hate? | Which failure modes recur in one- to three-star reviews for the current model? |
| How can we beat the competitor? | Which observed issues are specific to the competitor, and which occur across the category? |
| Is the product good? | Which attributes are consistently valued, and under what use conditions do they fail? |
| What feature should we add? | Which requested outcomes recur, and do existing features already address them? |
2. Build a focused sample
Export a consistent scope. Start with lower ratings to discover failure modes, then compare them with four- and five-star reviews to understand what successful use looks like. Keep variations separate when fit, dimensions, color, bundle size, or model can change the experience.
Record the requested and collected counts, sort order, star filter, marketplace, ASIN, and collection date. Check completeness metadata before treating the file as the intended scope. When comparing products, collect and label each product separately.
3. Classify complaints consistently
- Product area: material, fit, mechanism, packaging, instructions, durability.
- Failure mode: breaks, leaks, does not fit, overheats, arrives damaged, confuses users.
- Severity: inconvenience, reduced value, return trigger, safety concern.
- Actionability: product change, quality control, packaging, instructions, listing clarity.
- Evidence: review ID, exact customer language, rating, date, variation, verified status.
Define categories before tagging the full dataset. Test them on 10 to 15 reviews, merge overlapping labels, and write a one-sentence definition for each category so the classification remains consistent.
4. Create a small codebook before full coding
A codebook is a list of labels with inclusion and exclusion rules. It prevents one analyst from tagging “loose fit” as sizing while another treats it as material stretch. Begin with a small set, test it on several reviews, and add a label only when it changes a decision.
| Label | Include | Exclude |
|---|---|---|
| Fit / sizing | Too large, too small, slips, cannot adjust | Wrong item shipped or misleading bundle count |
| Durability | Cracks, tears, loosens, stops working over time | Damage clearly attributed only to delivery |
| Instructions | Setup, assembly, care, or use is unclear | A feature is absent rather than unexplained |
| Listing expectation | Dimensions, compatibility, material, or quantity differed from expectation | A confirmed manufacturing failure |
5. Prioritize patterns, not anecdotes
Frequency matters, but it is not enough. Combine occurrence, severity, recency, concentration in a variation, specificity, and whether the issue is addressable. A rare safety concern may deserve more attention than a common cosmetic complaint. A frequent delivery complaint may not justify redesigning the product itself.
Keep product defects separate from packaging damage, incorrect customer expectations, listing ambiguity, seller service, and carrier problems. This prevents the research brief from recommending the wrong intervention.
6. Write a source-linked research brief
For each prioritized theme, report the observed count and denominator, affected variations, rating range, recent versus older examples, severity, representative review IDs, and contradictory positive evidence. Then state a testable next step and the function that owns it.
The language “7 of 38 collected reviews” is intentionally narrower than “18% of customers.” The first describes your observed file; the second implies a representative customer rate that review data cannot establish.
7. Validate before committing resources
- Read source rows behind every high-priority claim.
- Compare at least one direct competitor and one adjacent solution.
- Check whether the pattern persists in recent reviews.
- Verify dimensions, safety, legal, and compliance questions independently.
- Use interviews, returns data, support tickets, or testing when available.
Reviews are observational evidence and may be manipulated or unrepresentative. They can reveal hypotheses and customer language, but they do not prove market size, technical feasibility, safety, or demand.
Common false positives
- Several reviews repeat one viral complaint but describe no direct experience.
- One old variation drives a problem that the current model may have changed.
- Delivery damage is coded as a manufacturing defect.
- Customers use the same word for different failure modes.
- A frequent complaint is prominent because lower ratings were intentionally oversampled.
Resolve these by checking source language, dates, variations, positive counterexamples, product specifications, and additional evidence such as returns, support tickets, interviews, or physical tests.