Managing Production Across Multiple Game Projects with Snoozy Kazoo

Most indie studios struggle to ship one game. Snoozy Kazoo has shipped two (Turnip Boy Commits Tax Evasion and Turnip Boy Robs the Bank), is finishing two more (Hobnobbers and Turnip Boy Steals the Mail), and just announced a fifth project, Rizz Dungeon, entering production.

Six people. Multiple active projects.

How do they do it?

I sat down with Yukon, founder, producer and director at Snoozy Kazoo, to understand how they structure production across multiple games, organize their six-person team, and use milestones and pillars to keep everything on track.

What follows is a tactical guide to multi-project production. How to split teams, plan ahead, and ship consistently.

The Team Structure: Split by Project, Not Discipline

The setup: Six people total:

• Yukon (producer/director/programmer)
• Jake (audio + programming)
• Two dedicated artists
• One developer (does both programming and art)
• Projects split into two active teams

How they organize:

Team 1: Hobnobbers

• Alexis and Jake
• Focus: 3D friendship-building game
• Their first 3D project

Team 2: Rizz Dungeon + Turnip Boy Steals the Mail

• Yukon, Kiki, and Pearl
• Focus: Finishing both projects
• Plus the newly announced fifth game

The key principle: “We separate by project. Occasionally we’ll jump over and help each other. But designers and programmers on a game stick permanently to a single game.”

Teams don’t fragment by role (all artists together, all programmers together). They fragment by project. Each game has its dedicated people who own it start to finish.

Why this works:

• No context switching between projects
• Clear ownership and accountability
• One person can deeply understand their game’s needs
• Help flows between teams when needed, but it’s the exception, not the rule

The Production Evolution: From Chaos to System

Early days (Turnip Boy Commits Tax Evasion): Four people. Kanban board on Trello. Everything lived in Yukon’s brain. Communication through Discord. It worked because the team was tiny and the vision was clear.

“It was lower stakes. We could just Discord each other. The core vision was stored in my brain.”

Growth phase (Turnip Boy Robs the Bank): Studio matured. Needed real structure. Switched to Notion—it could store documentation and handle project management.

Problem: Notion gives too many controls. Too many decisions. Do you make separate boards per game? Separate databases?

“I need to focus on making games, not building this elaborate Notion hellscape.”

Current system (multiple active projects): Switched to Codecks. Team fell in love in three hours.

“I showed it to the team and they were hesitant. Three hours later, everyone was like, ‘Oh my God, this is amazing.’”

How they use it now:

• Decks organized by project
• Weekly meetings reviewing what’s in each person’s hand
• Two-week runs with effort values (10 = one week of work)
• Milestones with effort tracking to estimate completion
• Data from past work informs future estimates

“It’s really nice to see these tasks we need to finish. We can give them effort values based on past experience and make a really good estimate of when that milestone could be done.”

The Milestone System: When Things Need to Be Done

Milestones answer one question: WHEN does work need to be finished?

How they structure milestones:

With a Publisher (Robs the Bank):

Publisher helped establish milestones. Each zone became one:

1. White box (functional build)
2. Art pass (make it pretty)
3. Next zone’s white box starts while art pass happens

This worked because the programmer could get ahead while artists perfected visuals.

Without a Publisher (Current Games):

They’re figuring it out themselves. For Hobnobbers (their first 3D game), they’re doing white box and art simultaneously—harder, but they’re learning.

The breakthrough: They recently switched engines and restarted Hobnobbers because scope was too high.

“We got a little ambitious. We’re slowing down, finishing the projects we have.”

The planning process:

1. Break Down Each Milestone in Advance

For each milestone:

• Draw out the design
• List every individual asset needed
• Rip apart the zone to understand exactly what needs producing
• Do this BEFORE the milestone starts

“We have a good comprehensive list so we don’t stress ourselves out producing assets. We can get a head start now.”

2. Use Effort Values to Estimate

