Techpinions post on business models

As some of you may know, in addition to blogging once or twice a week here, I do a weekly column on Techpinions, which is published pretty regularly on Thursdays. This week, I took some ideas I’ve been chewing on for a while and turned them into a fairly in-depth post looking at business models for monetizing consumer technology products and services. I talked about the tension certain business models (such as Advertising) create between end users and paying customers, and also talked about the strained logic behind Microsoft and Google’s aggressive efforts in emerging markets. Here’s a taster of the framework I used to evaluate the business models for monetization:

Business models for monetized productsIf that looks interesting, head on over to Techpinions for the full post.

 

Apple, IBM and the Pareto principle

If you studied high school economics, you might have come across the Pareto principle, which many people merely refer to as the 80–20 rule. This Wikipedia summary is as good as any:

The Pareto principle … states that, for many events, roughly 80% of the effects come from 20% of the causes.

Apple’s growth so far with the iPhone and iPad has been astonishingly rapid, as the chart below shows:

iPhone and iPad growth

However, both curves have begun to slope less steeply, and the iPad one has essentially flattened in recent quarters. Growth so far has been driven by fairly basic factors: releasing compelling products on a regular basis, and expanding distribution over time. The iPhone base, and the distribution relationships Apple had built to sell the iPhone, helped the iPad to grow much more rapidly. But growth in both products has begun to slow, especially in percentage terms. Apple’s product and sales strategy for the iPhone and iPad has changed little since both products were launched, but these have led to very rapid penetration of the addressable market for both products.

This is where the Pareto principle comes in. At this point, Apple needs to make a strategic shift as it enters a new phase in the growth of these two products. The established strategies will continue to drive some growth, but it needs to augment these with new, more tactical, approaches to penetrate the remaining parts of the market where these established strategies won’t serve it as well. One obvious example of this is the enterprise, where Apple has so far fared very well simply through its existing strategies of creating compelling products for consumers and slowly adding support for enterprise use cases. But Apple will only grow so far in the enterprise as long as IT departments support Apple devices reluctantly rather than wholeheartedly, and the IBM deal is a way to change that. It won’t move iPhone sales by a huge percentage, but it’s one of many smaller strategic moves that Apple will have to execute on to drive the next phase of iPhone growth.

Another example of this strategy is the 8GB iPhone 5C Apple began to make available in March 2014. Again, it’s not going to move overall numbers by a huge amount, but it may well drive enough to make a difference. I’m expecting to see quite a few of these sorts of initiatives from Apple as we go forward. We’ll see a more complex and diverse set of growth strategies to drive the other 20% of growth, compared with the 20% strategies that drove the first 80%. Some of them will be announced with significant fanfare like the IBM deal, while others will be much less noticeable, but as a strategic direction, I suspect the IBM deal is the shape of things to come.

Apple will make several wearables, but not a watch

Back in January, I did a post titled “Why Apple may not launch an iWatch anytime soon.” The gist of the piece was this: that Apple doesn’t enter markets particularly early, but rather enters at the point where the technology is ready for it to provide the kind of transformative product it’s used to disrupt the music player, smartphone and tablet markets in the past. At the time, my conclusion was that Apple would likely stay out of the wearables business entirely, until such time as the underlying technology was ready. However, given the other things we’ve seen from Apple in the last few months, I now believe it’s very likely we’ll see something in this category from Apple in the near future, but it won’t be a watch, and it’s likely that it will actually be several products rather than just one.

Smartwatches aren’t delivering on the promise, but the promise is flawed too

There are two big problems with the smartwatch market as it stands: firstly, the underlying technology doesn’t seem to be ready, which means it doesn’t deliver on the promise of the category. But secondly, the promise itself simply isn’t all that compelling for the vast majority of the general population. There’s a sense that if someone can just crack the smartwatch category it’ll suddenly explode, but I’m just not sure I agree with that. It still fundamentally seems like a solution in search of a problem at this point. But the coverage – as is so often the case – is driven by a very small number of people who likely are in the target segment and therefore talk up both the promise and the reality well beyond what’s justified.

