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.