Based on past data, assign effort values. Track actual effort completed. Compare against estimates. Adjust future milestones.

“That allows us to see how long it took to make this chunk. Then we can estimate how long we need for the rest, and cut down if needed.”

3. Work Ahead

While building Zone 2, design Zone 3. While implementing features for one milestone, plan the next. Staggered production prevents bottlenecks.

“If five people are waiting on me, and I’m only one person, four people are gonna be waiting.”

The Pillar System: What Should Be in the Game

Pillars answer a different question: WHAT features actually belong in this game?

Milestones tell you when. Pillars tell you what.

Turnip Boy Commits Tax Evasion pillars:

1. Respect (player’s time)
2. Silly tone (everything is comedic)
3. Short experience (mirrors short development time)

How pillars work in practice

The Tangerine Dog Example

They wanted to add a dog companion in Zone 2. Ran it through the pillars:

• Would significantly increase development time (dog follows through every map)
• Game goes to space at the end—how does a dog work in space?
• Goes against “short experience” pillar

Decision: Shelved it. Added it to Robs the Bank instead.

“When you come up with ideas, run them through your pillars. Does this fit in milestones? Does this click? If not, it doesn’t make sense.”

Turnip Boy Robs the Bank pillars: Same three, but comedy became “dumb action movie”—over the top and stupid. Van crashes through wall. Everything should be ridiculous.

What went wrong without strong pillar discipline: Robs the Bank added too many new systems: destructible props, tons of guns, enemies, NPCs. Development time ballooned. Milestones scrambled. Lots of delays.

The lesson: Pillars keep you focused. Without them, you add “cool ideas” that break your timeline.

Scope Management: Stay Small or Die Trying

The ambition problem: Yukon started wanting to make indie games at 11. That ambition built Snoozy Kazoo. But unchecked ambition keeps leading them down roads where they need to pull back.

The turning point: At Spell Collective, Yukon met Dorian (Kabuto Park, Momami Lane creator). Dorian’s message: “Why are indie developers building massive things and burning themselves out and killing themselves over it?”

The new philosophy: Downscope everything. Focus on unique, small experiences. Don’t get boxed into one franchise. Make “dumb as hell games” across different genres.

• Commits Tax Evasion = Zelda-like
• Robs the Bank = Roguelite
• Hobnobbers = friendship building
• Steals the Mail = runner
• Fifth game = TBD

“We want to do a bunch of different things. Our scope needs to be small to do that.”

How they use data to control scope: Codecks shows effort completed over time. They see how long one chunk took, estimate future chunks, and cut if it’s too much.

“It allows us to see how long it took to make this chunk. We can estimate the rest and cut down if needed.”

Non-Attachment: The Philosophy That Lets You Ship Multiple Games

The problem with attachment: People get too attached to their projects. Elaborate stories. Dream games. Perfect visions. That attachment forces you to stress over details, content volume, system complexity.

“That attachment can be really unhealthy. It can lead you to stress over making sure everything’s perfect, matching your perfect vision.”

The shift: When Yukon started Turnip Boy: “I have this character. I really like this character. But I’m not going to die if this game doesn’t get made.”

Turnip Boy wasn’t the dream game. That freed them to:

• Focus on what actually needed to get done
• Cut corners strategically
• Keep scope manageable
• Actually ship

The pivot example: Originally, Turnip Boy was a traditional Zelda-like with minimal dialogue. Players responded to characters and dumb jokes. So they pivoted: added full dialogue system, cut back on Zelda mechanics, focused on comedy.

“Because I didn’t have this core vision I felt so passionately about, we were able to pivot without it being, ‘I need it to be my perfect brainchild.’”

For managing multiple projects: Non-attachment means you can:

• Kill features that don’t serve the core
• Shift resources between projects based on need
• Restart a project if scope got too big (like Hobnobbers)
• Shelve ideas for future games instead of cramming everything into one

“We really like this game, but what’s the core? What can we cut? How can we bring this to market?”