A different approach solves some fundamental problems

For all these reasons, I’m still skeptical that Apple will release a product that’s identifiable as a watch. If I think about the thorniest technological challenge with smartwatches, it’s the fact that you’re having to squeeze both a fairly smart CPU and a decent display, and the battery to power them, into what has to be a very small form factor. That problem essentially goes away if you see wearables less as notification screens and more as off-device sensors, as Apple seems to, in contrast to Google:

Android Wear vs Apple HealthKit

If wearables are merely providing sensor extensions to the smartphone rather than trying to replicate smartphone functions, you can do away with the bright, big screen and the powerful CPU, and strip both down significantly. On some wearables, you might retain a small display, but it’s entirely possible that others would do away with it entirely. Put in the relevant sensors, a Bluetooth LE radio and a small CPU, and you’d be done. This would allow you to make the device significantly smaller and sleeker, make the battery last much longer, and also allow for many other form factors that could be worn in different places around the body. Continue reading

Why Apple might break its launch pattern with wearables

Apple has established a pattern over the last six years with regard to releasing SDKs to developers ahead of releasing new software and hardware products to customers. The original iPhone didn’t follow this pattern, not having an App Store and therefore no SDK either. But since March 2008, Apple has given developers several months’ lead time to create apps which are optimized for its newest hardware and software releases. The times between SDK release and customer availability of the related products is shown in the chart below:

iOS SDK to customer availability - 560px

The exact length of time between SDK release and customer availability has bounced around a bit. When new iPhones were released in June, the SDKs arrived first in March, and then in April, slowly whittling down the time available for developers to create apps. Then, in 2011, Apple moved the whole schedule back a few months, with SDK release in the summer, and the new iPhone landing in the fall, and it stretched out the time in-between at the same time, moving it back to around 130 days. The last two releases have both seen exactly 102 days from SDK to customer availability. When Apple last introduced an entirely new hardware category, in 2010, it gave would-be iPad developers just over two months’ lead time.

As we approach the possible launch of new hardware in at least one category (wearables) and possibly two (smart home), it’s worth thinking about how this pattern might apply to these new categories. What’s most striking this time around is that I think it’s entirely possible that Apple has already done the SDK releases that will power these devices, and we therefore won’t see the long delay between the announcement of new hardware and its availability to the public. Apple has already laid the groundwork for new wearable devices as follows:

  • In iOS 7, announced in June 2013 and available since September 2013, Apple tweaked the Notification Center and augmented Bluetooth capabilities to support better off-device notifications, for example on a smartwatch or similar device (Pebble and other third party smartwatches already make use of these)
  • in iOS 8, announced at this year’s WWDC and presumably available in September 2014, Apple created HealthKit and the companion Health app, which can capture data from sensors in wearables and store and analyze them for users.

As such, depending on Apple’s implementation of wearables, it’s possible that it’s already given developers all the tools they need to create apps that will take advantage of whatever Apple releases. There may not be an “iWatch” SDK as such. If that’s the case, we could see the pattern shown in the chart above blown away completely with the release of wearable devices from Apple. Or, put another way, Apple has already started the clock ticking by releasing the SDKs to developers, and now we just need to wait for the other shoe to drop. And of course, if you believe the rumors about the smart home, the very same pattern would apply there – the necessary tools are all already out there in developers’ hands in the form of HomeKit.

If Apple is indeed planning an iWatch rather than something similar, it might need an SDK of its own for the on-device display, but if – as I suspect – what Apple ends up releasing looks a lot less like a watch and more like a much simpler device, then I think all the pieces may already be in place. On Monday, I’ll talk more about why I think what Apple releases might not be a watch at all, and why I think there will probably be several devices rather than just one.

Nadella’s manifesto

Satya Nadella today wrote an email to Microsoft employees, which was simultaneously published on the Microsoft website. We’ve had glimpses and snippets of Nadella’s vision for Microsoft over the past several months, but this is the first time we’ve had the whole thing laid out in clear terms, and it marks something of a strategic break with the Ballmer era.

