What To Prioritize In Game Development

Read Time: 5 Minutes

I teach a class called "Reframing Agility." We spend some time looking at different mindsets, types of work, and approaches to delivering value. We go into some detail looking at when value is achieved in strict plan-driven vs value-driven approaches to game development. 

There's a slide in there that always bothers me a little because of how optimistic it is. It's for training purposes so keeping it simple makes sense, but it still feels a little deceptive. 

Here’s a sketch of the slide:

On the left you have the classical “waterfall” approach to work. People often build buildings this way. You plan everything out, then assemble your materials and put everything together following the plan. The 'product' does not begin producing value until every step is done. Only then can people move in and start using it.

On the right you have the iterative, incremental approach. This is typically a much better way to build games and software. You focus on delivering a small but complete piece of value, focusing on the biggest chunks first. This allows some value to be delivered well before the deadline. When developing products such as games with many possible features, this can get you in front of players way faster.

Let’s be honest: we tend to know less than we think we do and we tend to require creativity more often than we think we will. 

Case in point, I don’t doubt that many of you have heard someone say, "We know what we need to do, we just need to go do it." 

I can hardly think of a product I've worked on where that hasn’t been said at some point. And you know what? Most of the time it’s been wrong, leading to a lot of bad assumptions being baked into the game or tech. 

We need to prioritize in a way that acknowledges we don’t know everything up front. 

The Problem

So what’s my issue with the graphs? Well, the simple curve of the “value first” slide doesn’t solve us making bad assumptions. The “Value-driven Model” curve assumes we know what is most valuable and can build it right away. That’s - at best! - questionable and at worst completely contradictory to the value-driven approach itself. It’s skipping the power of iteration: learning.

This poor assumption is one of the most common mistakes organizations make, even for teams operating within “agile” frameworks. We like the iterative thing, but we hate the uncertainty of not knowing exactly what value our game is hoping to create. We want to know up front, so that we can do the most valuable work first. So we pretend we do know and then lay out a path of the “most valuable work” to do in order. It’s a fiction.

Down the road, we’re stuck on that unchanging path, having left the idea of value behind. After all, “we talked about value in planning!” Meanwhile the path is twisting. Soon we're not moving towards the goal. We may not even remember what it was. Worst of all, our game isn’t getting better.

Iterative development isn't just about working in cycles. You must recognize that when you start creating a game you don't know exactly what you want. Sometimes, you’re not even close to knowing. If you have not made learning safe, normal, and encouraged, you will appear to do the right process stuff without getting any of the benefit.

To get the most out of game dev, acknowledge what you don’t know.

I’ll admit, you do know some stuff. You have a vision and a player need you are trying to meet, and presumably some goal behind that for your company. But you don't know what satisfying that player looks like yet. 

What you think or assume will meet that need is off to some degree. Your audience is always changing, the technology is always changing, and the circumstances are always changing. This means that even if you recently built a similar game that you think you just need to recreate, it’s likely that a changing context means you are going to hit some important discoveries between starting work and reaching the value.

The Importance of Learning

So what do you do? If I don't know what’s valuable up front, how do I prioritize? 

I'm super glad you asked. 

Early on, you should prioritize things that teach you what will be most valuable.

Focus on learning when the work is more uncertain.

Getting something completely inadequate but playable in front of real players is a great first step.

Here's a stab at what I think the learning line probably looks like. And yep. It’s the original (and inaccurate) value graph, but I think it works just fine for learning.

Note that you do eventually start running out of relevant and important things to learn. Your rate of learning decreases over time. That’s normal. While you never stop learning completely, your focus will shift towards delivering the value you've learned about. How you prioritize will shift from the start of your project to the end, and that is totally ok.

Focusing on learning allows you to get an “S-curve” of value instead of a pretty flat line because you followed poor assumptions.

Prioritizing Learning and Value

It can feel weird to pause and go, "What don't we know?" when we spend so much time thinking about the game and experience and value we’re hoping to create. 

This is especially true in a world moving fast with harsh deadlines and money being tight and pressure coming from everywhere to get stuff done. Focusing on anything but urgent delivery of SOMETHING can seem like madness. 

But asking that question is how you get to the best player experience the fastest.

If I combine my learning and value graphs, here's what I think you’ll see when you are developing a product and focusing on both learning and value.

You focus that effort on learning early, and as that pays off, you start getting a better idea of what value you could deliver. Over the course of product development, you focus your effort less and less on learning and more and more on value.

For people responsible for prioritization, thinking about learning and value as important will help you make better decisions. 

Do not ignore learning. Avoid blindly focusing on what you know and what you thought up front would be valuable. Experienced and talented professionals get these things wrong constantly in the business world, and you are no exception!

To Summarize

When you are developing products, think about what you know and what you don’t. Recognize that there is probably a lot more in that 'unknown' bucket than you want to believe. 

A few things to do:

• Define the big questions that need answers when you start.

• Ask your team what you don’t know that may cause you to trip as you develop your game.

• Prioritize work that leads to learning more about your game early on.

• Be humble about your assumptions. 

If you do this well, you'll be equipped to deliver the valuable experiences that your audience is looking for, and that will help you achieve the goals of your game and studio.

In game dev, start with learning.

Whenever you’re ready, here’s 3 ways we can help you…

—>For a course on being a better game producer, check out “Succeeding in Game Production” HERE.

—>For regular deep dives on critical game development topics, head to BBG podcast

—>I’ve helped game studios save a ton of money & time through building clear vision and leveling up leadership. If you’d like to work with me, please reach out at [email protected].