Product
Gamification in a product that is not a game
- 2 min read
Points and badges lift usage for two weeks and then become noise. What survives them.
What gets asked for under the name “gamification” is usually three things: points, badges, and a leaderboard. What usually happens after adding them is a two-week lift and then a return to where it was, sometimes lower — because a user who has learned that the number means nothing has also learned to ignore it.
A game makes the goal; a product finds one
The difference between a game and a gamified product is that a game manufactures the goal and a product finds one. A player collects points because points are the game; a user of a sales system has a goal that predates your product, and any number that does not move them toward it is extra work in their day.
What is worth rewarding
So the first question is not “what do we reward” but “which behaviour serves the user themselves, and pays back far too late”. Gamification helps exactly where the gap between an action and its result is long: documentation written today and read next month, or data cleaned now that saves an hour next quarter. A behaviour that pays back immediately needs no badge.
A unit you can lose
Second: make the unit losable. A number that only ever rises loses its meaning in two weeks, because every user reaches it by waiting. A streak that breaks, a level that drops if you stop — both work because zero is reachable.
Leaderboards are usually misused
Third: leaderboards are misused more often than not. In a team of ten, comparing first to tenth removes the tenth from the product. Usually it is better to compare a user against themselves a month ago, and to make comparison with others something they choose to open.
And without measurement you do not know
Finally, the part nobody can buy ready-made: all of the above needs measurement. Add points without it and you will not know whether they lifted the target behaviour or only lifted session time, which are not the same thing. And measurement built after launch always measures the period after the change with nothing to compare it against.
MORE
Read next
An assistant for many companies: where it breaks first
The hard part of a multi-tenant chatbot is not the model. It is guaranteeing that one tenant never reads a line of another’s data.
Read moreWhy we build on Odoo instead of replacing it
Replacing a running ERP looks cleaner on paper and costs a year before anything works. Building on it has a different price — this is it.
Read moreArabic is not mirrored English
What we learned building bilingual interfaces that genuinely work in both directions.
Read moreNo model without an eval gate
How we stop a model reaching production before it proves it beats the one already there.
Read moreBoundaries before features
A feature built across a broken boundary costs more later than it saved — and why we spend two weeks on something that never appears on screen.
Read moreFacing a similar challenge?
Tell us what you want to build or improve, and we will help identify the right starting point.

