This multi-part series examines the history of Knockabout Games, a mobile games startup I co-founded in 2002, near the start of the pre-iPhone “first wave of mobile gaming”.  The start of the series can be found here, and last week’s post on Knockabout’s demise can be found here.

I wouldn’t feel too sorry for Knockabout, by the way.  We shut the company down cleanly, without debt.  Everyone found work quickly.  Our publishing partners still talk fondly of the titles we created for them.  And something odd happened after we closed the doors.

Early in Knockabout’s existence we did a deal with Motorola to OEM our pinball game on some of their handsets.   It was a colossal waste of time and money that we never thought we’d recoup (our max upside projection was about 10k– we did it mostly for the relationship).  We’d only ever seen one royalty report, and it was so small as to be inconsequential.  We had written the whole thing off.

Except that, three months after Knockabout’s end, we started getting checks from Motorola.  Checks that were large enough that we could have saved the business if we still had staff or an office or anything.  But we didn’t.  So we distributed the money to the shareholders.  We had no way to project how much would come in or for how long, but every quarter a new statement and royalty check would arrive in the mail.  For two years, money came in and went right back out.

On top of all that we got inquiries from both Microsoft and Sony about the pinball game, and ultimately licensed it to both of them.

Was all that enough to make up for the cash we sunk into the business?  No.  But it did soften the blow substantially.  Monty and I often joke that we should have made pinball and immediately shut the company down.  The real lesson, perhaps, is that we should have put more faith in our own IP and focused on that with a smaller staff.  We didn’t need to build the shop like our past businesses — a few guys would have been sufficient to achieve sustainability and from there we could have scaled up as appropriate.

The larger observation is that speed isn’t always as critical as it appears.  Any time you enter a new, emerging space, there’s a tendency to view the window of opportunity as small.   You have to move fast, grow quickly, establish a foothold before the value chain ossifies and fills up with established players.  To some extent that’s true.  But I think there may be a case for being patient and growing organically, not worrying about the timeline and just adapting as you go.  If you’re small, really small, you’re actually pretty nimble — large tectonic shifts in the space don’t kill you.

That wraps up the series on Knockabout Games.  The entire sequence is below:

Before The Start

Product Strategy

Business Strategy

Funding, Equity And Staffing

What Actually Happened

Where We Failed

Knockabout’s Demise

An Epilogue

This multi-part series examines the history of Knockabout Games, a mobile games startup I co-founded in 2002, near the start of the pre-iPhone “first wave of mobile gaming”.  The start of the series can be found here, and last week’s post on how Knockabout’s strategy failed can be found here.

In the end, Knockabout got caught in the typical developer trap, going from project to project, always in danger of missing payroll should a milestone slip.   We reached a point where we couldn’t sustain the business and had to shut it down.  Rather than conceal this from our staff and business partners til the last possible moment, we took a gamble on a better (and I would argue more ethical) approach:

• When we first saw things starting to crack, we informed everyone that we were at risk.  We didn’t know if we were going to have to close our doors, but we didn’t want anyone to be caught by surprise.  This was risky– our staff could start jumping ship and our publishers could cancel projects.  But none of them did.  We talked about options and scenarios, but mostly we worked hard to keep revenue flowing.
• A month later we revisited the situation and made the decision to wrap up the business (for reasons I’ll outline shortly).  Again, we told everyone.  Because we had titles under development, we told our publishers we would do our best to complete them, but it would likely cost more than they had budgeted.  All but one decided to continue.  We then asked our staff to stay on until their respective titles were done.  That meant as much as two more months of work.  We also said we’d help them find work if they needed it, and we’d give them severance if they stayed to the end.  All but two stuck it out.  I’d like to think being open and honest with everyone — publishers and our developers — compelled them to stick with us, but I can’t say for sure.

Not everyone understood.  One publisher initially agreed, but was baffled when I asked for more money to complete their project.  He told me I shouldn’t pay my staff unless they meet their milestones.  I explained that every one of my engineers already had jobs lined up with better salaries than what I was paying them.  They were there out of loyalty — he was welcome to not pay, but the project wasn’t going to finish.

Why did we close our doors?  Why not raise money, borrow from the bank, or scale back operations?  That may have been an option.  Indeed, we had deals on the table for another round of products.  But they all looked like the last round of projects, which meant we’d have a hard time surviving unless we were perfect on delivery (and we clearly didn’t have a track record to support achieving that).

We also looked ahead and didn’t see an exit.  Our strategy didn’t produce value in the space the way it had in the pc and console sectors.  And we didn’t have the capital — or the time to raise capital — to change the nature of our business.  So we moved on.

