Cheating Death: The 4 jobs of making enduring Live Games

The product work to make live games players love

This post is a follow-up to Make Live Games Players Love, which I would encourage you to read if you haven’t before you dive into this one. Here I continue with the loose transcript of a presentation I developed during spring ’22. Once again, the target audience for the post is game producers exploring or moving into Games As A Service. Free-To-Play developers may find the content a bit too obvious. Most of the images in the post are still slides from the deck. Somehow Medium makes the images slightly blurry even at high resolutions, making them hard to read. If you wish to have a better version, reach out to me.

In my previous post, I talked about the Search and Grow journey for Live Games. As part of it, I positioned these games as authentic Products (as opposed to more linear Projects) and in need of:

1. A Product Mindset the whole team can share, deeply rooted in our love for the player.
2. Product Management that fosters player value while creating a scalable, sustainable, and profitable business for our company.

Today, we’ll take a deeper look at the product work involved in the Search and Grow journey. This knowledge will help us understand what work styles and characteristics may align at each step to inform our talent strategy, which I will explore in an upcoming post.

While reading this post, many will wonder why doing all of this work when you can just have a game idea, develop it as you would normally do, and then consider that “the launch is just the beginning” and churn new content, season passes, and the like until it works? My answer: because you will be playing “hard mode.” In the product world, it is the equivalent of having “a solution looking for a problem.”

If you have a Live Game and your players’ curve looks like the one below, you may have a problem.

Now compare to this chart for the same period.

Both of these charts represent daily players in real service games. The one at the top comes from a studio with experienced devs with AAA background, backed by a major corporation, and the game had spent months on Early Access before a wide launch. The players’ curve has a shape that would be pretty respectable for a boxed game, but as a service, it’s a tough spot. It may or may not survive depending on how much time and cash the company can burn on steering things up to the point where it realizes its ambitions and is viable as a business.

Are players the only criteria for success? Not at all, but if we don’t have them, the rest quickly falls apart, leading to an early grave.

And so, the job becomes cheating death.

As always, we need a disclaimer when talking about these topics. We risk deluding ourselves into thinking we can follow “best practices” and predict some desired result. Product, People, and Organization are complex systems; it doesn’t work like that. All my examples are just that, examples. Things become clear in hindsight; they are not when you are in the midst of it. When dealing with complexity, we try to understand the mechanisms to manage the systems the best we can with our resources rather than looking for fireproof solutions. Each context is different, and the same inputs will create different results.

Search & Grow: The Product Work

Take a quick look at the Search & Grow journey. Our overall goal is to maximize returns while lowering risks. But what do we do to get ourselves to an enduring service?

If you don’t remember what this is, read the previous post.

Well, as the title of the post implies, I am breaking down the journey into four main jobs:

1. Explore and Envision
2. Build and Validate
3. Gain Confidence
4. Maximize Returns (Grow)

An important thing to understand before you read what comes next is that Search (1–3) is all about managing product innovation; it is not linear. It goes beyond delivering a project. I repeat myself, but this mindset shift is a crucial differentiator to what more traditional stage-gate processes have conditioned us to believe.

The worst thing we can do here is to put together a team and ask them to build on a project idea. The team will associate success with delivering a project, and we have established already that shipping, even if high-quality, is not a guarantee of success when dealing with Live Games.

Search Job 1: Explore and Envision

Maybe you can fall in love with someone by looking at their profile pictures on Tinder? I wouldn’t recommend it, and most people probably would advise you against it.

And so, if we want to fall in love with players to deliver a game they can’t refuse, we need to begin by understanding our chosen audience, their hopes, dreams, aspirations, concerns, routines, interests, and more.

If this is not your first rodeo, and you already know your player well and have a community in place, this may be easier. But don’t believe for a second that the community you have for [existing game X] will do for [new game Y] if the interests and needs you are serving are not the same, even if the players share the same demographics. There may be some overlap, but the original community could feel suspicious or even angry thinking you are “wasting precious dev resources” doing something new, and it’s not necessarily what they want from you. So think twice, and if you still want to try to draw some insights from the community, do it, but understand the bias and don’t make it your only source.

