Summary: In the last quarter of 2009, Apple made more money from smartphones and applications than the formerly dominant Nokia. The contrast between their approaches to developer communities reveals important lessons in the design and management of ‘two-sided’ business model ecosystems.
...Members of the Telco 2.0TM Executive Briefing Subscription Service and the Dealing with Disruption Stream can access the full item here. Non-Members, please see here for how to subscribe, or email or call +44 (0) 207 247 5003.
Introduction
This Analyst's Note describes how Apple have caught and passed the once dominant Nokia in the smartphone sector, contrasting their differing approaches to enabling and incentivising developer communities, and identifying key success factors.
For all those seeking to develop ‘two-sided' telecoms business models, developers can be very important players in the ecosystem, both as upstream customers, and as enablers for other upstream customers. Addressing their specific characteristics and needs is therefore an important component of systemic success, and this Note also articulates four strategy questions to help clarify how to achieve this.
Apple now makes more money from the smartphone sector than Nokia, although Nokia still has twice the overall market share. Where the market for high-end mobile devices was once dominated by Nokia, Sony-Ericsson, and HTC, it's now split between Nokia, Apple, and RIM.
Figure 1 – The Smartphone Market Vs Apple and Nokia Sales
Source: STL Partners/Telco 2.0
Apps helped Apple escape the Market ‘Squeeze'
The Smartphone market has also been growing steadily, having turned the corner in Q1 '09, while prices have fallen. As we suggested at the beginning of 2009, the industry faces a massive mid-market squeeze - the top end is being absorbed into smartphones, the bottom end into ultra-low cost shanzhai. The vendors in the mid-market, like Motorola and SE, turned out to suffer the most in the world economic crisis.
A key phenomenon in Apple's success was that they succeeded in creating an entirely new market sector - mobile software. Of course, mobile applications development existed before the iPhone, but it was tiny in economic terms, dominated by vendor in-house work, and mostly still potential rather than reality. Now, there is a vigorous industry of applications developers, selling mostly to end-users. Installing software on a mobile device has become normal behaviour, as has paying for it.
In the desktop computing world, it's always been applications that sell hardware - this insight drove the success of Microsoft. Apple catastrophically misjudged this in the 1980s, by trying to sell its development tools to the developer community while Microsoft was giving them away - it's fair to say they are determined not to make the same mistake. And we know that devices are a key driver of churn between mobile operators. Therefore, the developer community has become a pull-factor for subscriber recruitment and usage in mobile - T-Mobile UK is currently running a major advertising campaign centred on "smartphones with apps".
The benefit of honest hindsight
Back in January, 2007, we were just a little sceptical about the Apple iPhone, as were so many others. Yes, it was a pretty gadget, demonstrating Apple's historic mastery of industrial design and product-management. But it was quite light on features - you may recall the original didn't have things like a cut-and-paste interface, a decent camera, or a 3G radio, and there were some fairly impressive radio performance issues - and expensive. Perhaps we didn't feel it was quite serious and telco-ish enough to care about.
Now, three years down-range, it's proven to be the hit of the decade. Apple has emerged as a serious player in mobile; essentially every other manufacturer has found it necessary to offer a barrage of large touchscreen devices that look more than a little like iPhones; AT&T and quite a few other carriers have been forced to build up more data capacity and expand their WLAN hotspot interests to meet a surge in demand for data. Rather than Asia or Scandinavia, the innovation in mobile moved to Silicon Valley; nobody predicted that.
Now that our analysts have finished flagellating themselves over their original misplaced scepticism, we've resolved to ensure that we bring the lessons of why Apple has been so successful to our customers.
How did Apple do it?
First of all, Apple addressed its existing developer community. The iPhone as a development platform was promoted through their existing channels to the community, and its design maintains a high degree of commonality with other Apple products.
Apple made it easy for developers
The iPhone's operating system is a cut-down version of OS X (itself, essentially BSD Unix), the applications environment is Cocoa, also used on the Mac, iPod, and friends, the Web browser is Safari/WebKit. This use of existing development assets meant that the minimum technical investment to make a start was kept as low as possible. Existing Apple developers could download the SDK and start work with their usual toolchain, working against APIs that were very similar to the ones they normally worked with. This gave the community vital initial scale.
Apple also designed the whole system-of-systems around the iPhone to fit with the software developer's own business processes. To build an application, you need to understand the technology - read the docs, try out the APIs, look at examples - identify a need, write code, test it, debug it, deploy it in beta, fix the issues that come up from user testing, deploy in production, and maintain it.
It's worth laying special stress on the fact that this linear production process contains a feedback loop - once the first code is written, it needs testing, and once tested, it needs debugging or improving. It's never done in one run through, and there are multiple break points at which you may need to return to the "write code" phase. Debugging is one - user testing is the next. Therefore, the speed and efficiency of the test-debug-test loops tend to determine the pace of production. Anything that either facilitates test, deployment, and debugging, or reduces the number of test-deploy-fix cycles required, will improve productivity and quality more than any other change along the line.
Apple responded to these needs by:
integrating the iPhone's software development process with the standard Apple toolchain, thus getting rid of a source of errors and minimising the need to learn new tools
minimising the barriers to actually running your code on a development device
creating a deployment mechanism
encouraging the use of its tested user interface and system elements.
The only 100% reliable way to avoid coding bugs is to avoid coding; maximising your use of things like the iPhone system API and the Cocoa user-interface primitives minimises your opportunity to make mistakes. This can be seen as a poka-yoke, or "mistake proofing", mechanism.
Figure 2 – The software cycle
Source: STL Partners/Telco 2.0
The process controlled approval without killing speed
Like most mobile vendors, Apple found it necessary to implement an approval mechanism for applications - partly to guard their reputation for user-interface excellence, and partly because of the special status of voice as a privileged, safety-critical application with money attached. Unlike the others, they chose to implement approval after the test cycle - you finish work on the application, and submit it for approval. Nokia/Symbian developers need to get their code signed, which can require approval, before executing it on their own development devices for the first time, and every subsequent time they change it.
In the Apple software-production process, then, quality is inherent and an enabler - in the Symbian one, sadly, it is external and an imposition. This corresponds closely to the distinction between a lean production shop and a traditional mass production one - in one, it is assumed that workers will produce as many mistakes as they can get away with, and inspection must stop them, in the other, it is assumed that errors are the inevitable product of the system, and the system must change to preclude them in advance rather than detect them later. The final check serves more to monitor design than quality, whereas a Symbian application can be as ugly and unfit for purpose as human hand can devise as long as it gets all its boxes ticked.
iTunes: effective distribution and generous terms
Having built, tested, and approved an application, the next challenge for a developer is to get it deployed to users and hopefully to sell it. Apple already possessed a robust system for distributing paid-for content, iTunes, and the iPhone was integrated with it. This was a selling point in itself, but the next step was to link the software production process with the iTunes backend and the iPhone operating system. The App Store is the name given to this complex of systems. It provided one-click acquisition and installation of applications, with quality assurance to the user thanks to the approval mechanism. As usual, Apple integrated it prettily with their software UI and hardware design.
There is a final, crucial element in this complex supply chain; MONEY. Using the e-commerce elements of iTunes, Apple could offer the ability to sell applications, and a far better upstream user experience than anything else in the mobile industry. Typical mobile payments methods at the time of launch offered payout cycles of up to 90 days and transaction costs up to 50%. Better options were available for those who could negotiate a special deal with a carrier, but that was restricted to the very biggest players, and further restricted the addressable market to that operator's subscribers. Apple's revenue share formula was more generous by far - 70% of the selling price goes to the developer - and it paid out every month, straight into your bank account.
Overall, Apple improved the developers' business model
To sum up, Apple succeeded in creating an integrated system-of-systems that facilitated rapid applications development, deployment, and monetisation for upstream developers, one-click acquisition and installation for end users, and end-to-end quality assurance. They did so by concentrating on the following key interfaces: between Macintosh development and iPhone, between the developer and the iPhone OS, between independent software vendors' business processes and Apple's, and between Apple and the end user.
Figure 3 – iTunes, central to the iPhone system of systems
Source: STL Partners/Telco 2.0
At the technical level, this involved re-implementing the Apple development environment for mobile and integrating it with their content distribution system and the iPhone user interface. At the operations management level, this involved creating something like a multi-firm lean production process. At the strategic level, this involved a decision to reprise Microsoft's applications-sell-hardware-sells-Windows strategy in order to ship high-margin devices and recruit users into the Apple product line.
This decision had as an inevitable consequence that providing an excellent upstream user experience for developers was a top strategic priority.
But why didn't Nokia do it 5 years earlier?
To read the full article, covering...
What did Nokia Miss?
The broken app development cycle
Nokia's Strategic Miscalculations
How Nokia may have learned the lesson
Conclusion
The four key strategy questions
...Members of the Telco 2.0TM Executive Briefing Subscription Service and the Dealing with Disruption Stream can access the full item here. Non-Members, please see here for how to subscribe, or email or call +44 (0) 207 247 5003.
