Mouse to Horse: Iterative Game Loop Design

Most teams launch a horse leg. Then an eye. Then a tail. Then they wonder why nothing works.

I’ve watched this pattern for two decades. You get excited about the vision. You see a complete, magnificent horse galloping through your imagination. So you divide the work. One team builds movement. Another builds visuals. A third handles interaction. Six months later, you ship something that looks impressive on a feature list but does nothing alive.

Here’s the rule I learned the hard way: Launch complete organisms, not body parts. Start with a mouse. A real, living, functional mouse. Then evolve: mouse → dog → horse.

Table of Contents

• The Difference Between a Mouse and a Horse Leg
• Your MVP Is Not Your Crappiest Product
• Find Your Dead Ends
• The Game Loop Engine Maps to How Humans Work
• How We Built This at Octalysis Prime
• You Need GPS: Analyze Before Design
• Hidden Feedback Vehicles Are Triggers
• Three MVP Pitfalls You’re Probably Making
• One Designer Owns the Whole Loop
• The Bottom Line
• Frequently Asked Questions

About Yu-kai Chou

The Difference Between a Mouse and a Horse Leg

A mouse is small. A mouse has one core loop. Watch video → earn XP → unlock chest → repeat. Every single step connects. The reward triggers the next action. The action earns the next reward. It’s circular. It’s alive.

A horse leg is a feature. It looks powerful. It goes nowhere. You can watch a video and earn coins, but coins don’t do anything yet. You can capture creatures, but they sit in your inventory like digital taxidermy. You have a battle system, but battling takes you out of the learning path. Three steps forward, zero back. Arrows pointing in. Nothing coming out.

Dead ends don’t matter in Month 12. In Month 1, they kill momentum.

The anti-pattern is obvious when you see it: 10 features sitting beside each other with no connective tissue. You can almost hear the design meetings: “We’ll build progression,” “We’ll add combat,” “We’ll create trading.” And nobody’s asking: Does completing one create the hunger for the next? Does the reward pull you forward or dump you on an island?

Your MVP Is Not Your Crappiest Product

There’s confusion here. An MVP isn’t the minimum viable quality. It’s the minimum product that proves your hypothesis.

The hypothesis might be: “Users will watch videos if we give them visible progress.” Not: “We can ship 47 features in an MVP.” Not: “We’ll launch with everything but janky.”

I call this the Squirrel-to-Horse principle. Start with something small that works completely. The squirrel version proves the core loop. Then you scale: squirrel → rabbit → deer → horse. At each stage, you have a living system, not a Frankenstein.

The reason this works is simple. A complete mouse gives the user a first major win early enough that the discovery phase feels rewarding instead of confusing. That early success builds confidence, which is what earns you a second loop instead of a silent uninstall. Without that moment, even smart features feel like homework on Day 1.

Find Your Dead Ends

Here’s the practical move: Draw your game loop as a flowchart. Use arrows.

Start with your first trigger. Player opens app. Show every single action. Every consequence. Every reward. Every next step. Follow the arrows.

Now look for elements where the arrow goes in but nothing comes out. That’s a dead end. Those are your next iteration priorities, not because they’re fun ideas, but because they’re breaking the loop.

I used to see design docs with 15 features and 3 actual loops. Now I ask: “Where are the dead ends?” Suddenly the priority list gets simple. (If you want a structured approach to this mapping, the Desired Action Audit walks through it screen by screen.)

The Game Loop Engine Maps to How Humans Work

This isn’t theory. It’s how the Hook Model works.

Trigger → Action → Variable Reward → Investment that creates the next trigger.

The last step is the one everyone misses. Before the user leaves, you’ve already set the alarm clock for the next visit. The investment isn’t just about spending effort. It’s about creating the next trigger. I completed a quest, so I want to do the next quest. I earned coins, so I want to see what they unlock. I unlocked a tier, so I’m curious about the next one.

Without this? The user’s motivation leaves with them. They beat your level and think, “Well, that was nice,” and never open it again.

How We Built This at Octalysis Prime

June 2018. We were launching the first version of our game platform. We could have built everything. Instead, we built a mouse.

The loop: Watch videos → Earn XP → Open chests every 20 hours → Gain Chow Coins → Capture Geomon creatures → Earn power-ups → Upgrade to next tier.

It was intentionally tiny. But here’s what mattered: every element fed the next. You watched because you wanted XP. You wanted XP because it moved you toward the next chest. You wanted the chest because it had coins. And so on.

Except: coins couldn’t be spent. Geomon did nothing. We shipped dead ends knowing exactly what they were.

Why? Because the core loop (the mouse) was proof of concept. It worked. People came back. Our day-active to monthly-active ratio was 30-40%. For an app that’s literally “watch my face on your screen,” that’s Netflix-level engagement.