How do we choose an audience? Great question! And the answer is, “that’s part of the job!”. I am not trying to be cute; it really is something no algorithm will give you. You may want to make things easier by choosing players nobody is making games for, but I bet you will also be able to find underserved needs in mainstream players if you look well and avoid the obvious (more of this coming in a minute). One suggestion I have is that at least you make sure to choose players you genuinely want to serve. If your service takes off, you may be on a journey that lasts for years. It’s meant to be a love story, don’t get trapped in a loveless marriage.

A practical aspect to consider on this topic is whether you are exploring the right audience segment or, more precisely, the right granularity. For example, “Girls” is not a great target, “Girls 8–18yo” is still too imprecise, but “Girls 8–18yo who dream about horses” is getting closer.

But suppose you can go even more narrow. In this example, will your game appeal to girls who enjoy competition and want to race against other players and win? Or girls who wish to have a horse pet they can meet daily and have adventures with? Something else? There are many different flavors. Managing to appeal to and eventually retain at least one of these segments will help us establish a core community and make it easier for us to expand later on with a solid foundation.

We’ll need to complement this player knowledge with any insight from the market and competitors we may have around. There are plenty of market researchers around happy to sell us data, but scrappy research may also work if we are budget constrained; there are a lot of free resources. However, depending on how long it typically takes to develop our games, we must be cautious. Games with shorter cycles may get somewhere riding the trends. Others will want to remember that the road is paved with the corpses of one too many MOBA and Battle Royale games.

Don’t believe that our competition is just other games. I’ve seen way too many “competitor analysis” decks explaining Roblox, Pokemon, Minecraft, and Fortnite to me. Very few mention things like Disney+, Harry Potter books, or spending an afternoon playing ball at the park. Those are our competitors too. I am not suggesting that your game needs to replace any of those, but understanding why and how your player engages with alternative experiences can unlock new insights.

Study Jobs-To-Be-Done (JTBD) to understand this principle better. Understand what exists out there that competes with your game as we fulfill players’ functional, emotional, and social needs. I love the example of organized religion becoming disrupted by CrossFit [1]. And all those to-do list apps in the app store? Their biggest competitor is not another app; it’s pen and paper near the fridge. Knowing about and being able to think in these terms is a worthy investment for product and design teams.

I often receive the question, “but how do I figure out what experience to build?.” And well, that’s also part of the job. For a Live Game, I would say that using JTBD, particularly looking into Outcome-Driven Innovation[2], can help. It may provide an understanding of what interests are not currently satisfied or poorly satisfied for a given audience. Armed with that knowledge and partnering with game designers who can connect it to systems that fit a game experience can lead to a breakthrough.

It’s equally important to learn about our company’s vision and strategy well and ensure we explore opportunities that match those. Understanding how our company thinks about conducting business will make things easier when discussing identified opportunities, either aligning ourselves or helping us compare the “old way” with whatever we propose.

For example, Star Stable envisions a world where as many girls as possible can enjoy quality games created with their needs in mind. And so, I will not start by pitching, let’s say, a VR-only shooter game. Not because I don’t think girls would play VR shooters. Girls can play anything! But because there are already enough quality shooter games girls can choose from, it’s an overserved experience. We will also have a problem reaching “as many girls as possible” if we restrict ourselves to VR, at least with its current install base. So instead, we are better off exploring and finding underserved (or poorly served) needs and building on platforms with the best reach. In addition, we will want to explore opportunities with the best potential to become long-lived service games because those will align with our company’s expertise and preferred business model.

Ideas are cheap. Strategizing and churning documents is not enough to lower risks and establish trust. Instead, we need to validate the assumptions that made us think we are onto something good and then iterate as required.

