What if I’m not solving a problem?

Giff Constable games, social games, startups

A lot of customer development language revolves around ensuring that you are solving a real problem, and the right problem.

But what if you aren’t solving a problem?

Lean startup principles still apply to games and entertainment apps. You have the same things to validate: user experience and an understanding of your value, who your customers are (and when certain types adopt), user acquisition, market size, and business model. You can still treat your efforts as experiments.

With an entertainment experience like a game, your initial focus should be validating fun.

You won’t get that from interviews. You validate fun by testing your game.

You *can* learn a lot from interviews. A great game designer studies fun. She plays tons of games, reads the theory, investigates who plays what games, and tries to understand why certain games are winners or losers. But even great, thoughtful designers come up with lousy games.

Where teams go wrong is not realizing that digital games can indeed be tested early.

Paper testing is a critical tool. This is a natural fit for puzzle and board games, but sometimes less-obvious games can be paper tested with a little creativity. It is worth a shot, and usually faster and cheaper than writing software.

Great teams don’t just paper test internally. They get out of their own heads and watch how other people interact with the motivation loops, with the story, and with other players.

Some games are really hard to paper test. Some things do require non-trivial MVPs. World of Warcraft, for example, would be very challenging. But you don’t need all of WoW to know whether you have something good. You wouldn’t need multiple game areas, high visual quality, the full economy, full character powers, a leveling system, or countless other capabilities. All of those features could be added once the root experience was proven to be fun.

And games, just like any other application, should use a mixture of qualitative and quantitative testing to understand user experience and measure progress as changes are implemented. For qualitative, I am referring more to guided observation of actual game play rather than interviews.

The truth about MVPs is that most people think they need a bigger MVP than they actually do. Another classic mistake is that people get caught up thinking about digital product, and they fail to think creatively about analog tests or tests that don’t revolve around *features*.

For your game, think about the smallest unit of fun.

Final thoughts:
With software, there is going to be one core experience or value that captivates your early adopters. You don’t always know what it will be going in, but you want to find it. More features is rarely the answer. It doesn’t matter what you are creating — don’t build a mansion until you have confidence in a great foundation.