Expo Testing: What Players Actually Want

Managing multiple projects means testing efficiently. Snoozy Kazoo takes games to expos early to validate decisions fast.

What they watch for:

1. What people resonate with
2. Where people struggle (not opinions, struggle points)

Turnip Boy Commits Tax Evasion: People found the premise goofy. The name spread organically. They laughed at the giant worm boss Yukon added because he didn’t have time for a real boss.

Decision: Focus became engaging story and comedy over traditional puzzles. Simplified mechanics.

Turnip Boy Steals the Mail: Team plays Cookie Run (brutal precision platformer). Built Steals the Mail like Cookie Run. At GodotCon, players kept dying.

“They’re not here for hardcore gaming mechanics. We need to calm this down.”

Right there, Yukon reduced game speed. Made it more logistical, less brutal. Added characters mid-run for comedy. Cut levels per area, focused on story through fewer levels.

The lesson for multi-project teams: Fast feedback loops let you pivot without wasting months. Test early, adjust quickly, move on. When you’re managing multiple games, you can’t afford to guess wrong for long.

The Business Reality: Production Around Limited Capacity

Yukon’s friend Jordan Kegler: “You are not starting a game studio, you are starting a small business.”

When you’re managing multiple projects AND running a business, production must account for reality.

The capacity problem: Yukon can’t do 10 effort per week on games. Maybe five. The rest is emails, taxes, legal, random disasters.

Example: Bank account locked up in Sweden, destroyed payroll connections.

How they adapt:

• Other team members step in for code when Yukon’s handling business
• Shift focus between projects: “Go way more art right now, I’ll come back to programming later”
• Accept that business owner capacity is lower than developer capacity

“You’re a person with limited stamina. Your production needs to plan around that.”

For multi-project teams: This is even more critical. You can’t split your producer across three games at full capacity. Plan for it. Build systems that don’t require constant producer input. Empower team leads on each project.

The Biggest Multi-Project Mistake: Announcing Too Early

What happened with Hobnobbers: They wanted to announce at a specific event. Get the Steam page up. Problem: Hobnobbers was half-baked.

Focused on an impressive mural for the trailer. Team was proud, but it put them under massive strain. The game wasn’t ready to show, so they compensated with marketing materials they pushed too hard to make.

“That was an unfortunate crunch. I didn’t have data to show it would take that much time. We unrealistically promised an event we weren’t prepared for.”

The lesson for multi-project studios: When you’re managing multiple games, the temptation to announce everything is strong. Resist it.

“Announce when it’s ready. If you’re scared of what people will think, don’t announce yet. Wait. A year later your game will look totally different and you’ll have to re-announce anyways.”

Each announcement creates external pressure. Multiple announcements = multiple pressure points. Only announce what you’re confident showing.

Closing Thought: Systems Over Heroes

Snoozy Kazoo isn’t shipping multiple games because they work harder. They’re shipping because they built systems that work when individuals can’t.

Milestones tell them when. Pillars tell them what. Non-attachment lets them cut. Staggered production prevents bottlenecks. Expo testing validates fast. Effort tracking informs estimates.

No single person holds all the vision. No hero saves the day. The system carries the work forward.

As Yukon put it: “That’s my biggest thing about Codecks—you get so much data at your fingertips where you can be like, this is not working, or this is fantastic, keep up the work.”

When you’re managing multiple projects, you can’t afford to guess. You need data. You need systems. You need discipline.

Because ambition without structure just burns people out. But ambition WITH systems? That ships multiple games.

---

Woww you read all the way through! 😻👏

You now have Snoozy Kazoo’s playbook for managing multiple game projects: split by project, plan with milestones, cut with pillars, test early, stay unattached. If you want more multi-project production breakdowns, check out our YouTube channel and join our Discord.

And if you need project management that handles multiple games without the chaos, check out Codecks—the tool Snoozy Kazoo uses to track everything.