Gamasutra: The Art & Business of Making Gamesspacer
Making Lean Startup Tactics Work for Games
View All     RSS
October 22, 2014
arrowPress Releases
October 22, 2014
PR Newswire
View All

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

Making Lean Startup Tactics Work for Games

April 17, 2012 Article Start Page 1 of 3 Next

If you're involved in the startup community or even just follow Hacker News, there's a pretty good chance that you've heard about "lean startups" or the "lean startup method." In his bestselling book, The Lean Startup, Eric Ries outlines a framework for small, innovative teams to more efficiently find product/market fit for new products. At its core is a focus on evaluating product design decisions based on user data gathered from scientific experiments. Eric argues that by making "validated learning" your key goal, you shortcut your time to building a wildly successful mass market product.

I recently finished Eric's book, and what struck me was how many of the same principles could be applied to game companies. Eric Ries pioneered the "Lean Startup" method while at a game company, IMVU, yet many people that I've talked to in the game industry feel like this model is more applicable to "startups" than game companies.

I disagree: the product design decisions of a startup mirror the game design decisions of a game company, and both startups and modern game companies use customer analytics to drive their decisions.

There is no reason why game devs shouldn't strive to make games more cheaply, and that can be accomplished by incorporating the Lean Startup method into their production process. I've spoken to many developers who are trying it right now.

So what would a "Lean Game Development" process look like? How can game developers adopt the Lean Startup model to be more appropriate for building a game?

Minimum Viable Game

In The Lean Startup, a minimum viable product is the bare minimum that you need to build in order to test the assumptions of your business. A minimum viable game is similar: you need to build the bare minimum game experience necessary to prove that people find your core game mechanic engaging. What this looks like is going to depend on the type of game that you're creating and what game mechanic you want to test.

So what goes into a minimum viable game?

In order to test the core gameplay mechanic of your game, you need to do less work and spend less money than you think. You just need to build out the first level of the game, which will provide the framework for the experiment and give you valuable feedback on your initial onboarding process. Building this first level should be done as cheaply and quickly as possible so that you can start learning immediately. Here's some tips for staying lean when building your MVG:

Use existing code. To quote Raph Koster, "there must be a 95 percent overlap in what the code does between all FPSes, but somehow FPS developers have giant programming teams."

There's no need for you to fall into the same trap. Use github, open source projects and other resources to cobble together the basic facets of your game quickly and for free. This also gives you valuable perspective on how the system will work together and what parts you need to code yourself later.

Use very basic art and sound. There are great resources out there for free game art, unit sprites, and game sounds that you can use until you get your own IP. You can also get enough art for your first level by doing a small contract with artists that you already know, or reaching out to new ones on artist communities or /r/gamedevclassifieds.

Only include the necessary features. If the feature you're building isn't required for the player to run the game and complete the experiment, then you don't need it. Don't build a save game system, variable graphics settings, or even a starting menu into your MVG. Each of these features wastes your time, increases the number of things that can break, and doesn't contribute to your core goal. Just put the level online and let players have at it.

Article Start Page 1 of 3 Next

Related Jobs

Nexon America, Inc.
Nexon America, Inc. — El Segundo, California, United States

Localization Coordinator
Petroglyph Games
Petroglyph Games — Las Vegas, Nevada, United States

DeNA Studios Canada
DeNA Studios Canada — Vancouver, British Columbia, Canada

Analytical Game Designer
Xsolla — Sherman Oaks, California, United States

Senior Business Development Manager


Morgan Ramsay
profile image
Why are you distinguishing between startups and video-game companies, and between video games and consumer products? Every game developer and publisher, from Electronic Arts to Appy Entertainment, was a startup at the earliest stage in their corporate life cycles, and every video game is a consumer product.

Betable Blog
profile image
Fair point. I think the distinction is that with video games, you inherently lean towards not shipping a product "until it's done" because you believe that the game will only succeed when players get the full experience. While this was true for AAA and $50-per-box titles, it doesn't have to be true in today's web and mobile deployment environments.