Many of our colleagues faulted the space — it was hard on developers, market conditions were tough, very few survived.  But if you’re running a business you can’t ever point to external factors.  Every problem is ultimately a problem of execution.  If you don’t see the changes happening around you, or you fail to adapt, the only one you can blame is yourself.

Next time:  An epilogue of sorts.

This multi-part series examines the history of Knockabout Games, a mobile games startup I co-founded in 2002, near the start of the pre-iPhone “first wave of mobile gaming”.  The start of the series can be found here, and last week’s post on how Knockabout’s plan played out can be found here.

So some of the things we did worked well.  It didn’t play out perfectly though.  A number of problems presented themselves:

• Our costs rose with each round of titles too.  Not as much as the funding, but it was a couple years before we finally closed the gap.

• We chose to emphasize quality over everything else.  We had a limited number of resources, so that meant delivery date was not #1 (we would rather slip than be less than great).  I had a theory that, assuming you have the talent to deliver, the difference between a good title and great title in the traditional game space was perhaps 2x in development cost.  But it was 5x in sales, and those sales would cure all sins.   Except in mobile it wasn’t 5x, it was more like 1.2x, which doesn’t justify the development math.  We were making licensed sports titles for the #1 publisher in the space and garnering the top review scores.  It didn’t matter.  Consumers had trouble differentiating titles prior to purchase (14 characters for your game’s title, and no screenshot or other information), and didn’t seem to value them very differently beyond that (not enough for word of mouth to take off).  The COO for one of the major mobile publishers told me flat out that he’d rather have two mediocre titles for the same budget as one great title.

• We were slow.  This turned out to be Knockabout’s achilles heel.  Yes, we sacrificed time for quality.  But it went beyond that.  We couldn’t hit a date to save our lives.  I don’t have a good explanation for that.  In my first company we had taken people who had never shipped before and got them to hit every date, so part of me thinks I took that for granted — after all, our team had a ton of experience shipping product.  Or maybe our choice to go with more junior managers was wrong.   Those all feel like thin excuses though.

• Platform support, over time, became the critical skill to have as a developer.  We were building reference builds — i.e. a version of the game on 4 or 5 handsets that represented a sample of the possible memory and screen configurations.  The publisher would then send those off to a shop in India or Russia to have them ported to 200 handsets at $300 a pop (these days it’s more like 5000 handsets).  We couldn’t compete with that porting price.  But the developers who won were the ones who built a framework that could spit out ports at a push of a button.  The publisher would pay them the porting money, and they’d have no additional cost.  Of course, they had to limit their products somewhat, or choose ones that didn’t push the envelope like ours.   But by the time we realized we had to take this approach it was too late.

• We eventually hit a development budget cap.  We were getting the top rate in the space, but the return wasn’t there and publishers stopped increasing their per title development budgets.

All of this led to some difficult decisions.  We were trying to split our time between our own games and those for our publishers (our own titles were self-funded, we always dedicated resources to our publishers for the duration of our deals).  But as deadlines slipped, we applied more of our resources to our contractual commitments, and eventually had to can everything but our pinball game.  Bye bye breakout and blackjack.

And since we were bootstrapped, we had no capital to address the porting framework problem or to bring in more resources.  We were living a typical hand to mouth existence, with payroll dependent on hitting every milestone.  There was no buffer, and at 16 people, we couldn’t personally cover the difference.

I have quite a bit of game design experience, and that’s the role a played for Knockabout.  But I was also the CEO, which meant I was responsible for various business development and operational functions, plus managing the guys managing the products.  In addition to not having the time to actually do all that, it created a really awkward situation for the producers:  I was their boss, but I was also the guy on their team they needed design work from.  I had a good rapport with individual developers, but it undermined the managers.

Hiring junior managers was probably a poor choice too.  We saved money, and the guys were talented.  But I never spent the time to help them grow into their roles, throwing them in the fire and devoting cycles to business and design issues.

Our assumptions about distribution were also a little off.  While many of the carriers were encouraging developers to go through publishers, Verizon asked us point blank why we were using JAMDAT and not going to them directly.  In the long run I think that would have been hard to sustain (and we certainly couldn’t have gone direct to every carrier), but we might have been able to capture more short term revenue.

There were some unexpected staffing complications as well.  We gave a small signing bonus to one engineer we hired;  he took it, quit a month later and refused to repay it.  Another engineer came to work for us and quit after two weeks because a competing company made a better offer.  That’s random stuff that just happens:  both guys came in on personal recommendations from people already working for us.  In a startup you always have to expect the unexpected.

Next time:  Knockabout’s demise.