And so, the main focus here is learning; we prototype and build things to learn. Therefore, tons of throwaway prototypes and other forms of experimentation should be the norm. The faster “whatever” we can throw together to prove or disprove a point with players. I know this move tends to confuse veteran game developers who want to create prototypes to demonstrate how the final game may play and prove the fun. But, what we are doing here is not that.

You may come to me pitching “Beyonce’s Off-Road Racing Simulator across the Gobi Desert.” It will be a smash hit and engage players for years. “My friends liked the idea, and everyone loves Beyonce! Simulators are BIG on Steam!! How can it fail!!?. Let’s prototype it.” Alright, alright, but first, tell me who the player is, what the functional, emotional, and social aspects look like, and how they will spend years playing the game. And I want some evidence. Is spending months building a detailed prototype of the experience the best way to prove the point? Probably not.

Get out, find those people you made a hypothesis about; what’s their reality? Do they want to invest their spare time in this? Get some User Research done, or do some grassroots research yourself (many entrepreneurs need to). Combine qualitative and quantitative methods. Again, this is not about convincing me with a pitch that the game will be an interesting, exciting, and fun new experience. It’s about lowering the risk when building a game around a specific interest for a particular audience with the potential to be a profitable business. You’ll have time to prototype the game later.

Eventually, we will have the evidence to say we are onto something good, and we can put together a product direction based on it. There is no 100% validation, though. There will always be risks, and we must manage them the whole time, before and after this point. And that’s why I called this “Explore and Envision” and not Product Discovery.

A note here about Discovery since it has become another loaded word over the past few years. As I see it, Discovery is a core activity, not a phase. We never stop discovering. Discovery is about managing product risks, and if we are in the business of Live Games, those exist all the time. I see teams out there adopting the practice of Product Discovery and then asking if they “are done yet” with discovering. But, again, that’s linear thinking. We are never done with Discovery, there may be times when Discovery is at the forefront and others when delivery takes the spotlight, but it’s always there. I may cover Discovery in depth in a follow-up post.

An essential part of making things easier for us, in the long run, is to figure out today if what we have has the potential to scale. There are a few strategic frameworks out there that can help. When it comes to being insightful yet easy for teams to incorporate into their work, my favorite one is the 7 Powers [3]. You can look at what you have right now and identify whether it has the characteristics that will help it become “big” in the market. Yet another topic I save for another post; I leave you with the name and a slide to explore on your own if you are curious. You may also want to explore other frameworks; the point is to ensure you continuously analyze your potential to scale to save you some trouble.

You may question how you evaluate these scaling elements if you don’t exactly know what you are doing yet, and wonder why I include 7 Powers as part of the Exploration job and not something that comes later on. My answer is that 1) you should know about these to support your design as you form new ideas, and 2) remember Search is not a linear process. It would be wise to incorporate a scaling assessment when evaluating the potential of what we got during the “Build & Validation” job and then look at these again when you are “Gaining Confidence” and figure out ways to measure the strength of each of the elements. There is no one way of using this.

One last comment about why you shouldn’t skip the kinds of action we have gone through so far. Sometimes I hear, “we don’t need this; we have an IP with massive reach,” or “we are just doing our super successful [game property] but as a service.”

And yes, you may justify some early confidence based on statements like that, but then think about how many free-to-play games based on Star Wars, Marvel, or any other Disney property come and go without making a dent. Even if you love these brands, it gets hard to distinguish all the RPG battlers, card-trading, or 3vs3 games that seem developed by following a checklist. Considering how hard it can be to steer a game once in the open, investing up-front in understanding truly underserved needs that can lead to long-lived experiences is worth our time.

Similarly, it is worth trying to anticipate how the players who loved your boxed AAA franchise may react if you drop a Live Game based on the same IP, especially if the associated business model violates the core beliefs of your existing audience. So think about whether you may be possibly serving existing players you have with an experience that is not a fit for their needs and wants. For example, see Diablo’s core player reaction to Diablo Immortal — if you are Activision, maybe you are ok with the backslash and trading community trust capital off with market expansion. However, other companies may have a more challenging time.

Search Job 2: Build and Validate

