After Reading This, You'll Know: Next Time You Improve the Product, What to Fix First, What to Fix Later

“What to fix first, what to fix later” — this is the question I’ve been asked most often in all my years in Amazon.

In the team there’s arguing, the boss weighs in, ultimately often it’s whoever has the loudest voice wins, or whoever has the highest position has the final say.

Result? After fixing, negative review rate doesn’t change, investment goes to waste, teams blame each other.

This problem is essentially about decision-making basis — not about ideas.

A Typical “Argument” Scenario

I’ve seen a very typical case:

Operations says: “Quality feedback is most frequent, should fix quality first.” Design says: “No, reviews mention appearance problems more.” Customer service says: “You all haven’t seen the customer service records — returns are the most serious.” Boss decides: “Then let’s fix packaging first.”

A month later, negative review rate unchanged.

Why? Because decisions without data support are essentially gambling.

Is what operations said “quality feedback is most frequent” true? Do you have data? Is what design said “appearance problems more” quantified? Is what customer service said “returns most serious” counted?

No one’s conclusion can be verified — any conclusion could be right, but could also all be wrong.

The Correct Decision Framework: Use Data to Answer “What to Fix First”

Now when I make product improvement decisions, I use this framework:

Step 1: Quantify — not “which problem is more” but “what percentage does each problem account for”

For example, you analyzed 500 reviews and found 150 negatives.

Not simply saying “quality problems are biggest” — you need to count:

• Quality-related negatives: 68, accounting for 45% of total negatives
• Experience-related negatives: 52, accounting for 35% of total negatives
• Service-related negatives: 30, accounting for 20% of total negatives

This tells you: quality problems are biggest, but not the only ones — other problems also need attention.

Step 2: Classify — not “quality” but “what kind of quality”

“Quality” is a very broad word. Material is quality, workmanship is quality, durability is also quality.

I recommend using three-dimensional classification to divide negatives:

Product dimension: quality, design aesthetics, functionality, safety, description accuracy Service dimension: logistics, packaging, customer service attitude, after-sales response Experience dimension: usability, scene compatibility, satisfaction

When saying “quality problem,” it could be material brittleness (product dimension), or incomplete functionality (product dimension), or size mismatch causing difficulty of use (experience dimension).

Resolution approaches are completely different.

Step 3: Merge — merge same-semantic problems for counting

Users saying “poor quality,” “not durable,” “broke after two days” — actually the same problem.

If you don’t merge, you’d think there are three problems and waste resources studying three “sub-problems.” If you merge, you’d discover this is just one “poor durability” problem — solve this point and 67% of negatives disappear.

Merge same-semantic problems for accurate problem distribution.

Step 4: Sort — rank by severity

Not “which problem is mentioned most” but “which problem has best resolution effect.”

Prioritizing requires considering two dimensions:

1. Problem proportion: larger proportion means more affected users, prioritize 2. Resolution cost: some problems have large proportion but high resolution cost, some have small proportion but low resolution cost

Ideally, first solve problems that are “large proportion AND low cost” — quick results.

Step 5: Act — each problem corresponds to specific improvement action

Not “improve quality” but:

• Material issues → contact supplier to change materials/introduce third-party quality inspection
• Workmanship issues → ask factory to improve process/establish factory outgoing inspection process
• Instruction issues → rewrite instructions/add usage video
• Compatibility issues → label suitable user groups on detail page/adjust product design

“Improvement plans” without specific actions are just creating illusions.

A Real Sorting Case

I previously helped a seller with product improvement using this framework.

Analysis results:

Solving P0 and P1 addresses 55% of negatives.

Actual execution results: two months later, negative review rate dropped 40%.

Three Common Mistakes

Mistake 1: First Fix “Easy to Fix”

Many sellers like to pick the easy problems first — whichever problem is easiest to fix, that’s what they start with.

Result: easy problems solved, but negative review rate unchanged, because problems that truly affect users are still waiting.

Correct approach: first fix “large proportion and serious impact” problems, regardless of difficulty.

Mistake 2: Want to Solve All Problems at Once

Seeing a problem list, they want to solve everything at once.

Result: resources scattered, every problem fixed a little, but none fixed thoroughly.

Correct approach: each time only solve Top3-5 problems, concentrate resources, finish one then move to the next.

Mistake 3: Use Static Data for Decisions

Analyzed reviews once, then always follow this conclusion.

But reviews are dynamic — new negatives come, old problems might be solved.

Correct approach: regularly (e.g., monthly) re-analyze, compare data changes, dynamically adjust priority.

Tool Recommendations

Using the framework isn’t hard — what’s hard is execution at the operational level. Counting, classifying, merging, sorting — doing these manually takes too much time.

I currently use AstrMap — several features save me a lot of effort:

1. Three-dimensional classification automated: input ASIN, automatically gives classification and count results
2. Same-semantic problem merging: no need for manual categorization
3. TopN problem sorting: auto-sorted by problem count, priority at a glance
4. Improvement suggestions: system provides improvement suggestions based on problem types
5. Incremental comparison: regularly re-analyze and compare data changes

Of course, tools are auxiliary — the framework is core. Tools help process data, you make decisions.

Question in comments: How does your team currently decide “what to fix first”? Have you experienced situations where fixing had no effect?