Some Lessons Learned
By Richard Rouse |February 15, 2015
Source: Some blog.imaginellc.com
This is a candid post that analyzes the lessons learned in starting a company and developing games…
Broadly speaking, strategy plays two crucial roles for us – firstly to increase the chance of massive success and secondly to succeed in the least amount of time possible.
Every company defines success differently. For us, we want our games to reach millions of players across the globe, with those players being truly engaged and engrossed in the experience for months and years.
Although our first title, Bar Nuts, was not a ‘success’ as defined above, it gave us an invaluable learning experience and laid the foundation for one of our core values – continuous improvement and embracing failure. Making innovative games is risky, risk can inherently result in failure and we think that failure is something that should be embraced in the pursuit of continuous improvement, because this is where the greatest lessons are learned.
To say that our strategy in 2011 was conducive to the aforementioned strategy outcome would be a flat out lie. Looking back, we would have given anything to start again in 2011 with the knowledge that we now have. Instead of asking Sporky if he could build a time machine, we decided to do the next best thing – add experience to the team (Dammo) and pack all of our learnings into an innovative and cutting-edge game that would be enjoyed by millions.
Step 1: Dissecting where we went wrong
We dissected where we went wrong, and how we could leverage these powerful lessons into our future endeavours. Let us step you through where we went wrong…
Building a full resource game with a fresh team of four was a hugely ambitious project, a project that took us two years.
Two years near the infancy of the App Store was an aeon. Over this time, hardware capabilities increased which led to new games entering the App Store with superior capabilities. This gave us the the urge to catch up, resulting in destroying large chunks of code and rebuilding large parts of the game.
Now, two years is a price that we were more than willing to pay to reach our success target. However, during this period we were reluctant to prove traction with our target demographic.
We were hesitant to get an unfinished version of game Bar Nuts (let alone a prototype) into the hands of players because we didn’t want to be judged on an unfinished product or have competitors steal the game concept. In the eyes of the developer a game is never finished – there are will always be features and polish that you want to add. Listening to this inner voice before launching proved to be a big mistake.
This quote from ‘The Hoff’ sums it up to a tee.
Due to our lack of user testing, virtually every aspect of our game was an assumption.
We assumed: our target demographic liked the theme, players would find the core mechanics fun, friends would want to crash each other’s parties, drunk patrons vomiting in your bar would be entertaining, the app icon would get the most clicks among the options we had. We even assumed that our engine could withstand high res frame animation with the number of characters necessary, while comparable games were using sprites
You get the point – we assumed everything!
There is nothing wrong with creating a niche product when starting a business to build a base of super-fans, particularly when you are a startup trying the carve out an audience. However, when you give your product away for free this can be problematic.
Step 2: Lessons Learned
After dissecting where we went wrong, we discovered that the problems we identified were also being felt by other tech companies. This is when we discovered The Lean Startup and immediately began immersing ourselves in it.
Before development was properly underway, we crafted legal contracts… the hard way. Simplifying this process by having all the team on completely equal terms for Mutt Runners saved a ton of time.
Our development process was old school – using techniques being taught in game design lectures since games were invented. We went from building lengthy and rigid design documents to iterating working documents that break down each game element into modules. Think moving from Microsoft Word, with workflow managed in Excel to individual spec docs using Google Docs, managed with Trello.
We failed to establish an efficient development process, backed by software to support us in establishing smooth and consistent workflow. Being a remote team, the establishment of a kanban system as our foundation development process, coupled with reliable, intuitive and customizable software in Trello (recently switched from Kanbanize) has been paramount in driving efficiency and shipping builds quickly.
Despite building our own analytics stack, we didn’t get this valuable insight until it was too late.
We have moved from being precious about being judged prematurely to embracing negative player feedback so any issues can be identified at the earliest possible point in order to deliver what our player want.
This is why we initially deployed Mutt Runners Origins as a bare bones product (MVP), soft launched and assessed its viability (product-market fit). After overwhelming positive feedback, our strategy has been to deploy Mutt Runners in ‘modules’ as updates – see blueprint posts.
This process has allowed us to get granular insight as to what effect each feature set is having on our players, how these features are being received, if players enjoy the mechanic, user experience (UX), what isn’t clear, and so on.
We have embedded optional surveys and a feedback button right into the game so that players can let us know what they would like to see or where they are frustrated, without leaving the app.
The Lean Startup framework demonstrates this process as build, measure, learn.
Virtually every aspect of building a game is an assumption, particularly when you are innovating and creating a game that is unique and stands out from a crowded market. Our team holds each other accountable by challenging assumptions. Our morning meeting vernacular surrounds this very word.
This morning, for example it was “yeah mate, but that’s an assumption… but either way it’s an assumption.” When this situation arises, and the assumption is particularly risky, the next process is to form a hypothesis and discover if the assumption holds true.
For assumptions that can be tested server side, we deploy A/B tests. We always have an A/B test in place to fine tune the best experience for our players.
In selecting Mutt Runners for our next title, we wanted to create a truly unique game that would stand out from the crowded App Store, while appealing to a wide audience. Being a small team, is was vital not to clone the next Clash of Clans, Candy Crush or town builder, like so many of our larger companies that can get away with it.
We landed on a theme that was in very low supply, was a solution that we assumed mobile gamers wanted, and used the principles above to assess its viability in finding product-market fit.
This is not an exhaustive list of our lessons learned, rather a high level summary of our most crucial learnings. We are always evolving our processes, strategy and mechanics. If you found this useful, stay tuned and we’ll happily share our learnings as we continue on our pursuit of continuous improvement.
Get in touch with me at firstname.lastname@example.org or follow me on twitter and I’m always happy to set up a Skype chat with any Mutt Runners fans!