← All insights
LiveOps
Players Are Complaining About the Wrong Problem
A request is a symptom report. Treat it as a lead, not a specification.
Players are good at noticing that something feels wrong. They are much less reliable at naming the cause or the cure, and they are not meant to be. When someone says “add trading”, they are describing the solution they imagine, not the problem they have. Building exactly what they ask can leave the real problem in place.
Common requests and what may sit under them
| What players say | Possible underlying problems | How to tell |
|---|---|---|
| Add more maps | The current map is repetitive, progression is too slow, the game lacks variety in goals | Do players leave after repeating a map, or after hitting a wall? |
| Make this cheaper | Price too high for the value, unclear what it does, rewards earned too slowly, low trust | Compare views of the item with purchases and what buyers do afterwards |
| The game is boring | Confusion, no goals, too little challenge, too much grind | Watch first sessions, look at where they stall |
| Add trading | Duplicate items with no sink, players want to collect, they want to socialise, they are stuck on drops | Check how many unwanted duplicates exist and whether players already trade outside the game |
Why the literal fix can fail
- A new map does not help if players leave before they finish the first one.
- A price cut costs revenue and does nothing if the item’s purpose is unclear.
- Trading adds an economy to defend: scams, duplication risks, inflated prices, moderation. If the real need was a use for duplicates, a simple conversion system could meet it at a fraction of the cost.
Use four sources together
- Behaviour
- What players do in the game: where they stop, what they ignore, what they repeat.
- Analytics
- How many do it, in which cohorts, and how it changed over time.
- Observation
- Watching real sessions to see the confusion that numbers hide.
- Feedback
- Which words players use, how many say it, and who is saying it. A new player and a ten-hour veteran may want opposite things.
Any one of them can mislead. When they agree, you have a finding.
A method for each request
- Restate the request as a need: “I want trading” becomes “I cannot do anything with items I do not want.”
- Ask what the player was trying to do when they thought of it.
- Find the behaviour in the data that would be true if the need is real.
- List other ways to meet the need, including the cheap ones.
- Test the cheapest option that addresses the need before building the requested feature.
- Tell players what you learned. “We looked at this and here is what we are doing” builds more trust than a flat yes or no.
When to build exactly what they ask
Sometimes the request is right. If many players ask for the same thing, the behaviour backs it up, and the cost is reasonable, build it. The point is to check, not to ignore players.