The most visible sign of this is the dismissal of “Devices and Services” as the descriptor of Microsoft’s strategy and mission. This was the vision Ballmer cooked up in his last couple of years at the company, as he sought to find a way forward for Microsoft in the face of serious threats to its two biggest businesses – productivity and operating systems. It did one thing well: recognized that operating systems would in future be monetized through hardware sales, and that productivity software would be monetized through services. But that was about as far as it went. Neither Ballmer nor anyone else at Microsoft ever really articulated how the two fit together, or how Microsoft would bridge the competing demands of providing the best services on any platform versus providing devices that offered truly differentiated experiences.

I do think the two could have been rationalized, as I’ve written elsewhere. Ultimately, a devices and services strategy properly executed would have meant creating really compelling services and then having Microsoft devices serve as the best possible instantiation of those services. But Microsoft was never really able to articulate that vision, and in the process created some really awkward questions for OEMs about why Microsoft was competing with its partners, first with the Surface and then with the Nokia devices acquisition. The fundamental problem, though, with Devices and Services as a strategy, was that it was never fleshed out, and thus was mostly a description of new business models for its two existing businesses, rather than a true vision for transforming Microsoft. It also never answered the question of what Microsoft was really about, or why it does what it does.

Satya Nadella’s new strategy replaces the Devices and Services pairing with another: Productivity and Platforms. On the surface, that could seem like a startlingly unoriginal vision for the Office and Windows company – more of the same. But drilling into what Nadella actually means by those two things shows that he has a much more expansive vision of what both terms signify, but one that’s rooted in the things Microsoft is good at. That’s a subtler shift, and we have yet to see the full implications of it. But it positions Microsoft as an enabler of its users, both enterprise and consumer, rather than a seller of devices and services, and that’s an important change, because it speaks to potential customers rather than merely to investors.

The other major implication of all this is a refocused Microsoft, one which sees “dual users” (a term that Microsoft uses to describe what others have called “prosumers”) as its target market. It’s in some ways an admission of defeat in the broader consumer market, and a statement that it’s going to focus on the narrower segment of people who see “getting things done” as a major reason to buy a personal device or use a consumer service. There certainly is a substantial segment of the population that views getting things done as important when selecting a device vendor or online service, but I suspect it’s a minority.

The other challenge is that, as Microsoft has been broadly absent from the smartphone and tablet markets for the last several years, people have found plenty of other ways to get things done without Microsoft’s help. Given its slow response to the demand for Office on the iPad, for example, it now faces much more of an uphill battle than it would have done had it embraced that opportunity before many alternatives moved in to fill the void. The same applies to many other domains where Microsoft has lost a step over the last few years.

Where Microsoft seems much better placed is in the broader platforms business, beyond traditional device-based operating systems, in what Nadella calls “Cloud OS” in his email. Microsoft was the only one of the big three consumer technology companies to split its developer conference keynote into two, and it did it to focus almost entirely on this opportunity in the second part. With Azure at the center, Microsoft is building a truly device- and platform-independent set of cloud services and infrastructure for developers, and doing well at it. But this revenue stream today is a small fraction of Microsoft’s overall revenues, at a couple of billion dollars a quarter across both its Enterprise and Cloud services businesses. Cloud Services itself – which also includes Enterprise Office 365 revenues – is smaller than Microsoft’s online advertising revenue, though growing much more quickly.

One upshot of all this is that we may be looking at a smaller Microsoft over time.  Last quarter, Microsoft’s revenues actually shrank year on year for the first time in a couple of years. If Microsoft yields much of the consumer market to competitors while focusing on a narrower segment, it could see revenue declines in some historical areas along with smaller growth in the new areas it’s successful in. But once it crosses the chasm from its historical highs to a new, refocused business, it should be set for better growth again. At least Nadella seems to be seeing Microsoft’s strengths and weaknesses clearly and taking steps to reshape the company in the right mold. There are also hints towards the end of the email about efficiency, streamlining and flattening in the organization, which could be read innocuously as having the same team operate more efficiently but could also be seen as an indication that some cuts may be coming.

