I’ve been making small games since university. Nothing shipped, nothing famous — just weekend projects that taught me more about product design than any PM course I’ve taken.
Here’s what I mean.
Games have no mercy
When you build a consumer product, users are polite. They’ll tolerate a confusing onboarding flow. They’ll click through a broken UI. They’ll give you the benefit of the doubt.
Games don’t work like that. If a game is confusing for even five seconds, the player quits. If the first level isn’t fun, they uninstall. There’s no politeness, no tolerance, no second chances.
This is brutal. It’s also clarifying.
Building games taught me to ask a harder version of the product question. Not “does this feature work?” but “is this feature worth the player’s attention right now?” Every second of a player’s time is a vote. They’re constantly deciding whether to keep playing or do something else.
That’s the real standard for product design. Not “does it work” but “is it worth it.”
The tutorial problem
Every game designer knows the tutorial problem: you need to teach players how to play, but tutorials are boring, and boring players quit.
The best games solve this by making the tutorial indistinguishable from the game. You learn by doing. The first level is the tutorial — it just doesn’t feel like one.
I think about this constantly in product. Onboarding is the tutorial problem. Most products solve it badly — they show you a slideshow of features before you’ve done anything. The best products make the first experience so good that you learn naturally, through use.
The question isn’t “how do we explain this feature?” It’s “how do we design the feature so it explains itself?”
Feedback loops and dopamine
Games are engineered feedback loops. You do something, you get a response, you do more. The response has to be immediate, legible, and satisfying. Delay the feedback by even a second and the loop breaks.
Product teams often underinvest in feedback. You submit a form and get a generic “success” message. You complete an action and nothing changes visually. The loop is broken.
The best product moments feel like games. You complete a task and something satisfying happens. You reach a milestone and the UI celebrates with you. These aren’t frivolous — they’re the feedback that keeps users engaged.
Difficulty curves
Every good game has a difficulty curve: easy at first, gradually harder, with occasional spikes that feel challenging but achievable. Get the curve wrong and players either quit from boredom (too easy) or frustration (too hard).
Products have difficulty curves too. We just don’t think about them explicitly.
The onboarding flow is the early game. The power user features are the late game. The question is: does the difficulty curve match the user’s growing capability? Do we introduce complexity at the right pace?
Most products fail here. They’re either too simple (no depth for power users) or too complex (overwhelming for new users). The best products have a difficulty curve that grows with the user.
What I actually do differently
Concretely, game design has changed how I work in a few ways:
I prototype interactions, not just features. Before writing a spec, I sketch the interaction. What does the user do? What happens immediately? What’s the feedback? If I can’t describe the interaction clearly, the feature isn’t ready.
I obsess over the first 60 seconds. The first minute of any product experience is the most important. I spend disproportionate time on it.
I think about intrinsic motivation. Games work because they tap into intrinsic motivation — mastery, autonomy, progress. The best products do the same. I ask: why would someone want to use this, not just need to?
I kill features that don’t earn their place. In games, every mechanic has to justify its existence. If it’s not fun, it’s cut. I try to apply the same standard to product features. If a feature doesn’t clearly improve the experience, it shouldn’t exist.
Games are the most honest form of product design. I’m grateful I started making them.