Building a Card Game Taught Me More About Product Than Any Course

My side project this year is an original digital trading card game, built in an open-source game engine, from the card systems to the art direction to a playable single-player campaign. It started as a creative outlet, something with no client, no deadline, and no stakes beyond my own curiosity. It has quietly become the best product education I have ever received.

I want to explain why, because I think the lesson generalizes past games. Twenty years of communications work taught me a great deal about serving an audience. Building a game taught me things about products that two decades of professional work somehow never forced me to learn, because a game is the least forgiving product there is. Nobody needs a game. Nobody's boss makes them play it. Every second of attention is volunteered and can be withdrawn without explanation. Designing for that audience is product management with the training wheels off.

Scope is the game behind the game

Every game designer learns this the hard way: the design document is infinite and the shipping game is small.

My design document was glorious. Multiple factions, branching campaigns, elaborate progression systems, mechanics layered on mechanics. Writing it felt like productivity. It was actually a form of shopping, filling a cart with features I had not yet learned the price of. The price revealed itself the moment I started building, because in a working game every mechanic touches every other mechanic. Each addition is not a line item. It is a multiplication against everything already there: more rules to teach, more interactions to balance, more cards invalidated by the new system, more ways for the whole thing to wobble.

So I cut. I cut more mechanics than I kept, and every cut hurt, and every cut was right. Not one of them is missed in the game that exists. That last part is the miracle worth staring at: features that felt essential on paper turned out to be entirely optional in reality, and the only way to discover which was which was to try holding the whole system in a working state.

The discipline transfers directly to client work. When a project's feature list grows, I now feel the multiplication instead of the addition, and I can name what a "small" request actually costs downstream. And I have a better answer for the pain of cutting, because I have felt it on my own project rather than just inflicting it on clients: the feature you defer is not lost. It is the price of the thing actually existing. An unshipped product with every feature is worth exactly nothing.

Playtesting is user research with no place to hide

You cannot explain a card game over someone's shoulder. Or rather you can, once, and then that player leaves the room, and the game must stand alone. Either the rules teach themselves through play or the design has failed. There is no onboarding email, no training session, no tooltip that can rescue a fundamentally confusing system, because a confused player does not file a support ticket. They just stop playing.

So you playtest, which means you sit silently while someone plays, and it is the most efficient humility delivery mechanism I have ever encountered. Watching someone misread a card you thought was obvious is humbling in exactly the way watching someone misuse your app, your form, or your website is humbling. I had a card whose wording I had refined across a dozen passes. I knew what it meant. The first real playtester interpreted it to mean nearly the opposite, played accordingly, and was baffled by the result. My instinct in that moment, and this is the instinct to watch for, was to explain. To lean in and say, no, see, it means this. Explanation is the designer's anesthetic. It makes the pain stop without curing anything, because I will not be there to explain it to the next player, or the thousandth.

The user is never wrong about their own confusion. They may be wrong about the fix, they are often wrong about the fix, but the confusion itself is data of the highest grade, collected at the exact point where your model of the user diverges from the actual user. The card got rewritten. So did my process: I now watch people use things I build, silently, before I call anything done. Websites, forms, onboarding flows, apps. Silently is the hard part and the whole part. The moment you explain, the test is over, and you have learned nothing except how good you are at explaining.

Systems beat content

My early instinct was to design many cards. More cards felt like more game, the same way more features feel like more product. So I ground out cards one by one, each individually designed, each needing individual balancing, and the work scaled exactly as badly as you would expect. Every new card made the next card harder to add safely.

The better move, which took me embarrassingly long to see, was designing few systems that make many cards interesting. A handful of well-chosen mechanics that combine, and suddenly cards almost generate themselves: each new card is just a new point in a space the systems already define, inheriting depth from the interactions rather than manufacturing depth alone. The game got richer as the design got smaller. Players do not experience the count of your content. They experience the depth of your combinations.

There is a practical test I now apply to any proposed addition, in the game and everywhere else: does this create new combinations, or does it just create more inventory? A new card that interacts with existing mechanics multiplies the game. A new card that only does its own isolated thing merely lengthens the list, and lists have a way of becoming inventory that someone has to maintain forever. The same test works uncomfortably well on feature requests, service offerings, and even content calendars.

Product work rhymes so hard here it is almost embarrassing. One well-designed data model outperforms twenty bolted-on features, in games and in apps alike. I have watched organizations pile feature on feature, each solving one narrow request, until the product is a junk drawer, when one underlying rethink would have made half those features unnecessary and the other half trivial. The card game gave me a visceral feel for the difference between adding things and designing the thing that makes things. I reach for the second move much faster now, and clients get better systems because a hobby project punished me for the first move in private.

Shipping a slice beats polishing a plan

For months, the game existed as pieces: systems that worked in isolation, content in spreadsheets, a campaign outline, and my complete confidence that it was all basically done except for assembly. Then I forced a rough version to become playable end to end. Ugly, unbalanced, missing half the content, and suddenly every design question had a concrete answer instead of an opinion.

Arguments I had been having with myself for weeks, about pacing, about difficulty, about whether a mechanic was fun, dissolved in an afternoon of actually playing. Some things I was sure were problems turned out to be fine. Things I had never once worried about turned out to be the real problems. The plan and the product disagreed everywhere, and the product was right every time.

The document version of your idea cannot surprise you. The running version does nothing else. I have carried that sentence into every professional conversation since. Whatever you are building, a communications strategy, an app, a campaign, a course, get to the playable slice: the smallest end-to-end version a real person can actually experience. Not a deck about it. Not a roadmap toward it. The ugly working thing. It will surprise you within the first hour, and every surprise is a decision you no longer have to make by argument.

Why the stakes being low made the lessons stick

One more observation, about why a side project taught me what client work did not. On client work, failure is expensive, so we hedge. We plan longer, commit later, and wrap every risk in process. The hedging is rational and it is also why the sharpest lessons never quite land: something always cushions the impact.

On my own project, with nobody to disappoint, I could let mistakes run to their natural conclusion and feel the full weight of each one. I over-scoped and personally paid the entire bill. I skipped playtesting and got humiliated at full price. Every lesson arrived undiluted, which is why every lesson stuck. The side project was a flight simulator for product judgment: real physics, no passengers.

Side projects are not a distraction from professional growth. Pick one hard enough to teach you things clients cannot, something with real users, real constraints, and no one to blame. Then let it be a ruthless teacher. Mine deals its lessons one card at a time, and I am a noticeably better builder for every hand it has dealt me.