Game designers need to "let go" of the experience a little bit to use this method, but it can yield huge benefits with significantly less work if done correctly.

Wendelin Reich
profile image
@Morgan. To quote Eric Ries, "A startup is a human institution designed to create a new product or service under conditions of extreme uncertainty." This definition is actually very good and precise, and it implies that startups can happen anywhere - even in big old companies or in government bureaucracies.
An established video-game company is not a startup, but a team within that company can act like a startup if it launches a new, uncertain kind of product. Tyler is dead-on with his idea of a "minimum viable game"!

Betable Blog
profile image
Thanks Wendelin!

Joel Nystrom
profile image
Just pointing out some stark differences between two recent Gamasutra articles:

Tyler York:
"Metrics should always be quantitative, because only hard data can give you the definitive answer that you need to make tough decisions"

Koichi Hayashida:
"What we try to rely on is more of that objective feedback that we can see in the expressions on people's faces as they're playing our games"

Betable Blog
profile image
Quantitative vs. Qualitative is a debate that will always exist. I think there's multiple advantages to pursuing quantitative data in the methods that I've outlined here:

1) You can test anonymously. This means players who will never meet you and have no idea who you will test your game. This leads to the most honest, direct feedback. Good testers will still give good feedback to friends, but often times they will soften the blow because they're talking to you in person.

2) You can test on demand. Any time you need testers, just fire up Facebook Ads or Google Adwords and you'll have as many users as you want, from all over the world. Scheduling user tests is very time consuming.

3) Data ends arguments. Often times in game development, two people key to the game's design will have a fundamental disagreement about the correct course of action. Qualitatively, there are likely merits to both approaches. However, if one feature iteration performed significantly better than the other in user testing, that ends the argument.

Don't get me wrong, there will always be a place for qualitative testing. But I think there are some pretty serious limitations to it, especially at scale.

Kenneth Blaney
profile image
Tyler, data only ends arguments if your data actually measures what is important. If you don't seek to continuously refine your quantitative methods based on qualitative feedback, you're probably missing something important.

Graham McAllister
profile image
I think it's great that you're trying to get feedback from people who are not friends and family. However, by saying that metrics should always be quantitative it sounds like you're only interested in the more simple issues (time taken, deaths, objects most used etc).

By not analysing qualitative measures you're missing out on the most important factor of all, the player experience.

Betable Blog
profile image
That's a fair point. I think both are valid methods of feedback and I wasn't trying to rule anything out. Also, in the article I mention that you can get really good feedback from your early beta testers if you've already built a connection with them on forums or chat rooms.

Aaron San Filippo
profile image
I agree that it's important to pursue both approaches. I'm a huge fan of quantitative data - but nothing replaces giving someone an iPad or a controller and just watching them play. I *always* learn things from those one-on-one sessions that the data won't show.

And sometimes, you can drive yourself crazy trying to get just the right stats, when it's easier just to watch a few people play.

Ted Brown
profile image
The only drawback to this method, IMHO, is the fear of exposing a product to the market before it's ready. Anecdotally speaking, a game released "too soon" is effectively DOA, with resuscitation unlikely.

Betable Blog
profile image
I agree with your point that games, especially those on mature platforms like Facebook, HAVE to be finished on release.

My counter to the prototype argument would be that you can launch the game as a MVG in an unbranded, low-fi way that wouldn't jeopardize your actual game's launch. Instead, you'd just have a crappy game that people would test, and then you'd kill it and launch the new game without any association to the test game at all.

Brandon Van Every
profile image
Not as far as Minecraft Alpha was concerned. Looked like a POS.