Depending on who you ask, exploring and envisioning can be great fun, but even if everything lines up, we need to be able to build the thing. Here is where those game dev skills you already have will shine when channeled in ways that recognize that we are dealing with uncertainty.

The actual “building” of the game is pretty much what you would expect. The job here is delivery, which we have probably been doing for years, but we need to contextualize the work properly. There is no single way of doing things; it depends on many particular factors, your circumstances, culture, size, and preferences. The primary advice I can offer is that you adapt your working methods to the complexity of the work in front of you. But I leave this for another post.

If we are doing anything we could consider novel (as opposed to iterating on something you have done before), I would suggest studying Lean Startup[4] and adopting some variation of it. I don’t care about what labels you use. If you want to wrap things around pre-production, production, or whatever so that it aligns with your own terminology, it is just fine. The important thing here is to not fool ourselves into thinking this is linear and believing that what matters the most is “project progress.” Because it is not.

Building products, not projects, require actions such as:

• Regularly revisiting the product direction, according to how we see players reacting to what we build. Some may frown at this as it sounds like we are compromising the game’s vision but remember, we are trying to find the experience that best matches our audience, and we are not being precious of our ideas.
• The ability to prioritize what matters most when deciding what to build next. While it sounds super obvious in theory but can be pretty tricky in practice. Choosing “what matters most” can quickly become a challenge depending on stakeholders, our team’s situation, office politics, and other factors. But it is part of the job to understand the criteria and connect the dots to figure out what you want to learn next.
• Being able to build something that players can test often if not continuously. Easier said than done but critical to perform continuous validation. It’s good to adopt a mindset in which we tell ourselves we are running a service from day one. We launch frequently. We look at a launch or release as a learning tool rather than an event. If you think three focus group tests a year are enough, you are not embracing the new reality. And if it’s hard, do it more often. Tools that can help with this have been available for years. Build that player community. Involve them in the development. Make them feel listened to and important. You may not like blockchain games, but those people are building games around communities and there are some good lessons to learn from them too. And, of course, you can even consider launching in some limited way and “build in public” (pretty much what Star Stable did ten years ago).

Whatever process you follow, it’s important to establish regular decision-making checkpoints where we inspect the learnings we get from players, rather than evaluating the progress made delivering a project, as stage-gates usually care the most about. And let’s decide what to do next:

• Are we onto something good, and we feel the level of risk in exposing more players to this is low enough? Yes? Let’s do a wider launch. Broaden the reach bit by bit.
• Are we onto something good but still have more to learn before we feel confident to take the next step? Let’s keep on this track and discuss what to learn next to lower the risk.
• Did something not work as we expected with players? Let’s make some changes in the next iteration/increment.
• Have we realized our experience is not a match for these players, but we still believe there is a market here? Let’s grab our learnings, salvage what we can, and pivot to another idea, revisit the vision.
• Have we tried enough but don’t believe there is a market anymore? Let’s stop things here and move on to other opportunities.

This process provides the ability to manage risk, particularly financial risk, which creates the most friction in management teams. If we genuinely consider what we do innovation work, we need to fund the team, not the project. And then adopt Innovation Accounting [5] or a similar mechanism.

We need to provide a runway for a team to innovate and have the freedom to find evidence that they have a value proposition and a business model that works for their players [5]. Note how it differs from greenlighting a budget to delivering on a project pitch. And this is how traditional publishing mechanisms often become an obstacle for Live Services. We need to place bets on great teams, not projects, requiring the right talent strategy to work — a topic for another day.

These frequent checkpoints are where we look at what we have and ask ourselves if we still believe in this team and their choices. If we do, and we have the player data to back it up, then let’s renew the investment. A healthier alternative to the finger-pointing, and antagonistic discourse of “oh, this team has been building something for two years, it’s Alpha, and now that we look at it, this is not what we expected.”

