002: Planning a Gaming App in 40 Minutes with User Story Mapping

User story mapping example, applied live to a product I am actually building: a gamified holistic growth app that blends Tamagotchi, quest-based hero's journey, personal growth, and mental health. Forty minutes of planning, no design, no code. The session walked me from a chaotic vision into a clear activity flow with concrete user stories, and surfaced an insight I did not expect: the most important part of the app is something I can validate before I build the rest of the app. This article extracts the principles. The session is the case study.

Why this matters

Most build-in-public videos start in the editor. I refuse. After fifteen years in product management at companies like SumUp and Trade Republic, and a parallel career as a trained body psychotherapist, the pattern I see is the same on every team: products fail because of bad thinking before the code, not because of bad code. Planning is the part most creators skip on YouTube because it looks boring. It is also the part that decides whether the product exists at all. This episode is a single planning session, mapped live, on a real product. Use the principles in your version.

Principle 1: A bad plan beats no plan, even with AI

There is a simple rule that has not changed in fifteen years of product work: a bad plan is always better than no plan. The plan is wrong on purpose. It is a starting point, a target to push against, a thing your future self can argue with. The version of you without a plan is the one who builds three weeks in the wrong direction and has nothing to argue with except sunk cost.

In my coaching experience, the founders who skip planning do not skip it because they are reckless. They skip it because they trust the build phase to surface the answers. With AI, that instinct gets worse. Claude Code makes building feel cheap. The temptation is to skip the map and start coding because the cost of building seems low. The trap is that low building cost makes the cost of building the wrong thing higher, not lower. You ship faster, then you have more of the wrong thing to throw away.

The classic Pareto split for product work, 80 percent planning and 20 percent building, was always more aphorism than measurement. In the AI era it shifts further. A GitHub study published in 2022 found developers using Copilot completed a coding task 55 percent faster than the control group. When the build phase is cut nearly in half, planning becomes relatively more expensive in calendar time and relatively more leverage in outcome. In my own sessions the ratio lands around 90/10. The exact number matters less than the direction. The AI era pushes the leverage upstream into planning. Building is the fast part now.

The portable rule: even when building is cheap, write a bad plan first. The cost is one afternoon. The version without a plan costs a month.

Principle 2: Map activities before user stories

User story mapping has three layers. A persona at the top, the activities they perform in the middle, and the user stories underneath each activity that describe how the activity is actually done. The temptation, especially when you know the product well in your head, is to jump straight into user stories. You skip the activities because the activities feel obvious.

This is wrong. The activities feel obvious only inside your own head. Written on a map, they move three or four times in a single session. In this episode, the activity flow shifted at least four times: I added "create the hero visually" after I realized the reward had to land before the questionnaire. I split "fill out questionnaire" from "confirm questionnaire" once I saw that the back-end processing had to happen between them. I added "see future milestones" as its own activity after I realized the player needs a visible long-arc payoff, not just a per-quest reward. None of those moves would have surfaced if I had started at the user-story layer.

A practical rule: do not write a single user story until the activity row reads cleanly from left to right and you would not rearrange it again. Once the activities are stable, the user stories drop in fast. The technique is described in detail in my user story mapping guide, which covers the underlying methodology if you want the basics. The value of this episode is watching the technique applied to a product I had not planned before the camera turned on.

Principle 3: The most important part of the app can sometimes be validated before the app exists

The session changed direction at minute thirty-five. I had mapped the activities and most of the user stories. The flow was clear. And then I noticed something. The deepest part of the app, the questionnaire that determines who the player is and what their quests look like, is also the one piece I could put on a landing page tomorrow and gather real data on. I do not need to build the app to test whether the questionnaire works.

That is the lean startup move, and it is not new. What was new for me was realizing the questionnaire is not separate from the product. It is part of the product. Most lean startup validation uses a fake door, a smoke test, something that is not the real product. The questionnaire here is the real product. It is the deep psychology layer that justifies the rest of the app. If the questionnaire fails to land with real users, the app fails too, and I have saved myself months of building.

This is where the body psychotherapist angle changes the planning. An engineer mapping this product would have scoped the questionnaire as one feature among many, slotted somewhere after onboarding. Clinically, I know the questionnaire is the moat. The depth of the psychological inquiry is what makes this app holistic instead of gimmicky. Every other gamified-health app on the App Store is built by engineers and product people. The questionnaire is where the credential matters, and it is where the validation belongs first.

The portable rule: when you are mapping a product, look for the part that determines whether the product works at all. If you can validate that part outside the product, do that first.

Principle 4: Naming is psychology, not branding

Halfway through mapping the user stories, I caught myself writing "user creates their avatar." I stopped. The word felt wrong. Avatar is the engineering term. It is what game studios call the player's in-game representation. It carries no weight. In the context of this app, the player is not creating an avatar. They are creating their hero.

The hero is not a branding choice. The hero's journey is a specific framework in psychotherapy and coaching, originally drawn from Joseph Campbell, used to help clients connect to their deeper desires and form a path toward them. The framework is physical, often embodied, sometimes expressed through movement or drawing or dance. The word "hero" invokes that framework. The word "avatar" does not.

In my coaching experience, when a client renames the thing they are working on, the work changes. The same is true for products. The user stories I wrote after the rename were different. The visual creation step expanded from "pick a character model" to "create a representation of who you want to become." The questionnaire shifted from "preference survey" to "inquiry into desires, challenges, and direction." The whole product got deeper because one word changed.

The portable rule: when a name feels off, stop and ask what the right name actually means. Naming is psychology. It shapes what gets built.

Principle 5: Scope the MVP at the end, not at the start

The classic mistake in MVP planning is scoping first. You start the session by deciding what is in version one and what is in version two, and the activity map gets built to fit the scope. The result is a constrained map that pretends to be a vision.

The reverse order works better. Map the full activity flow first, including the parts you know will not ship in version one. Then walk the map left to right and ask, "What is the smallest cut of this that proves the product works?" That cut is the MVP. In this session, the MVP cut was not the full hero creation and quest engine. It was the questionnaire. Specifically, the questionnaire on a landing page, with no app behind it, sent to real users to gather data. The lean startup move, applied to the specific moat of this product.

By scoping at the end, you also get cleaner cuts for version two and three. Version two becomes "build the hero creation and the first quest type, wire them to the validated questionnaire." Version three becomes "add milestone progression and social loops." The roadmap writes itself once the map is stable.

There is one cost to scoping at the end. You will discover that some of the parts you were excited to build do not make the MVP. The hero creation with the Marvel-pixel-style selfie generator. The location-based Pokemon-style quest layer. Both fascinating, both out of scope for version one. Killing them on camera, with the full map in front of you, is the discipline. The portable rule: the smallest cut that proves the product works is the MVP, and you cannot identify it without seeing the full map first.

What is next

Episode 003 is the design phase. With the activity flow and user stories locked, the next session takes the map into a visual design pass. No code yet. The goal is a low-fidelity wireframe that shows the onboarding, the hero creation, and the first quest screen, so the questionnaire on the landing page has something to point at if the validation works. If you want a sparring partner for a similar planning session on your own product, that is the kind of work I take on in my product coaching engagements. The full user story map from this session is downloadable below, along with a blank user story mapping template you can drop your own product into. The previous episode, the build-in-public system setup, is where this pipeline started. Subscribe so episode 003 lands when the design phase ships.