Reconciling “Minimally Viable” with Game Development

It’s hard to spend a day at HBS without overhearing someone mention the term MVP, referring to the Minimum Viable Product methodology prescribed by many entrepreneurial gurus, most famously Steve Blank and Eric Ries. Their advice is difficult to disagree with – don’t waste time and resources building a full-fledged product no one wants; instead, build a version of the product that has the minimum features required to validate the product vision and test it with potential customers. Specifically, Ries has defined the MVP as “that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.” Who wouldn’t want that? Yet, recently, every time I hear someone mention MVP, I cringe in despair. Why? Because the product my team and I are building happens to be a mobile game, and while the MVP strategy still applies, it is incredibly difficult to execute on an ongoing basis.

The entire point of building an MVP is to get early feedback from a select group of potential customers, which Blank refers to as “earlyvangelists.” These aren’t ordinary customers – they are early adopters who have the unique ability to envision the full potential of the MVP and are ready to back your product in its current state. This is a tall order for most customers, and it’s an even harder task when the product they have to evaluate is a game. Like other art forms, games are not created to solve a customer problem in the traditional sense. Instead, they are played for pleasure and are deemed successful when they create a delightful experience. With traditional productivity software, customers have an easier time imagining a cleaner, faster, sexier version of an MVP that already solves the core problem they are facing. They can look past the rough edges and evaluate the basic value proposition of the product. But with games, the sexiness is the value proposition. The basic game mechanic (often referred to as the “core loop”) can be very difficult to evaluate when it is not complemented with sounds, design and other traditionally “non-minimal” features.

While building TrivPals (we describe it as the “DrawSomething of Trivia”), it is a constant struggle to determine which features are necessary to validate our core loop. Someone on the team will offer an improvement to our current game, and very often, someone else will shoot it down citing the tyranny of the MVP mantra. We are left scratching our heads and often make an arbitrary judgment. Back in my days as a software developer in a Microsoft research lab (even dinosaurs can be agile!), our first MVP for an educational game took just two hours to make – it was a “paper prototype,” literally a collection of pieces of paper with buttons drawn on them. This was enough to gather the initial learning we needed. But the next MVP took us three months to build – our intended audience was middle schoolers, and we decided we simply couldn’t determine the educational value of our game without investing in making it fun and delightful.

So is an MVP strategy simply not applicable to game development? Definitely not. Following lean methodologies like MVP design helps avoid spectacular failures like Duke Nukem Forever, which took 14 years of development by four different studios to release a total flop in the market. There is no doubt that it is a good idea to stage development and test innovative features with potential customers regularly. But amidst all the hype, it is important to remind ourselves that there is no absolute definition of an MVP, it is defined contextually, relative to what else could eventually be done. When selecting the features for an MVP, it is important to cut the fat, but keep the essence of the product you are building. In the case of games, this means you have to be comfortable with spending a considerable amount of effort on emotion-inducing elements that a first glance seem at odds with the notion of an MVP.

1 Comment

  1. Akira Hakuta

    Hey Abhishek, I recently watched a documentary called "Indie Game" that I found really liked, and that you might find interesting. It follows different teams of independent game developers that are all trying to make the next big independent game hit. Your concerns about the difficulty of creating an MVP for gaming are touched upon in some ways in the film; in one scene, game developer Jonathan Blow shows his initial "MVP" for a game he created. He programmed the basic mechanics (the "core loop" that you mentioned) with really basic graphics as a way to test out his initial vision. Think simple outlines of a character jumping over things. I forget if Jonathan used this pared-down product as a way to get customer feedback, but the impression I got is that it was more so that he could test his own vision for the game. Once he thought he had a solid experience in the MVP of the game, he went on to fully built out all the graphical and aural nuances of the game, which went on to become a hit game for PC, Mac and Xbox called Braid. I wonder if this isn't an approach that you could emulate in your development of TrivPals- perhaps the "core loop" can be created without requiring too much polish or development time? Given that your target audience is young children, they might be less inclined to care about fancy graphics in the first place, and could still provide interesting insights into how they interact with the game.


  1. Adagio Medium - [...] key.Press End or restart the current game. Use keys ASDFGThe mouse wheel changes the sound volume.When a note hits…