Lastly, it’s interesting to see the word “privacy” pop up four times in the email, and particularly interesting in the context of the fact that it was never uttered during the keynotes at Build (security was mentioned, in the context of the enterprise). This was a recurring theme at Apple’s WWDC, and although Microsoft’s Scroogled campaigns arguably haven’t been that effective, there seems to be a sense at both Apple and Microsoft that privacy can be an effective competitive vector against Google if done right.

Nadella still hasn’t given us many specifics in terms of what this will all mean for new products and services at Microsoft. But he has now at least given us the framework for thinking about where Microsoft might go next, and how it sees its mission in the world. That’s going to give the company some valuable direction and focus following several years of seeming a bit lost. But as with any strategy, the devil is in the execution, and we’ve seen very little of how Nadella will deliver on that yet.

The three problems with Android Wear

I’ve been using an Android Wear device – the Samsung Galaxy Live – since I picked it up at I/O last week. I’ve tried a number of other smartwatches before now, and it’s interesting to see the differences. As it’s currently constituted, I see three flaws with Google Wear, two of which seem to be pretty fundamental, and one of which should be fixed soon:

Cards are a bad UI for small screens

Cards make a ton of sense on smartphones and tablets and on the web, where they provide useful visual separation between discrete chunks of information, and they work well on Twitter.com, in Google Now on smartphones, and elsewhere. But on a space-constrained screen they really don’t work because they’re a terribly inefficient use of screen real estate. There are several different layers of information in Android Wear, as shown in this triptych:Android Wear triptych 560px

The first screen is what you see before you interact with a card – the card stays in the bottom half, and takes up just a third of the screen. The amount of information presented is extremely limited. If I then interact with the card, I get the middle screen, which is slightly richer but still takes up only half the pixels on the display. If I then swipe, I get even more information as shown on the right. But the card still only takes up half the screen. Compare this with the Galaxy Gear 2, which (though not a paragon of great UI) uses the whole screen to display notifications. This is a minor annoyance with the weather card from Google Now, but it’s really annoying when a notification comes in about a new email, and just a tiny amount of the email shows by default – I almost always have to tap on the small card to make it big enough to have a real sense of what it’s about. The “glanceability” factor just isn’t there.

The cards UI, with its limited use of the screen space, and the rest given over to a background that really adds nothing, is just not a good fit for such a small screen. It’s a great example of the problem with applying a single design language, essentially without modifications, to multiple form factors. It’s a problem that Microsoft has struggled with too in the form of Windows 8, and one that Apple so far seems to have managed to avoid in providing useful integration between iOS and OS X without taking things too far.

Google Now is still too much just in case and not enough just in time

Continue reading

A review of early Android Auto and Apple CarPlay support

Apple announced on Tuesday that it had added several new auto manufacturers to its list of partners for its CarPlay automotive platform. Given Google’s official launch of Android Auto last week, we now have two major platforms looking to do very similar things in the car: namely, extending certain smartphone functions to the in-car display. I thought it would be useful to have a quick look at how the two platforms are shaping up in terms of their support from major automobile manufacturers.

Here’s a summary of support by the major manufacturing groups 1. A full list by brand follows at the bottom of the post.

Android Auto and CarPlay support by major manufacturing groupWhat’s striking is that there is no clear pattern between the two sets of companies. Both companies have just under 30 total brands supporting their platform, and there’s no clear separation between luxury and non-luxury brands, as one might expect given the the market segments iOS and Android skew towards. Yes, Ferrari and BMW are CarPlay-only for now, but Maserati, Acura and Infiniti are currently only supporting Android Auto. There are major groups that appear to lean one way or the other – the VW group, for example, appears to favor Android Auto, but its Audi brand is on both platforms, while Peugeot Citroen is CarPlay only.

