Metric Alchemy: The Council of Chronos
Built a gamified PM learning game from scratch with AI in two weeks, shipping 18 levels, 8 story scenes, and instrumented analytics that surfaced a specific onboarding bottleneck in week one.
- Stack: Next.js · React Flow · Framer Motion · Mixpanel · Vercel
- AI used: Claude · Claude Code · Gemini
- Live: metric-alchemy.vercel.app
Problem
PM candidates freeze on unfamiliar metrics because no transferable method existed to teach this
Solution
A six-unit gamified learning game built solo in two weeks using AI across research, content, code, and visuals
Outcome
43 users, 701 questions answered, 63% correct rate, ten full game completions, specific bottleneck identified at 59% progress through Unit 1 Level 1
The problem, the gap, and why a game
A question kept surfacing in my PM fellowship group sessions: "How do you approach a metric you've never seen before?" It would get a general answer about interview structure and everyone would move on. Then it came back again the following week. And the week after. Nobody had a satisfying answer, including me.
I posted in the group chat channel to check if this was just me, but many people agreed that they had the same issue. A few days later, few people reached out privately asking if I'd found anything. The unprompted follow-up confirmed that people were looking for an answer that didn't exist yet.
Most PM interview resources fall into two buckets. One type teaches you how to structure and communicate your answer in an interview: how to clarify, how to frame your thinking, how to come across well. The other gives you lists of metrics to memorise: DAU, retention rate, NPS, GMV. Both assume you already understand the metrics being discussed. Neither teaches what to do when you encounter a metric you've never seen before and need to work through it from scratch.
That gap is what this game addresses. I spent several weeks going through interview prep resources, decomposition approaches, and practitioner content looking for a method that could be applied to any unfamiliar metric. Nothing existed as a single teachable framework. So I built one through research and trial and error, testing it against unfamiliar products until it held up consistently.
01 - Domain Grounding: Identify the economic engine.
02 - The Funnel: Where does this metric sit in the user journey?
03 - Metric Type: Count, Rate, or Product?
04 - Constituent Identification: What is it made of?
05 - Unit Test: Do the child node units resolve into the parent?
The obvious formats were all wrong for the same reason.
An article explains the framework once. Someone reads it, feels like they understand, and freezes the next time they see something unfamiliar. A course has the same problem with more content in the way. A Claude skill could provide a guided teaching session but would only reach people already using that specific tool. None of these build the reflex. They deliver information.
The problem wasn't a lack of information about metrics. It was a lack of practice applying a systematic method across enough varied contexts for it to become automatic under pressure. That's something that can only be fixed with practice.
Games are the natural container for structured practice at scale. 67% of students find gamified learning more engaging and motivating than traditional methods, gamified learning increases retention rates by approximately 40%, and 80% of workers report that gamified learning experiences are more engaging than standard training (Zippia).
A game could deliver the framework across 18 levels and dozens of unfamiliar products, building the reflex a single read-through never would.
The first version of the game was wrong, and the failure taught something important
The first version of the game I built was called Metric Lab. A game based on the metaphor of a chemistry lab where metrics were treated as chemical elements: a mad scientist character, beakers, a pouring mechanic. A working Level 1 prototype was built, then tested with a small group.
The feedback was consistent: the chemistry metaphor didn't fit. Two problems emerged. First, players had to mentally translate between the lab world and actual metric thinking at the same time, which created friction right where the experience needed to feel natural. Second, the lab mechanic abstracted the learning itself. When your task is "pour this element into that flask," the mental model you build is about lab interactions, not metric decomposition. The mechanic was obscuring the skill rather than teaching it.
The failure revealed a useful design principle: the story world and the gameplay mechanics don't need to share a domain. The story creates emotional investment. The gameplay teaches the skill. Trying to make them the same domain was the mistake.
The pivot was an alchemical academy with a council competition storyline, wrapped around metric decomposition mechanics that stand on their own terms. The alchemy metaphor didn't need to explain the mechanics. It just needed to make someone want to keep playing.
The product: six units, each owning one step of the framework
Three product decisions shaped how it works.
Decision 1
Teaching before attempting creates recall, not reasoning
The first design was standard teach-then-quiz. Early playtesting revealed the problem: players were recalling what they'd just read, not genuinely reasoning. Getting a question right because the answer was on the card thirty seconds ago is not the same skill as working something out under pressure.
The format was reversed. Players see a primer question before any teaching. They commit to an answer from instinct, no feedback shown. The learning card appears as a reveal, showing whether their instinct was right and explaining why. Then a confirmation question tests whether it clicked.
The gap between what you guessed and what's true is where learning happens. This operationalises retrieval practice: the research-backed principle that attempting before studying produces stronger long-term retention than studying then testing.
Decision 2
Decomposition is generative. Multiple choice tests the wrong skill
Multiple choice was right for the first three units, where the skill is recognising and reasoning about concepts. But from Unit 4 onwards, the skill is constituent identification. You construct the decomposition rather than just selecting it.
Testing a generative skill with multiple choice would have players picking from options instead of building from first principles. That's a different cognitive activity from what the framework requires.
The solution was a custom interactive tree builder built with React Flow. Players drag nodes from a bank, place them in the correct position in a decomposition tree, select the relationship type (+, x, or ÷), and submit. For Unit 5, this extends to multi-level progressive trees where each confirmed level locks and expands downward, up to five levels deep.
Decision 3
The story isn't decoration. It embeds the argument
Eight visual novel scenes wrap the gameplay. Three characters: Lucius, who tries to understand why things work; Orpheus, who memorises answers and Master Lazarus, who sees through both of them.
Orpheus knows the answers and fails when asked why. Lucius understands the reasoning and succeeds. The story doesn't just create engagement. It makes the case for the method players are learning, so they experience the argument, not just the content.
One deliberate constraint: no sign-in, no accounts. Click the link and play immediately. Game state lives in localStorage. For someone practicing before a PM interview, zero friction mattered more than cross-device persistence.
How it was built
Research and content: Using Claude, I synthesised the five-step framework from scratch across PM interview resources, decomposition approaches, and learning science research because nothing existed as a single teachable method. The same AI-assisted process produced over 200 individual learning moments across 18 levels, each with primer questions, correct explanations, and illuminating wrong-answer explanations, plus a 30+ term progressive glossary.
Build and visuals: Claude Code handled the full engineering stack: scene player, map screen, primer-learn-confirm loop, React Flow tree builder, Mixpanel instrumentation, and deployment. Story scene images, the game map, wordmark, and progression emblem were generated with Gemini using detailed style prompts. Every major product decision was tested through AI-assisted critique: the chemistry lab pivot, the teach-then-quiz redesign, the tree builder replacing multiple choice.
What the data showed after two weeks
| Metric | Number | What it means |
|---|---|---|
| Unit 1 Level 1 Completion Rate | 57% | 13 of 30 starters dropped off, most at an average of 59% progress, right around the mixed questions section at the end of the level, a specific friction point with a specific location |
| Median Time Per Question | 54s | 701 questions answered, 63% correct rate, a 54-second median means players are reading and reasoning, not clicking through |
| Mobile Game Starts | 50%+ | iPhone and Android account for more than half of all starts, a tree builder layout bug found through mobile play was diagnosed and fixed within the same day |
| Full Game Completions | 10 | Ten users completed all 18 levels and watched the ending scene. |
| Framework Screen Opens | 40 | 27 from first-time onboarding, 13 from direct map button access on return visits, return visits suggest players are actively referencing the framework while playing |
Reading the funnel
The 57% Unit 1 Level 1 completion rate looks like a difficulty problem but one row changes the read: every user who finished Level 1 continued into Level 2, and everyone who reached Level 3 finished it. The drop-off isn't a general difficulty curve wearing people down across the unit. It's one specific gate at the end of Level 1, exactly where the abandonment data places it: the mixed questions section at 59% average progress.
That distinction matters for prioritisation. A leaky funnel calls for smoothing difficulty throughout the unit. A single gate calls for a much smaller, higher-leverage fix: rework that one section. And the stakes are real: 30 of the 43 users who started the game made it as far as the gate before dropping. Fix it and nearly double the number of users who ever see Unit 2.
The mobile data and framework-screen opens are useful signals for how people engage once they're in but they don't shape what ships next, the gate does.
What I'd do differently
Ship smaller, earlier. A two-unit version could have launched in three days and generated real feedback that would have shaped the rest of the build. I over-built before validating. Next time I'd test: whether a two-unit version with the same primer mechanic produces a higher U1-L1 completion rate by reducing time-to-first-completion.
Mobile-first from day one. More than half of all game starts are on mobile. Designing for desktop and adapting late meant a real user hit a real bug after hours of play. Mobile-native from the start would have caught this in testing. Next time I'd test: whether a portrait-mode layout for the first three units (which are MCQ only, no tree builder) removes the orientation friction entirely for the majority of mobile users.
Instrument from the prototype. Mixpanel was added near the end. Basic event tracking at the prototype stage would have given data on the chemistry lab mechanic and made the pivot decision faster and more confident. Next time I'd test: whether tracking time-on-learning-card alongside question correctness reveals a correlation between reading depth and primer accuracy.
Takeaways
The hardest part wasn't the build. It was finding a framework that didn't exist, testing it until it held up, and designing a format that would actually transfer the skill rather than just explain it.
Play the game: metric-alchemy.vercel.app