Kenneth Blaney
profile image
A minimum shippable product isn't necessary, in most cases, to test the fun of a game concept. Take, for instance, the development of Mario 64. It was quite a gamble to do something completely untested (the 3D platformer) and so the developers had to make sure it could work. Moving through a space had to be fun. So, the first area they built was the courtyard of the castle which was later used for the entrance to Boo's Mansion (not the first level I'll remind you). Their they worked out the jump mechanics of Mario in 3D and established the highly acrobatic nature of his motions that would be seen in the final game not found in previous games (such, the triple jump, the duck/backflip and the tree handstand). The rest of the game was then built around these proven fun movement mechanics.

The advice of "make something fun first" then design the game around that proven fun mechanic is really good advice. Otherwise the game could end up as a mess with completely superfluous items and abilities... or worse, you will end up with a full, ready to be shipped game that is fundamentally broken and inconsistent. A prime example of this is "Enter The Matrix" where the fun of bullet-fu shooting and wire stunt martial-arting your way through a bunch of military and police is undercut by the radically inconsistent presentation and singularly over powered techniques.

Betable Blog
profile image
Yes, this is exactly right :). This is what I'm advocating here.

And also on a side note, Enter The Matrix was a seriously disappointing game. I had such high hopes for it but it was garbage (anyone remember the driving mechanics? Oi).

Kenneth Blaney
profile image
The courtyard of Mario 64 is not a minimum viable product. Maybe I'm just getting fussy over semantics, but a small, completely enclosed area with a handful of things to interact with and absolutely no goal or end point (not even enough room for a player chosen one) is not a "viable".

Add some collectibles, some enemies and then a timer for each (so players can race to see who can kill all the enemies/get the collectibles fastest) and you have something a little closer to a minimum viable product. That said, for Mario 64 a minimum viable product would have to have 2 levels connected to a hub level, each with 2 or 3 goals. That gets across all of the major aspects of the larger game: Move around, explore and fight enemies in a 3D space; Play levels to earn stars to open up new levels; Levels can change when they are replayed to earn even more stars. Remove anything and you lose a core mechanic of Mario 64.

A set of tires isn't a minimum viable car, the courtyard of Mario 64 isn't a minimum viable game.

Paul Laroquod
profile image
How do I apply this to a narrative game or a text mechanic? When the mechanic is the story, it's very difficult to have people test a 'minimum viable' version, because people judge stories by their language and trappings, not by their core mechanics. Besides, they'll be spoiled for the 'real' game. I genuinely wish that I could apply the lean startup model to story games and get them up off the ground much more quickly, but I just don't see how it could be workable. You have to be prepared to toil in obscurity with little to show for it for a long time in order to create a truly great story game that is likely to impress anybody; and then after all that effort, you still only get one shot to impress any human being with a story, so pick your moment well, and that means, don't do a lean startup.

I think the 'lean startup' advice is really only applicable to sandbox/RPG or twitch-style games, which are admittedly in ascendance, but do we want to uphold a development model as an ideal when it only really applies to a few subgenres?

Raph Koster
profile image
Narrative industries do this all the time. In writing, you have query letters and outlines (horizontal slices) and three sample chapters (vertical). In film you have screenplays and test footage and table read throughs, etc. in theater you go through workshops -- the current Tv show "Smash" is a great example of how a minimum viable process works on Broadway.

I think all the same techniques would apply for narrative games. Vertical slices are common in the development of AAA story-driven blockbusters... If anything they don't do enough horizontal slices.

Betable Blog
profile image
Raph nailed it. Check out the piece on Vertical Slices towards the end. It's a great way of doing a narrowly-defined by complete experience as a means of testing out your concept. If you've released a vertical slice and have players clamoring for more content, then you know your story has legs.

tony oakden
profile image
I disagree that you advocating making a horizontal slice. In fact I think what you are suggesting is developers make only part of a horizontal slice. A complete horizontal slice would be the entire game, with all levels but using much simplified graphics , sounds, animations etc. You don't need that to test the game is fun. A vertical slice is supposed to be a few minutes of game play which demonstrates as accurately as possible what the finished game will be like. I think in an idea world developers would start of with the playable prototype you describe, then if it's successful, develop both vertical and horizontal slices to demonstrate both what the finished product will look like and how all the levels and what not will fit together. The two together form a sort of cross if you like which define both the breadth and scope of the game without requiring all of it to be made. Then in production all the extra stuff is made to fill out the missing quadrants. In the real world developers don't do this because (puts his cynic hat on...):A horizontal slice is not very nice to look at so has very little value in persuading upper management/publisher to continue putting money into a productA vertical slice requires a very large part of the game play systems to be in place in order to effectively demonstrate how the game will play and therefore tends to end up just being a pretty graphics/art demo.Having said that for my next Android product I intend to release the absolute minimum game first, gauge user response, then if it looks promising start fleshing it out with extra levels etc. Seems pretty obvious though in hindsight...