There are quite a number of sub-brands which are not on either list yet – particularly where a manufacturer has a core mid-market brand with high-end and low-end sub-brands: GM’s Chevrolet is committed to both platforms, but there’s no mention of Buick, Cadillac or GMC. Similarly, Toyota is on CarPlay, but there’s no specific mention of Lexus or Scion at the high end or low end. It’s likely that these companies will experiment with either platform or both in one or two mainstream models and then extend them to others as demand warrants. The main other marques missing are high-end luxury brands such as Porsche, Lamborghini and Bugatti.

The other glaring omission, though, is Tesla, tiny in terms of overall manufacturing share but a very tech-centric brand and one which likely shares a great deal with the target market for CarPlay and Android Auto. Tesla, of course, already incorporates a large, smart screen in its cars, and as such doesn’t have the same need to buy in something better from Apple or Google. But to the extent that users will want their own smartphones, rather than an independent car-based system, to drive their entertainment, navigation and communication experience in the car, Tesla may still want to find ways to work with Apple and Google to enhance its infotainment solution. The challenge will be that both Android Auto and CarPlay are designed to essentially take over the UI, something that makes much more sense on a traditional small car screen than on Tesla’s 17-inch display. It’s likely that it will want to build something more customized than what we’ve seen from either platform so far.

Perhaps the most cheering element of the support both platforms have received from major manufacturers is that so many of them seem to be planning to support both, even in the relatively short term. Given that the biggest objection from many users to the whole concept of a Google- or Apple-powered in-car system is that they don’t want to have to choose their car purchasing options limited by their choice of smartphone, this is a welcome trend. The best outcome for consumers would be in-car systems that either come with both platforms pre-loaded, or with the ability to activate either at any time. It seems that Volvo, Honda and Hyundai may be moving in this direction already, which again should be a cause for celebration. This will have to be part of a broader shift towards more upgradable in-car systems, which will drive demand for in-car connectivity and create opportunities for other players such as wireless carriers.

The key thing here, though, is that we’re very early in the development of this new market. Both platforms currently rely on wired connections between the phone and the car to a degree that most customers won’t be happy with. Bluetooth and potentially WiFi connectivity seem logical next steps for improving the experience. But for the most part, all we’ve seen today are concepts and some very early commitments to include Android Auto and CarPlay in some models. It will likely be a couple of years before we see broad support for these platforms in a large number of models, and the list of manufacturers supporting each will likely grow significantly between now and then.

Here’s the full listing of support by brand: Continue reading

Notes:

  1. This is a surprisingly complex exercise, given the sometimes intricate relationships between the various marques and their owners – e.g. I’ve listed Porsche as part of the VW group, but technically the Porsche company is an owner of the VW group

The limited opportunity for app install ads

Today, Twitter formally introduced its new mobile app install ads product, joining Facebook and Google in what is becoming a crowded space, with Yahoo apparently waiting in the wings too. I had a quick look at this space in the context of Facebook’s Q1 earnings a few weeks ago, but wanted to drill down deeper, especially now that we know more about app revenue through Google Play. The upshot of all of this is that the opportunity for mobile app install advertising, though growing rapidly, is not big enough to provide a significant revenue stream for all these companies. In other words, there’s gold in them there hills, but not enough to justify the gold rush we’re seeing into this space.

First, a quick primer on mobile app economics. Some of the major app companies are public, and report data themselves, while several third parties also report data on the topic regularly, allowing us to draw a few conclusions:

  • Revenue from advertising is a factor for some apps, but the vast majority of revenue today (likely between 80% and 90%) comes from pay-per-download and in-app purchases. As such, the revenue numbers for the two major stores – Apple’s App Store and Google Play – likely account for a significant proportion of total revenues from apps 1.
  • Developers pay Google, Apple or other stores 30% of their gross revenues from these stores, keeping 70% for themselves. Thus, if they’re to make a living, it will be by keeping their other costs contained within that net revenue figure. That needs to cover development costs, ongoing operating costs (salaries, hosting, care, etc.), and costs to promote apps.
  • Sales and marketing costs for most successful app makers sit between 10% and 20% of gross revenues. App install advertising will come out of this budget, and may indeed make up most of it. This percentage may be significantly higher for apps early in their lifecycle and therefore promoting themselves heavily without yet seeing significant revenue, but it will tend to return to that average over time.
  • Thus, anywhere between 40% and 50% of a typical app developer’s gross revenue may go to the store commission plus sales and marketing, leaving about half for all the other costs of running the business.

