Introduction to Mobile Advertising

Many in the mobile industry see advertising as a dirty word, something to be avoided, a necessary evil – at best. This view is, perhaps, driven by the fact that the most successful games don’t have advertising – Minecraft, Clash of Clans, and lately Candy Crush Saga.  Of course it’s easy to promote life without ads when you’re making $2.4 million in revenues daily.

I’d argue this view is mistaken.  Advertising when done well can add a significant percentage onto a developer’s bottom line.  The most famous example of integrating ads seamlessly with your product is, of course, Google – who now earn massive profits from returning ads along with search results.  Why can’t the rest of us integrate ads in a way that enhances or at least doesn’t alienate users and players?

Many people still associate mobile advertising with cheap Banner Badgering.  However, the mobile ad industry is evolving at an extremely rapid pace, there are now all kinds of affiliate, interstitial, video, offer walls, to take into consideration.  Developers have reported that when done well ads are adding $500-$3000 onto their daily revenues – a figure not to be sneezed at.

To that end I put together a presentation for the team at Tsumanga Studios, where I work.  To introduce some of the terminology and options that are available to games and app developers, I hope you find it useful.

Best Practice

Of the current crop of top games, take a look at Gameloft’s Minion Rush – the way they have integrated ads is very clever, rewarding users with tiny amounts of currency in exchange for watching an ad.  Similarly Disney’s Monsters University have integrated an offer wall in a way that doesn’t spoil the game at all for those uninterested in ads (note this is a paid for app).

Placing interstitial ads at appropriate points, ie at the end of a level (like Fruit Ninja) or rewarding the player for watching ads should not destroy the user experience, and may help your app break even faster.  At the very least, you should use ad networks to cross promote your other content.

Conclusion

The mobile app and game space is still pioneer country.  No one knows anything.  There are plenty people doing well with and without ads, but you need to make up your own mind and run your own experiments.  There are a number of competing business models out there, clearly if you can get your game or app right vast profits can be made.  That, however, is not an easy task.  Until you get it right, perhaps, ads can help?

Advertisement

Startups – The Importance of Momentum

I’ve been working in my present job in a mobile games studio for about 6 months.  It’s been pretty intense, but we just shipped our first game.  I produced it, I’ve got my name in the credits, and it got 500 downloads within 24 hours of being launched, so I’m very pleased, and I expect things to only get better 🙂  Not bad for a bunch of guys with limited experience in the gaming industry.

I wanted to blog some thoughts about lessons I’ve drawn as we’ve gone along, before the nervous breakdown hits.  First up – The Importance of Momentum.

What it felt like on my first day

The technology industry attracts a lot of smart people, which can be pretty intimidating when you’re starting out.  How can we compete with EA, how can we compete with Microsoft, but you can – as long as you keep moving quickly and get your products into the marketplace.

Here’s the top 10 ways and rationale for acting like a shark, and keeping on swimming:

1.  Stick to the Plan – At least once a day one of the team will say “Stick to the Plan”.  You can only move fast if you have a good idea of where you’re heading.  Plans need enough detail so you can spot when things are starting to wobble.  When things are moving at 90 miles per hour, as they do in a startup, there are all sorts of variables that will be thrown at you.  If you have a plan you can easily say No – we’re sticking to the plan.

2.  React – The corollary to Stick to the Plan is – don’t always stick to the plan.  Over time you’ll inevitably be presented with evidence that your plan isn’t working.  Feature X is bogged down, Team Member Y is struggling with task Z etc etc.  React to this evidence and change your plan, make a new better plan and hit the accelerator again.

3.  There’s a fine line between order and chaos – The corollary to the corollary is being sensible enough to hit the brakes and drive within your limits (to push the metaphor).  Don’t change everything at once, prioritise problems and learn to live with uncertainty.

4.  You ain’t going to get it right first time – Most startups will probably have 3 years, or less, to demonstrate they can make money, so the earlier you can get some traction in the marketplace the better.  Spending 2 years in development, is a big risk, much better to ship 4-6 products or significant updates in that time (see the MVP).

5.  If in doubt, keep it simple – When faced with a choice, the safest bet is to go for the simplest solution.  If you’re wrong at least you’ll find out sooner, and in my experience simplest is best 9 times out of 10.  Large estimates and complex solutions have red flags all over them. (see YAGNI)

6.  Shipping teaches tough lessons – A feature we spent a number of weeks developing was rejected by Apple.  If we hadn’t shipped early we’d have wasted additional man-hours on a feature that we had to remove.

7.  Perfect is the enemy of good-enough – It’s comforting to gold-plate features, nail another bug, spend another few days in QA, optimise a bit more.  But if your product is good-enough, ship it, then react to real-world data, rather than second guess.  We went live with 20 known issues, but they were all issues we could live with.  If no-one downloads it, you’re much better to know after 3 months, rather than 6, as you could have spent the previous 3 months doing something different.

8.  Play to your strengths – It’s important to recognise where the strengths and weaknesses of your team lie.  Over time what you thought was a strength may prove to be a weakness, so change your plan.  Where you have gaps, either hire, or better, partner and use freelance resource until you can demonstrate you have the need/resource for a full time employee.

 9.  Don’t wish for what you don’t have – Don’t waste time on toying with the latest fads.  If you have a team of PHP programmers just write PHP as much as you might wish for a team of hipster Rubyists (see play to your strengths).

