Sunday, July 14, 2013

Kickstarter and Feature Creep


An example of feature creep (by James Provost)
The current buzz in game dev circles is about the Double Fine Adventure launched on Kickstarter 18 months ago.

To make a long story short:
1) Development team goes on Kickstarter to raise $400K
2) No stretch goals were specified.
3) They raised more than $3.3 million.
4) Nine months after the "Estimated delivery" date, there is no game.
5) Uproar has ensued.
I can see while people are angry. If you don't deliver a crowd-funded project because the lead designer gets hit by a bus, that's understandable. But if it's because you have too much money, that looks really unprofessional to an outside observer.

I have some comments, but please note that I am not criticizing Tim Schafer and the Double Fine team. The game industry has people that are actually evil and I see no evidence that Double Fine has done anything immoral or intended to do anything immoral. I'm not a backer and I'm not in their shoes. Nevertheless, I am taking a moment to talk about another team's project because:

1) I believe that crowd-funding will, and should, play a major role in the future of game development.
2) The crowd-funding paradigm is still young, and we need to discuss and clarify what backers should expect from developers.
3) Feature creep is, in my experience, the single greatest enemy to successful game development.

The Pressure of Feature Creep

The Double Fine team expanded the scope of their project in an attempt to have the magnitude of the project match the magnitude of the funding level. As the scope of a project increases linearly, the complexity of the project tends to increase exponentially. Therefore, it's no surprise that the project slipped past the completion date that they originally promised, despite having much more money to work with.

Based on the high funding level, I can understand the extreme pressure felt to add features not originally specified (aka "feature creep"). To say that I "understand" is an understatement. I can viscerally feel the pressure just by looking at the funding level. Game designers always want to add as much as we can, and we want to deliver everything that the consumer expects, and more. So when I see that funding level, I feel the pressure of higher expectations, in my gut, even though I have nothing to do with the project.

However, I have felt the pressure of feature creep many times before, and I have gotten better and better at resisting it as I have gained experience in this industry. I have also gotten better at justifying such resistance to management, publishers and customers. My sanity and happiness have increased in direct proportion to my ability to resist feature creep.

Backer Expectations

In my opinion, the decision about whether or not to succumb to feature creep in this situation should be guided by the expectations of the project's backers. They are the ones "buying" the product, and they are the ones to whom you have promised to deliver a specified project on a specified timeline.

I have supported Kickstarter projects in the past, and I have never had an expectation that the scope of a project would increase if the funding exceeded expectations (unless this is explicitly specified with stretch goals). For me personally, I wouldn't have gotten mad if Double Fine had simply delivered what they promised and "pocketed" the extra money. If they are getting paid accordingly to do what they love, without having to work for a big evil publisher, they will almost certainly make more games. So any "extra" money is just going into those future products.

My logic on this is that the crowd-funding paradigm looks to me an awful like the "pre-ordering" paradigm. You pay ahead of time for a product, in exchange for some positive benefit. In software, this benefit might be a lower price or a bonus game level, or even just the assurance that you will get the game on launch day instead of having to waiting in line. This is the customer/publisher relationship. If a traditional game publisher has more pre-orders than planned, they don't expand their scope accordingly. In fact, the very idea is silly. If EA projects that Madden pre-sales will be 250K and they hit 300K, the development team doesn't run back to the studio and try to squeeze in an extra feature before launch.

But Crowdfunding is Different

However, there are reasons that this project can't be compared to traditional game development, and can't be compared to other Kickstarter projects:

1. The "pre-order" numbers are *very* public.
Yes, you could theoretically find out if Madden exceeded sales goals and then demand more features from EA. But in the crowdfunding scenario, the funding level is right there on the very page where you "buy" the product.

2) Crowdfunding is a new field that doesn't fit the current retail paradigm.
Rightly or wrongly, we put more trust in a Kickstarter team than we do in a big game publisher. And in return, rightly or wrongly, we expect that the Kickstarter team will act (as an economist would say) in an "irrational" manner, going out of their way to provide us with a quality product instead of only looking at the bottom line.

3) Software is different.
If you are Kickstarting a board game with a $10,000 funding goal and you get five times that, there isn't an expectation of scope creep. The game is probably already designed and the funding is being used to meet actual physical printing costs. More funding means you have to print more copies and spend most of that money. Because software distribution is perceived as "free", people expect that any "extra" money should go back into product development.

The problem is that when you internalize the above points, you end up succumbing to feature creep and promising more than you can deliver. This puts you in a horrible situation where you are not only working 80-hour weeks, your customers are also mad at you for not delivering what you originally promised.

Expanding Scope While Limiting Risk

Assuming you do get caught up in the internal and external pressure for feature creep, what are some ways to address this pressure without exponentially increasing the complexity of the project? Some ideas:

  1. Hire more QA. Most gamers would rather have a modestly-scoped game with no bugs than an ambitious but buggy release.
  2. Run a serious beta test, run entirely by staff outside the existing development team, so you don't distract them from their efforts to reach the finish line.
  3. Hire customer service folks to ensure that the game runs properly for everyone after launch, and that problems and requests are responded appropriately. Design teams always underestimate the problems that will occur with downloads, billing, shipping physical product, and delivering patches and updates.
  4. Promise an update to the game 6 months after launch that incorporates feedback, fixes game balance etc.
Anyway, I think this is really interesting discussion and a really important one for our industry. Not only because crowdfunding is becoming an important path to market, but because feature creep has always been our worst enemy.

If I ran my company the way they tell you to in business school, we might have 50 employees. On the flip side, if I always tried to expand scope to meet every single customer's request or expectation, we would be out of business. As one of example of this, I know for a fact that I have customers who would earnestly complain that I took 30 minutes out of my day (on a Sunday) to write this post, instead of working on the actual product.

Finding a balance is tricky. I feel for Double Fine, I wish them success, and I hope they can take the outrage with grain of salt and make the game they want to make.

No comments: