iOS Product Strategies - an honest discussion

One of the biggest mistakes I see people making as they enter the appStore is a lack of understanding of how the appStore ecosystem behaves. Most developers assume that it is only a hit-based eco-system - that a couple of Angry Birds and Flipboards define the worlds largest software product marketplace. For most developers entering the appStore with visions that your product will become the next Angry Birds or generate engagement like any of the Zynga games on iOS is an exercise in tagging yourself "stupid". 

I was chatting with Enrique Allen and an applicant at 500Startups the other day and we were discussing the enterpreneur's vision for mass market adoption on the iPad for his app/product. A major hurdle in his (the enterpreneur's) understanding of the appStore was that customer adoption would be "easy" given the scale of the appStore and the product-market fit given the demographic of users that make up the iPad today. Assume for a moment that the app has a great launch - what next? What about 2 months after launch or 3 or 6? You do not need to have all the answers ready, but, in my opinion you need to ask yourself some of these questions today. 

As a Product Manager I care about the lifecycle of the product and not just the launch mania. I have learnt from the launch of many apps into the appStore and I see a pattern in all of them - it is that of a left-heavy bell-curve (see image below). The height of the bell-curve will vary depending on how good your app is but the way it settles is a truth you cannot escape. It will settle, and you need to plan for the way the apps settle.  

Fatvsthin

In explaining the appStore product cycle to anyone I have begun to use the terms: "settling fat" vs. "settling thin".

Settling Thin: After the initial euphoria of your app having been released and you getting some decent coverage in the press and through bloggers you will see a steady decline in the number of downloads per day. This is normal. Be sure to measure downloads and updates using services like AppAnnie or appFigures. I personally recommend appFigures - they have great pricing and good customer support for their paid plans. 

Settling Fat: This is the baseline of what I want of all our apps at 955 Dreams. We wouldn't begin to consider expending energy on any app unless we knew it could settle fat. After the initial round of coverage from press and hopefully good coverage through the appStore the daily app sales will start to slow. Sales settle at a predictable and healthy pace daily. This is what you want. Any additional marketing or ad-spend results in measurable improvements in daily sales volume.

Fat and Thin is relative: To figure out what these curves mean for your startup/business, invest some time prior to launch to set some projected daily downloads for your apps. Think long and hard about projected downloads the first month of launch and then use the fat vs. thin curves to figure out what you could be looking at in terms of downloads 3 months into launch. This might seem like mind-numbing number crunching today but believe me it serves as a great tool to figure out the validity of your business or app/s. If your apps settle very thin - you need to rethink your product from the ground up. Spending good money on ads when apps settle thin is a bad idea (more on this in a follow-up post). 

I'm looking for more feedback on this and would appreciate some dialogue... you can also follow me on twitter: @smalldozes


 

 

 

startup lessons from traditional media...

There's probably some larger lesson about social media to be drawn here, and how its immediacy can be great in its power to connect us, but also a liability because something blurted out and not meant to be serious acquires a greater power. Then, an offensive joke can be seen as an ideological manifesto, gallows humor can be seen as a serious support for sexual assault. I only wish this had been apparent to me before I hit enter.

an interesting read

[think before you tweet Kiran]

one reason why I'm fine with the 30% apple tax for subscriptions...

Order_inbox
here's a list of orders on our Android Merchant Dashboard. I've hidden everything about the transaction save 2 very important variables to illustrate my point. 

Charge is whether the transaction actually went through - ie the customers credit card was charged the amount that the app was on sale for at the time. From this Google will take 30% of the transaction. I'm completely and totally in favour of the 30% transaction cost from Google aswell - if Google was to charge a 30% subscription tax I would gladly pay that aswell. 

Here's what I would want from them though:

You see the ugly red triangles - those are BAD. Very bad. What it means is that the customer who downloaded the app successfully onto their device for some reason has his or her credit card declined during the transaction. If you notice the number of red triangles or crosses in this simple screen grab you will see how much of work it is to manage these transactions and finally get the consumers to either fix the transaction on their end or convince the ones that cancelled that the product is worth the money that they spent. 

In the Apple ecosystem, we don't deal with this. Consumers that are downloading the apps have already gone through the credit card check process and Apple is dealing with the transactions. This is a BIG deal when you're talking about a direct to consumer business with the kinds of volumes that we generate and the volumes that we want to get to (tens of millions of transactions a year). 

Tell me why I suck in the comments. Or show me a real response to deal with this image in the Android ecosystem. I'm listening.

iOS subscriptions and the 30% tax

The furor on the web from this morning's announcement by Apple has been loud and really negative. I've heard practically every blogger without an iOS app or web-service come out in arms about this proposed change in Apple's dev policy. 

I have just a few words of advice: "Calm the fuck down."

At 955 Dreams we're working on launching a new subscription based service for the iOS platform and we're perfectly fine with this 30% tax levy. Here's why:

  1. It doesn't effect iOS only subscription services. If your service is only for iOS devices then this 30% is exactly like the in-app or app-sale cut that Apple takes today. Nothing has changed. In fact, the entire process of adding customers through a single click and charging them monthly for your service is a profound improvement from the earlier one time pay and in-app purchase only models.
  2. If your service is or was a web subscription service: here's the question that you have to ask yourself: how has the addition of iOS effected your business? For rdio, Pandora and others in the music space this is a no-brainer - the addition of the iOS platform has made their services more relevant. They just would not be the same without Apple iOS and that's a fact. If the addition of the iOS ecosystem has actually complimented your business then paying the 30% subscription rate seems fair to me. How about reducing your ad-spend on the web, controlling your customer acquisition cost on the web and staying focused on the part of your business (iOS) which has a fixed cost (30%) and where you know you can convert paid users more efficiently?
  3. I consider a large part of this 30% fee to be a marketing expense. Our products are being showcased to an eager audience that wants to buy. read more about this here....
  4. Subscription billing, managing cancellations etc. is a time consuming and critical part of your own handrolled subscription service. This will cost money to create and manage. I'm happy Apple is doing this for us and part of the 30% cost goes directly towards this expense. 

I may sound like a fanboy and you can cuss me all you want. My team has made 3 app-of-the-weeks in the past 14 months and more are to come. We're adhering to the high standards that Apple sets when it comes to the experience for users - this is the most important thing when you're selling directly to consumers. Every thing else, like todays web uproar is noise. 

 

nokia in 2007

September 5th 2007 I visited Nokia HQ with a few other mobile bloggers as part of a fact finding mission into the new mobile technologies which were being developed behind closed doors at Nokia. Obviously, being in Finland (which is a great country btw), even for a holiday, you develop a sense of reverence towards this flagship Finnish brand and most people talk very very positively about them there. This was most definitely true in 2007. Everyone in Finland loved Nokia and people who came to visit Helsinki (atleast in tech) spoke in hushed tones about what Nokia would do to "crush Apple" for encroaching in mobile. 

This is a recap of what actually happened during that visit. This is not made up.

The iPhone was announced on January 9th 2007 and went on sale on June 29th 2007. Practically every little minute detail of the device was disected, analyzed, blogged about and video taped online. Everyone I knew in the mobile + tech community had atleast kept abreast of every small feature on the device - most already owned the device. I had my iPhone with me when I walked through the glass doors at Nokia.

We were greeted by kind people who showed us into some sort of press greeting room and started showing us many of their new devices. Most were already on shelves in Europe and the US and they spoke about some new Symbian features which seemed mildly interesting. An over enthusiastic blogger who was with us asked me to hand my iPhone to the "suit-man" who was showing us around - he had introduced himself as one of the product manager/evangelists at Nokia - he seemed important. 

A small crowd had gathered around suit-man as he sneered and jabbed at the iPhone. He nervously tapped around and got to the camera - asked about the megapixels on it and then asked how he should take a picture since there were no evident buttons for the shutter - Nokia devices did have this on the sides of the hardware. I thought he was joking and ignored him the first time, but, when he asked a second time, to keep the joke alive I asked him to talk to the phone and said the device recognizes the "click" sound. 

He actually talked to the iPhone expecting a result. 

3 Months after the release of the device and almost 8 full months since the initial announcements this guy had still not touched an iPhone. He also seemed to believe that the device had voice recognition built in for simple controls like the camera - basically he was clueless.This would be funny if it were not true. I left Nokia HQ feeling a bit puzzled as to how this giant company could be so clueless and what it would take for them to be jolted out of their silly market leading stats (which they tout to this day).

Reading about how Nokia is going to make a turn-around and attract dev talent to their eco-system in 2011 seems a bit absurd. They're not going to be able to right the software ship in their orgn. alone, they need help. Microsoft is as good a company as any that can lend a hand and help. Google would have been a great partner aswell. They should stick to building the hardware which they are good at and leave the software to MS - possibly even setup the evangelising group here in Silicon Valley. 

I wish them the best of luck. Really - atleast they're trying 4 years later.

Here are pictures from my trip: https://picasaweb.google.com/kiran.bellubbi/NokiaVisit2007#

 

 

Samsung Bada

Samsung bada includes a new UI framework that supports the next generation Samsung touch UI. The main UI delivers simplicity and ease, without decreasing usage efficiency. The UI framework introduces an open-ended evolutionary innovation from the current touch UI to leverage better user experiences.

 

a team of drunken asinine monkeys wrote up the main developer landing page for the Samsung Bada Platform. There's even more fun stuff here. I had to stop reading...

Marketing iOS apps

Over at 955 Dreams Inc. we get pinged a lot by people looking to understand how we market our iOS apps. 

There's always an incredulous look when we tell them we practically have a non-existent marketing budget. It's not like we've not tried before with some sort of web-based marketing approach. Its been a colossal waste of time and money. I wouldn't recommend CPM and CPC marketing to anyone in the iOS ecosystem. People who claim it works are just flat out lying. 

Before you embark on a massive spending spree on marketing your app outside the ecosystem consider this: 

You spend 30% of your revenue just to do business in the appStore. Part of this 30% cut goes towards the mechanics of the transaction itself - that's just fair since the entire transaction is just so frictionless - no one save Amazon has managed to make it this easy. 

Let's assume 1/3rd of your 30% goes towards this cost. The rest is being spent in some way on showcasing apps on the iTunes Store. Apple is actually doing a great job on this front. 10 Billion apps downloaded, record numbers given out in revenues to developers etc etc. So in-effect a good chunk of your revenue is already being spent to market your app and they're probably doing a better job than most people can of converting those dollars into brand awareness and revenue for you. 

As an app developer you should embrace and grok this simple fact. Then start spending more time on making the experience in your apps much tighter and you'll see results. Your marketing budget is trying to work for you today... you just need a product to go with it.

App usage data and how it can inform feature ideation and save money (hell yeah!)

I'm a huge fan of Flurry. Adding flurry libs to your app before go-live to me is a no-brainer. I would never release an app into production without some level of analytics to help us understand usage and feature adoption amongst users. 

For our latest app: Mario Batali Cooks! which was app of the week a few weeks ago, we went a bit further and actually put flurry to track some interesting usage data. 

We have videos in our app. Tons of videos - about 6hrs of total playing time worth of in-depth, beautifully shot videos with Mario actually teaching you to cook. These videos are heavy and take up space on your phone so we decided to allow you to decide which ones you want to download onto your device. We host these videos on Amazon's S3 infrastructure and apart from the simple cost of the hosting (2Gb worth of videos) we were concerned about the amount of money we would be spending on monthly bandwidth costs. 

Enter Flurry and something that's pretty easy to setup called Event Tracking. Using the Event API calls, it's fairly easy to setup when a particular event gets fired within your app. These events can also take in parameters which makes them quite dynamic (neat!). What we managed to pull off was a simple report which tells us how many times worldwide a particular video is played (which means downloaded). We can now take this information and possibly add the top 5 popular videos directly into our next version. 

Flurry_analytics

Setting up events is not a revelation here. Implementing it is not either. It's what you do with that information that matters and how you use it. 

I know a ton of developers that just throw this invaluable tool in to their builds so they can measure "something". Once you go beyond session length and repeat usage stats - the usage of flurry data in most apps to make informed product decisions is abysmal. 

Fix this by figuring out what you want to use the data for first. Then work out how this exceptional tool can get you there.