3 simple (but extremely effective) lessons I learned from game jams

The magic behind good delivery management principles when you're racing against the clock to create a game

I've been having a blast experimenting with PICO-8 recently. For those who don’t know, this is a minimalist, pixel-perfect fantasy console developed by Lexaloffle that intentionally imposes limitations on its engine, allowing designers to come up with some of the most amazing game concepts I've seen in quite a while.

PICO-8 made me fall back in love with the basics of making games. It’s been years since I actually opened an engine to prototype something, but there’s something nostalgic, almost meditative, about diving into a tiny resolution and a limited color palette to relearn what game development is really about.

These solo endeavors brought back memories. Some of them were great. Others… well, let’s just say they were educational.

I remember my first time joining the Global Game Jam, back when I was still working full-time in the games industry. We had about 30 hours to create a playable prototype based on a theme, and our team, made up of co-workers and college friends, dove headfirst into the storm of ideas. We came up with big ambitions, wild mechanics, full art pipelines. We were excited to apply everything we wanted based on the theme provided by the organizers.

The theme in question is lost in time. I can’t for the life of me remember it. However, I didn’t forget the outcome: we ended up our journey exhausted and with nothing more than a bunch of disconnected assets and a handful of bugs. No game to call our own. We didn’t even had a functional prototype.

We tried again the next year, this time eager to have something done until the end of the jam. Same energy, same level of confidence… and same outcome. A game jam with no game.

That’s when I made a bold choice: go solo. This time, though, I was decided to not fall into the same traps me and my friends fell into. I knew my limitations, so I went small and with low expectations. I used Construct 2, a visual scripting engine I was already comfortable with, and focused my efforts to make a simple platformer about a cave boy outrunning a dinossaur in an auto-scroller setup. It wasn’t anything flashy, but it was working.

By the end of the jam, it was done. Three looping stages, Game Boy-style graphics, and a modest 4-track soundtrack. Nothing remarkable, but finishing it felt like a huge win.

A year later, I went solo again. This time, I wanted to try to create a little shoot ‘em up. I used the same engine and tools I had last time to create a minimalistic game called Liber Lamb Dragonfly for mobile. Despite the new genre, I kept my limited approach, but got the same result: another micro game finished.

Eventually, I started to wonder: Why was solo development working so well for me? Was I just bad at working in teams?

I had my suspicions on what went wrong the first two times, but I was still unconvinced. To prove them, I joined another jam, this time as a floater. I offered my help as a chiptune composer for different teams who needed support, and I ended working with three groups of complete strangers to see what I could learn from them.

The outcome: 2 teams completed their games, while the one that didn’t left me with a feeling of déjà vu. They were a group of very skilled artists and programmers that were well-versed in Unity and all the other tools needed to do the job. However, they got trapped in the same inflated aspirations that my friends experienced during my initial jams.

That’s when it all clicked: the key to success was all about learning how to scope, prioritize, and execute. And that’s not only for the game itself, but to your tools and limitations as well.

These chaotic weekends taught me lessons that I’ve carried into every delivery and project management role I’ve taken on since, from corporate digital transformations to procurement rollouts and everything in between. With that in mind, today I want to share three of the biggest takeaways from those chaotic weekends that shaped the way I lead projects from that point onwards.

---

Lesson 1: Plan your planning time wisely

Game jams are a chaotic mix of adrenaline, ambition, and creative energy. But one of the most overlooked parts of the experience, and arguably one of the most crucial, is how you manage your planning time.

In my first two jams, this is exactly where we stumbled. Our team spent hours brainstorming mechanics, story ideas, art styles, UI flows, and game modes. We wanted it all: branching paths, complex sprites, layered audio... and because of that, we got none of it. We treated planning like a sacred phase that had to be “perfect” before execution begin, but perfection is the enemy of progress, especially when the clock is ticking.

What we really needed was something I learned later as a delivery manager: your planning phase should be just enough to give you direction, and no more. The goal shouldn’t be to outline the entire universe, but to set a course and start prototyping as fast as possible.

In delivery terms, it’s the difference between waterfall thinking (plan everything before you move) and agile thinking (get to the first sprint and adapt as you go). There are merits to both approaches according to the type of project you’re working on — sometimes you should even mix both for better results. However, no matter if you’re on an agile or a waterfall structure, if you’re on a high pressure situation where you need to deliver fast, you need to prioritize high-value activities early. In game jams, for example, that’s the core mechanic. In corporate projects, it might be defining your MVP or solving for key blockers first.

And it’s not just theory. Early in my career, when I transitioned from game dev to project management in a print outsourcing firm, I repeated the same mistake. I tried to map every detail of the project before kickoff. Clients got impatient, timelines stretched, and everyone’s morale dropped. I learned the hard way that overplanning delays momentum.

Today, I’ve adopted a leaner mindset: plan just enough to reduce risk and keep your team aligned, then get moving. You can adjust as you go.

Takeaway: Don’t get stuck trying to design the “perfect” project before you begin. Scope your planning to the time and resources you have, focus on the essentials, and start prototyping fast. That’s where progress (and creativity) truly begins.

---