Then we connected the dead ends. Coins became the currency for EXP boosts and creature traps. Geomon weren’t just collectibles. You could sell them for coins or free them for engagement-building cooldowns. Each iteration, the loop got tighter.

One decision we made: We said no to Geomon battles. We could have added turn-based combat. It would have been beautiful. But the business metric was learning time: how long users spent understanding the creature mechanics. Battles distracted from that. And strategy (real strategy) is not about choosing what to do. It’s about choosing what not to do.

That constraint forced us deeper into the loop we had. It made it better. That focus mattered.

You Need GPS: Analyze Before Design

I work with a lot of teams using frameworks that jump straight to design. Build this feature. Add that mechanic. Gamify that moment.

But you can’t navigate without two things: your destination and your current location. You need GPS.

That means before the design doc, you analyze. You understand where your user is now. You understand the business metric you’re optimizing. You understand the hypothesis you’re testing. Only then do you design the loop that connects them. (This is the same principle behind the Strategy Dashboard: know your business metrics, player types, desired actions, feedback mechanics, and incentives before you start designing.)

Most teams skip this. They feel it’s slowing them down. They ship faster. They iterate slower.

Hidden Feedback Vehicles Are Triggers

Game loops aren’t just inside your product. You have feedback vehicles everywhere. Customer support calls. Newsletter opens. Social community messages. Emails.

Most teams treat these as one-way broadcasts. “Here’s a new feature. Use it.” But these are triggers. A support call where we help someone understand your system? That’s an investment that creates curiosity about what else is there. A newsletter that shows progress? That’s a reward that primes them for the next action.

Redesign them as loop elements. Now every touchpoint strengthens the cycle.

Three MVP Pitfalls You’re Probably Making

Pitfall 1: Using MVP for validation instead of learning. You want to validate that your idea is good. But your MVP’s job is to teach you what works. These are different. Validation asks, “Do users like this?” Learning asks, “What do users actually need?” The second builds moats. The first builds products that get copied.

Pitfall 2: Idea Lust. One sentence on a spreadsheet becomes a three-week development cycle. Your founding story is “we’ll build a platform for,” and suddenly you’re designing five interconnected systems. Write it down first. How does Idea A feed Idea B? If you can’t trace it in one paragraph, it’s a horse leg, not a mouse.

Pitfall 3: Shipping and stopping. You launch your first loop. It works. Now you think you’re done. You’re not. You’re at the mouse stage. The question isn’t “did the mouse work?” It’s “how do we become the dog?” That requires discipline. You’re running the first loop at full capacity while designing the next one. Most teams get tired here.

One Designer Owns the Whole Loop

Factory-style design kills loops. You have a progression designer, a combat designer, an economy designer. Each owns a piece. Each optimizes their piece. The result is generic.

You need one person (or one tight pair) who owns the entire loop from trigger to investment. They see the arrows. They notice the dead ends. They make the hard calls about what to cut.

This person gets slower buy-in sometimes. They say no to good ideas. But they build alive things.

The Bottom Line

• Draw the loop: Flowchart, arrows, every step. Find where arrows go in but nothing comes out.
• Start smaller than you think: The mouse version might be 60% of your original scope. That’s fine. It’s better.
• Complete organism, not features: Every element connects. No island features.
• Last step creates the next trigger: Before they leave, they know why they’re coming back.
• One owner: One person sees the whole system. They make the hard calls.

Frequently Asked Questions

Doesn’t a small mouse limit our vision?

No. It focuses it. The mouse proves your core loop works. Once validated, you add features that enhance the loop, not distract from it. A working mouse with one complete game loop teaches you more about your users in a week than a year of building horse parts in isolation.

What if I’m already shipping and I have dead ends?

Map every user path right now. Find where users complete an action and have no clear next step. Those are your dead ends. Fix them by adding clear calls-to-action, unlocking the next challenge, or surfacing related content. Each dead end you close increases retention measurably.

How long does a mouse version take to build?

2–4 weeks if you’re disciplined about scope. The mouse is one core loop: one trigger, one action, one reward, one investment mechanic. Everything else is a horse feature. If your mouse takes more than a month, you’re building a pony.

Can I add more loops to the mouse version?

Only after the first loop is validated and working. Each additional loop should feed into or enhance the primary loop, not compete with it. A mouse with two working loops is more powerful than a horse with ten broken ones.

What metrics should I track for a game loop?

Loop completion rate (what percentage of users complete the full trigger-action-reward-investment cycle), loop frequency (how often they repeat it), and loop retention (do they come back for another cycle). If all three are healthy, your mouse is ready to grow.

WOULD YOU LIKE YU-KAI CHOU TO WORK WITH YOUR ORGANIZATION?