10.  My rushed site got 30,000 views – One of the first things we did was launch a website which we’d be the first to admit isn’t going to win any design awards.  However, we’re working on an updated design that addresses some of the original’s shortcomings.  In the time version 1’s been live we got 30,000 visitors and 3000 sign-ups, a 10% conversion rate that gave us some confidence we had a market.  If we’d waited until everything was addressed we wouldn’t have the confidence or the numbers (see perfect is the enemy of good enough).

10.1 Investors like momentum – If you can show your investors something tangible that they can see and play with, their confidence and happiness will increase (and you WANT happy/confident investors).  They can’t take a burndown chart to the bank.

So in summary, ship early, be agile in the truest sense, and keep moving.

The SDK business is dead – It’s a commodity market now.

I’ve been thinking about selling SDK’s recently. I have a pet theory that just like everyone has a novel inside them, every developer has a SDK inside them. A SDK that would make constructing software as pleasurable as running through a summer meadow, who’s many hundreds of unit tests would shine green like a leprechaun on St Patrick’s day, and every design trade-off was explained by a 30 second video from @unclebobmartin.

A beautiful dream, even more so if you think that you can sell your SDK for cash-money, to run a profitable business, in the 21^st century.

But without me noticing it (until now), the software tools business is rapidly turning itself into a commodity business, like electricity and gas, where you pay for what you use.

Reasons SDKs are a tough sell

First let’s look at why selling SDKs is difficult

• Software developers have no money – By in large most small software teams have little budget for tools
• Software devs don’t like spending money – Devs brought up in the Linux/Ruby/Python communities are so used to installing gems etc for free, that the thought of actually paying for software is often met with outright hostility.
• Not Invented Here – If you didn’t code it yourself, it’s probably rubbish. What Linus coded it? Well he probably made some stupid decisions.  All devs look down their nose at others code.
• Laziness – evaluating a SDK is quite difficult, more so if there’s tons of dry documentation to read.  We’d rather code it up ourselves, right?
• Upgrades – Upgrading your software is a nightmare, there’s a reason everyone delivers client-side code over the net.
• Platform specific – you write your code in Python, well only some dude who knows Python is going to be able to do anything with it, you’ve segmented your market (in a bad way) before you’ve even started.

So where does that leave you, basically with 4 strategies:

1. Pile-em-high, sell-em-cheap – If you have a SDK or tool that is mass market – eg Resharper.  I’d suggest your maximum price point is circa £200.  Much more and no matter your claims small teams just won’t be able to afford you, or they’ll look down their noses at you.
2. Enterprise – Large enterprises are more used to paying for tools and software.  However, they often have large legacy code bases, so may not require new tooling (or their devs are enslaved on Windows XP and an ancient version of Eclipse).  But if you can find a niche you may be able to sell here possibly up to £10,000
3. Exclusivity – If you have tooling that help crunch numbers for quants, oil surveying etc then you can probably justify a very high ticket price.
4. Service – Give away your tooling and charge for support.  Eg Red-Hat linux etc.  This can work, but I’d suggest it’ll take a ballsy investor to green-light this strategy.

So selling SDKs and tooling is a tough business, it can be done, but it’s hard.  So is there an alternative?

Its services all the way down!

I first heard people bandying around the term Software as a Service (SaaS) maybe five years ago.  At the time it was all talk about silos, XML and SOAP.  Anyone who’s looked at SOAP was so bamboozled by WSDLs and handshaking and 2000 lines of XML that they abandoned all hope.

But then the 3 Musketeers of REST, Json and OAuth came along and changed all that.  Suddenly the average dev could understand and consume your API with ease, without requiring a PhD in angle-brackets.So what’s are the advantages

• Low barrier to entry – No downloads and generally a free trial to try it out
• Pay for what you use – most SaaS providers offer a tiered structure, ie 100 users = £5, 500 users = £10, 100 transaction = £5, 1000 = £10.  So price is right for everyone.
• Upgrades are pain free – they upgrade their platform, you benefit at no cost to you (unless API breakage, but that’s rare)
• Economies of scale – If you integrate a SaaS service into your software then each additional customer you gain, will generally mean the price-per-unit you pay to the SaaS provider becomes cheaper overall.  Ie because 2 customers are doing 500 transactions between them the price per transaction drops.
• Platform agnostic – cranking out your code in Objective Haskell? That’s cool you can consume our API.

It’s an absolutely brilliant way of delivering tooling to other devs.  I’d be convinced if you’re currently trying to sell a SDK to developers that the core or some element(s) of your product could be turned into a service and delivered using the SaaS model.

On a recent project I’ve used Rest based services from SendGrid, Zencoder, Zendesk and SagePay to name but a few, and it’s been a joy.

Conclusion

I prefer to abandon the term SaaS and use “commodity” instead.  If you start thinking of your service as a commodity like electricity then it’s easy to think of customers consuming it like a commodity and paying only for what they use.

Major vendors from Microsoft on down are adopting the commodity model.  It wouldn’t surprise me, in fact, if Windows 9 was given away for free, and you would just pay for cloud backup, office 365 etc as you needed them.

The SaaS/commodity model is here to stay, it scales, is platform agnostic and makes your service easy to consume and cheap from the end user point of view.

I’d suggest that all vendors of SDKs and tools to other software devs start to look seriously at delivering over SaaS, otherwise your competition will.