Lesson 2: Keep It Simple, Stupid (KISS)

It’s easy to get carried away with big ideas, especially in creative environments like game jams. The first time I participated, our team had an ambitious vision that didn’t materialize into a game.

That’s why, when I finally decided to go solo, I forced myself to impose limits and work with what I had. No complex mechanics. No fancy graphics. No branching systems. Just focus on a simple goal: make a character run from left to right in an auto-scrolling game. I added a few things here and there, but each new feature was thought to be quick and easy to implement. In the end, the game was primitive, but it worked. And for the first time in my game jam journey, I had something to show.

The experience reminded me of a well-known principle in product and project design: KISS — Keep It Simple, Stupid. You don’t need to dumb things down, but you need to reduce complexity to the point where your core idea shines. This is the same mindset Shigeru Miyamoto used when designing Super Mario 64: they focused on Mario’s movement first to make the simple act of controlling him fun. The levels came after.

I later applied this strategy in my own book-writing process, and again in countless projects as a delivery manager. When building a procurement platform from scratch, for instance, we resisted the urge to over-engineer workflows or integrate too many departments upfront. Instead, we implement a solid MVP with just enough functionality to get feedback from users and we use their feedback to iterate from there.

It’s like building an onion: you start with a small, sharp core and layer complexity only when the structure can support it. If you start with the outer layers first, you’re left with a hollow, fragile shell.

Takeaway: Simplify to amplify. Start with a strong core mechanic (or project goal), prove it works, and build from there. The simpler your base, the stronger your final result.

---

Lesson 3: Use the Tools You Already Know

One of the biggest mistakes teams make in game jams (and in business overall) is trying to learn a new tool while delivering under pressure. That’s a guaranteed recipe for disaster. In my first jam, we thought, “Hey, this is the perfect time to learn Neo Axis!” Yeah… guess what? It wasn’t. We spent more time figuring out where the compile button was than actually building the game.

When I switched to solo mode, I did the opposite. I picked Construct 2 since it was a tool I already knew inside and out. I couldn’t afford the luxury of reinventing the wheel, especially regarding the game engine. The same applied to my soundtrack — I used Mixcraft, a DAW I had years of experience with. The result? Two completed games, delivered on time.

This principle applies everywhere. I’ve seen corporate projects sink because a team switched CRMs mid-implementation. I’ve seen marketing teams stall campaigns trying to learn a new analytics platform under deadline. In a past role, I helped rescue a project that nearly failed after a client insisted on using a shiny new platform no one on the team was trained in, just because it was trending on LinkedIn.

I’m not saying that you should only stick to what you’re comfortable with. You should always explore new tools and smarter ways to do your job. However, there’s a proper time for this, and being running against the clock is definitely not one of them. Keep your desire for experimentation with new engines, softwares and tools when you have buffer to spend.

Also, there’s the eternal debate of using paying softwares versus licensed ones. To that, I say you should evaluate if the investment is worthwhile and stick to what you know will help to get the job done. I paid for the Construct 2 license and that made me create 2 games plus prototype some other ideas, so it was worth for me. Sometimes you see your progress stuck because you are wasting time trying to master a free tool that is not the best for what you need to accomplish.

The truth is, paid or not, tools don’t matter nearly as much as familiarity does. When time is short, mastery of a simple tool beats clumsy use of a powerful one, every time.

Takeaway: When time is short and stakes are high, reach for what you already know. A familiar tool in a skilled hand beats a fancy tool in an uncertain one, whether you’re coding a game or launching a product.

---

To sum things up

Game jams are an exiting way to learn how to work under pressure. You are working with a limited time, under a specific theme and with a small number of resources, but having your little game done in the end is worth the effort. There’s even some great games that were born at game jams at first, and I would love to explore this theme in a future post.

That being said, I’m not making a comeback to game jams anytime soon. Not that I don’t like the idea of spending a whole weekend creating a demo, I just don’t have the same energy I did in my 20s. But the lessons I learned during those chaotic weekends have stayed with me across every industry and team I’ve worked with since.

Whether you’re launching a new product, implementing a system, or writing your first line of code, you should always focus on clarity, simplicity, and choosing your battles wisely. If you need to deliver something fast, keep in mind these three principles.

• Plan just enough to stay aligned.

• Focus on building a strong core before layering complexity.

• Stick with tools that let you create instead of just learning how to use them.

That’s why I’ve been enjoying my recent dive into PICO-8. It reminds me of those game jam days, but with even tighter constraints — and somehow, even more creativity. If you want a good antidote for the bloated AAA game market, I highly recommend checking out the Featured Carts section on their website. It’s free, and some of the most imaginative game design I’ve seen in years lives right there.

In the end, this post was my little love letter to game jams, where I learned the fine art of scoping well, working smart, and delivering something — anything — that makes you proud. That’s what game jams taught me, and I’ll carry those lessons into every “boss level” I face next.

Now, I want to hear from you. Did you guys joined a game jam recently? Is there any PICO-8 fans out there who read me? I would love to hear your experiences and share some PICO-8 recommendations with you!

In the meantime, let's keep leveling up, one boss level at a time.