Betable Blog
profile image
Thanks for the feedback Tony, I agree with you.

Aaron Casillas
profile image
What this really boils down to is using our audience as testers, getting the data and iterating...testing is nothing new to the game industry...However, this type of testing has a problem, if you are 1st party do you allow your device to be inundated with a sea of experimental or 1% applications? This not only hurts the perception of quality control to the 1st party, but hurts fellow developers as their products are drowned in a sea of apps. In a business were velocity to the top of the charts can partially equate to the volume of users, we are killing ourselves and our brethren.If I was 1st party, I would create a program specifically for these types of expriments, were the consumer can come in play and you can get your data....Or hire a game designer that knows what he/she is doing...after all the designer is the audience...

Michael Joseph
profile image
How would one create the minimum viable song, novel, poem, painting?

This aritlce seems to be for the "games are just products for making money crowd." And "Who needs a passionate and competant designer when you can design by a committee of metrics? "

Don't get me wrong... i think players/testers/focus groups have their purpose in terms of helping tweak and polish a design... but you have to start with someone who has a vision I would hope.

When it comes to running a lean startup, it almost sounds like you're describing an atmosphere where the actual game concept is irrelevant and that it's the process that is the most important thing.

I can't conceive of how someone forms a start up without a clear idea for a game. And I suspect it's relatively rare (not impossible) that a company is founded on the basis of a game idea that turns into something radically different due to feedback.

Now itterative game development.. that makes a lot of sense (more project management oriented and not project design oriented although design benefits from good management). Get your core game playable as fast as you can and then itterate and that's not new. But that sounds substantially different than this notion of "lean startup tatics." That sounds like a mixing of business and design.

Laurence Nairne
profile image
I know it's over a year late and you may have stumbled on this yourself by now, but I just thought I'd put my two cents in.

Lean startup isn't trying to dictate the design of your game to you through metrics. What it's there to do is tell you what you can expect from your user base. You, the game developer will decide on what market you are targeting, so then data will - likely - come from that crowd. The point of getting data at that early stage is to get an idea of how your game will survive on release. Not only this, but it also helps gain substance with your target market before it's even available.

The difference between Agile and Lean isn't the iterative nature of it, as the two converge at several points. The difference lies with the business focus of testing with Lean and the developer focus of testing with Agile. Neither deny the importance of the other, and it makes sense to combine the two areas.

Though it sounds like a soulless crapfest to just push out an unfinished product, it makes sense if you want to get a reaction from your market. And there's little new about any methodology really. I imagine some of the pioneers of methodologies didn't ever get a mention, as some just had the sense to work different from the status quo, but they become a framework when they gain momentum :)

Randy Angle
profile image
It is very important to remember that MVP, or as Tyler puts it MVG, is a term used in the agile development of game as a service - typically a web or mobile free-to-play game. The term used for classic retail style games is "proof-of-concept" and is generally the first milestone after pre-production is finished, or if the production time is long enough: during pre-production. When a MVP is released you know that it will have continued development honing the game into a success based on the feedback of actual users in the wild. Modern games are never quite finished, but they can be viable, successful, or dying. The finished state is when a game dies because it was deemed not viable for further investment.

Curtiss Murphy
profile image
Jim Collins called this, 'Bullets, Then Canonballs'. That's how great companies do it.

Course, I'm not great yet, so here's my goal: iterate early; iterate fast; iterate often! I've done products in 4 months, 8 weeks, and 2 weeks. And, recently, I started doing weekend-prototypes. The best lesson I learned is: MORE products is better than a PERFECT product.

Nice article. A bit focused on statistics, but that's a nice looking game. Thanks for sharing!