Given these facts, let’s look at total gross revenue opportunity from the two major app stores. I’ve added 15% to my estimated gross revenue from the two stores to account for the advertising opportunity.

Total app store revenues from Google Play and App StoreNow, let’s think about the size of the market for mobile app install ads, which as we’ve already said will have to come out of that sales and marketing budget. To put it in context, we’ll compare it to Facebook’s mobile advertising revenues, since Facebook is the largest player in this market today and a substantial proportion of this revenue comes from app-install ads today. In the chart below, I’ve plotted Facebook’s mobile ad revenues against two views of the app install ad opportunity – one a bull case and one a bear case. The bull case assumes that the app install opportunity is 25% of total gross revenues, and adds 15% to store revenues to account for ad revenues. The bear case assumes that the app install opportunity is 15% of gross revenues, and adds a smaller 10% to store revenues to account for ad revenues. My own view is that the bear case is likely closer to reality. Continue reading

Notes:

  1. For simplicity’s sake, I’m excluding the revenue opportunity through other stores, because they account for a tiny proportion of overall revenues. Adding them in would not significantly affect the numbers.

On the replicability of the iPhone

A couple of my tweets from a few days ago were retweeted first by Ben Thompson and then by John Gruber, and as a result I got a slew of replies on Twitter from people, many of whom misunderstood the fundamental point I was making, and the context in which I was making it. In the interest of making my intentions clearer than 140 (or even 280) characters allowed me to be, I thought I’d write a quick post on my reasoning.

First, the context for my tweets, which were arguably subtweets directed at this paragraph from a recent post by Jean-Louis Gassée:

The most ambitious rumors project 50 million iWatches sold in the first 12 months. I think that’s an unrealistic estimate, but if a $300 iWatch can sell at these numbers, that’s $15B for the year. This seems like a huge number until you compare it to a conservative estimate for the iPhone: 50 million iPhones at $650 generates $32B per quarter.

Here are the original two tweets:

The fundamental point I was making is this: as long as our bar for whether Apple should do something, or whether that thing should be considered a success for Apple, is how it compares to the success of the iPhone, everything will come up short. The iPhone has been such an enormous success for Apple that it is arguably unparalleled in the history both of Apple and of the industry as a whole. If that’s our bar for success now, we’re fooling ourselves, and if Apple were to take that approach, it would likely never launch another product again. This post explores that central context in more detail.

Measuring the iPhone’s success

Continue reading

What we learned at I/O about Google’s app revenue

With both Apple and Google’s developer events behind us now, we have some useful new numbers to play with, specifically on the amount both companies have disbursed to developers. In today’s Google I/O keynote, Google announced that it had paid developers $5 billion over the past year, and that this was 2.5 times what it had paid developers in the previous twelve-month period. This gives us some really good numbers to start plotting overall Google Play developer payments for the first time. The Wall Street Journal also reported today that Google is now retaining almost all of its 30% cut, as does Apple, rather than giving the majority to carriers as it once did. This, in turn, allows us to calculate Google’s revenues from Google Play as well.

Google is catching up quickly in payments to developers

First, a comparison of quarterly developer payments on both platforms. I’ve filled in the blanks with a nice smooth curve on the Google Play numbers, and although my fairly accurate estimates on the iOS side are pretty lumpy too I’ve smoothed that curve as well to make them easier to compare. (The reality is developer payments go up and down because app spending goes up and down as new devices ship and are sold in large numbers around major launches and the holiday period, for example.)

So here’s a chart comparing developer payments from the two companies since the inception of their respective paid app stores:

Google and Apple developer payments Continue reading