Another question I hear a lot: “What about vertical slices?.” By all means, do one if that’s what works for you. But I wouldn’t go dark for two years while building it. Instead, find a lifecycle that allows you to manage all the aspects I have described above, especially testing with users, validating, and managing the risks properly. I recently saw a presentation by the team behind Ghostrunner, not a live service but an encouraging example of how to integrate public player feedback (not just focus tests) into a vertical slice [6].

Still from Radosław Ratusznik’s talk, “Ghostrunner and its life cycle — production, design, and challenges.”

Search Job 3: Gain Confidence

We’ve done the homework about players and needs and built something we can now put in front of a larger audience. Are we done with Search? Can we move on? Well, no.

While I am not fond of “the launch is just the beginning” kind-of statements because, even when true, it seems to encourage developers to think the players will magically come regardless of what we do, the reality is that there is a lot of work left.

So, let’s say we are at the point where players can access our game more broadly. It may be a full-fat official launch, early access, game preview, alpha, beta, or other go-to-market execution. For us to safely invest in further growing this game, we need to find strong evidence (in priority order) that:

1. Enough players stay in the game,
2. We can make a living out of the game, hopefully in ethical ways, and
3. We can scale to our ambition level in sustainable ways for us as game makers.

Note that I am being purposely vague on what “enough players stay” or “make a living” or “ambition level” means because it will look very different depending on your circumstances. For example, we typically want to foster and increase daily engagement. But what if you are making games for kids? Are the mechanisms that create “fear of missing out” and the associated metrics something you want to drive for your product? Probably not. Same with the ambition level. What big companies consider unacceptable returns may be an excellent start for a small studio to make a living and serve their community of players for years.

This work involves experimentation, marketing, funnel management, data analysis, community management, and many other aspects. And, of course, we keep building and validating. It’s, once again, about lowering the risk. No 100% validation; it’s about getting to the level of confidence we might feel comfortable with as a company.

Here is where traditional game developers with Live Game services ambitions can learn a lot from free-to-play mobile developers. It has become standard practice for them to spend months or years in soft launch, optimizing, and trying to figure out whether the game will make it in their (extremely competitive) mobile market. Yes, some Live Games on PC/Console also do extended Game Previews or Early Access. However, this step is sometimes used as a way to fund the game’s development, bug fix before a full launch, or, in worst cases, just a checkbox in a stage-gate process. Instead, it should be seen as an opportunity to observe our audience, iterate, and critically assess if we want to support this game in the long run.

Search is not a linear process

I mentioned it already, but I thought it was worth reiterating this because reading this post so far may give you the impression that we are following a linear process. First, we “Explore and Envision,” then we “Build and Validate,” and then we “Gain Confidence.” But in reality, creating products is not linear. We may find ourselves missing the mark along the way, taking a step back, and trying something else.

It is OK to go back to move forward.

Fun fact: This (busy) slide has 21 animations in the original deck.

When we mentally connect success to the delivery progress, taking a step back might be seen as a setback. It’s a very human way to think. But pushing forward for the sake of progress with a game service that may struggle for months or years doesn’t sound necessarily a great approach.

The best organizations encourage their teams to make (or at least contribute toward) the decision to heavily alter or even discontinue a game that we can’t find convincing evidence can reach the agreed-upon ambition level.

Because of this need for back and forth, flexibility becomes an essential tool, way more important than perfection, which is the default mindset of AAA developers. Think about Fortnite. It’s not like they set the world on fire with their launch tower-defense shooter. But it took them about two months to come back with a very different Battle Royale offering that was a better match for what the market demanded.

Grow: Maximizing Returns

Congratulations, we made it to the Grow side of the journey. We fully trust that we have a game we want to continue investing in, that promises to become a profitable long-term business for our company.

The product work we do here maximizes the returns from the service while navigating existential threats. We cannot predict all swings in the market, so what we will do is a combination of proactive and reactive work, such as:

• Continue optimizing the business side of things, analyzing, measuring funnels, listening, and learning. We will find ways to expand the player base for the existing service, growing value for the company.
• Expanding on proven experiences that we know resonate strongly with players. The more reliably and predictably we can serve players, the better.
• Expanding into new types of experiences. The existing offering won’t stay fresh forever. Product-Market Fit is ephemeral.
• Growing our ability to efficiently take action based on what we see in the game to sustain and improve (through experimentation) engagement, retention, and monetization.

The “how” we do all this depends on what works best for your type of game, your company, your team, and, more importantly, your players. DLCs, Free-To-Play, Freemium, Paid base with expansions, Season Pass, In-App Purchases, Gachas, Subscriptions, Live Ops, and just some of the tools that may or may not fit your audience. Doing the job during Search should have given you confidence in what works, but at this stage, you can experiment, tweak, add, and remove, all in the name of optimizing.

Note how adding new functionality will also unlock the potential to reach new audiences. We will want to aim for adjacent players and increase the reach progressively rather than disrupting the existing player base.

Find audiences that might be interested in your game but are missing something to invest themselves in it fully. Then, figure out what that something may be and build it. If you keep doing this for a while, you can go beyond the game and find opportunities to serve your audience in other ways. For example, Star Stable has a book, music, and animation offering parallel to the MMO game.

This kind of strategy aligns with what I think is the aspiration of every service product — to go from selling a product to a player to satisfying the core needs of an entire audience segment.

And when you think about it, we will essentially repeat the Search cycle at a smaller scale for new features, which is why I believe working on this kind of new development is a great incubator for innovation teams, as we will see in the next part of this series.

I want to wrap up by acknowledging that we do much more to grow and sustain a Live Game.

What took us here is often messy by design — prioritizing flexibility and momentum sometimes means debt in the codebase, easy-to-modify yet suboptimal pipelines, a few hacks here and there, single points of failure, heroes, and possibly a reliance on tribal knowledge. For those out there with knowledge of Wardley’s evolution stages[7], we go from Genesis to Product. If we intend to run a service for years and years, we need to work on building resilience. Otherwise, you will be more reactive than proactive, firefighting all the time.

Predictability means, in many cases, creating redundancy, changing mindsets, managing knowledge properly, exploring ways of becoming cost-effective, and more. Teams will grow and create new challenges. The illusion we can have something stable is just that, an illusion. We don’t “solve” complexity; we “manage” it the best we can.

What’s Next?

People, and how talent connects to all this work will be the main topic of the next part. You can’t have a great product without the right people.

I will continue using the “Make Live Games players love” deck as a guideline; I promise it’s almost over!

As always, thanks for reading, and reach out if you want to discuss any of this!

Thanks to the early readers for this post, Jose Paredes, Doanna Neville, David Hontecillas, and Mayara Fortin — you make my writing better!

References

[1] Read more about how Church and CrossFit compete in the article “Can Innovation Get You Into Heaven?“ by Chris Spiek — link

[2] There are many resources on JTBD/ODI in Tony Ulwick’s body of work. His post “Market Segmentation Through a Jobs-To-Be-Done Lens” is a good reference on this particular point — link

[3] “7 Powers” by Hamilton Helmer (Deep Strategy 2016)

[4] and [5] “The Lean Startup” by Eric Ries (Random House, 2011)

[6] “Ghostrunner and its life cycle — production, design, and challenges” by Radosław Ratusznik— link

[7] Wardley Maps’ material is open sourced by Simon Wardley. An intro here.

Image References in order of appearance:

[1] and [2] Screenshots taken from Gamecharts.org. Details have been removed intentionally.

[3] Max Von Sydow and Bengt Ekerot in a movie still from “The Seventh Seal” by Ingmar Bergman (Svensk Filmindustri, 1957)

[4] Church photo by Debby Hudson on Unsplash. CrossFit photo by Bastien Plu on Unsplash

[5] Rocket comic panel from Tintin’s “Explorers on the Moon” by Hérge (Casterman, 1954)

[6] Tom Hanks in a movie still from “The Money Pit” by Richard Benjamin (Universal, 1986)

All images are copyright to their respective owners.