‘Failing Fast’ has become the new buzzterm in game development. It’s popular because it is easy to point at examples of where it succeeded. Game design isn’t a science yet, it still requires a lot of fumbling around in the dark until the team randomly bumps up against a nugget of fun. And so the more dimensions a team is allowed to flail through, the better chances they are to smash into value. It’s like a spelunking trip where the group will only take the one path decided when they were on the surface versus careful exploration. It’s the difference between a safari at Animal Kingdom and a safari on the Serengeti.
Designers like the idea of being able to better harness their creativity. Anyone that says they can design a great game on paper, throw it over the wall to some engineers and watch it blossom is an idiot or a liar. So the idea of getting new ideas running fast to understand them and to prove to other parties things work is very attractive.
The business-side people like the idea of not having to throw resources at a dead-end problem. They don’t have to invest $100 million on a project that may or may not be good. So if the team has to fail, they’d rather it be failing cheaply.
But the problems occur when neither side really wants to fail fast.
Designers don’t want to fail fast because they have impenetrable egos. Their ideas are always great. If they are failing now, it is because it hasn’t been given enough attention. Just give it time. Give it more resources. Don’t fail so fast. It’s a lot more work to take an idea that is 10% there and bring it to 90% there than it is to create a 10% idea from scratch. A 10% idea can be vague, but a 90% idea has to be crystal clear.
Additionally, designers don’t want to be responsible for failed ideas. They’ll get bad looks from engineers. They won’t be trusted with big features or get promotions if their ideas fail. So they’d rather do things the old-fashioned way: fail slowly and then rationalize. “Well, it was more complicated than we hoped. Players just don’t understand the idea. Marketing didn’t sell it right. QA was being lazy.” And so on. Big failures are too complicated to be any one designer’s fault.
But business-side people don’t want to fail either. Failing costs money. Why would you plan to fail? After all, nothing has to fail: “Yeah, that feature isn’t really good, but let’s just ship it anyway since we did all that work.” And failure is very hard to explain to your publisher or your higher-up bosses. Winners get results. Losers fail.
And it’s easy to not fail: simply don’t take risks. Sit around and discuss what your game or feature or idea could possibly be for weeks and months. Talking about doing something risky is much cheaper than actually doing something risky. Sitting on your thumbs until it is too late to take risks is a popular passive-aggressive tactic among those who would love to take risks but balk when they look over the edge of the Abyss. They aren’t bad people. They are just in the wrong business.
So you need to find designers and business people who value succeeding far more than they value not failing for this mantra to work. You also need a team that values learning from their mistakes and humility over avoiding blame. And we are out there. But it only takes one weak link in your decision-making chain for the process to devolve. Everyone has to be on board.
There’s a time and place for both. I don’t think you have to take big risks to succeed. There’s something to be said about risk management and safety. For some groups, the tools simply are not there to do the same kind of prototyping and iteration that other teams find endemic to the design process. But remember safety comes at a cost. You can not truly innovate, you cannot count on growing market share and you cannot expect your creative people to be sustained forever on a policy of risk evasion.