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