26 November 2011

Microsoft, iPads and the Innovator's Dilemma

This article was motivated by listening to Episode 44 of Hypercritical, the episode of John Siracusa‘s weekly podcast that focused on the question “What Ails Microsoft?”; listen to it for context. I agreed with most of Siracusa’s analysis, but thought he missed a few key insights and perspectives.

You should listen to Siracusa’s podcast, but here are some of the key points in his analysis of what ails Microsoft are:

  • Microsoft consistently refuses bet-the-company radical changes that will be good for the user and its own long-term business prospects because it are scared of damaging its cash cows (primarily Windows and Office, but also servers, Exchange etc.);
  • Microsoft serves primarily PC vendors, IT departments, backward-looking developers and perhaps Intel rather than its end-users; this leads to poor user experiences;
  • Microsoft follows rather than leads and so is always behind the curve (think Bing, XBox, Zune, Windows Phone etc.)
  • Microsoft underestimates its own position of strength, which would in fact allow it to upset its customers more (to everyone’s long-term benefit) for fear of losing what it has;
  • The demands of its core customers for a roadmap mean Microsoft always overpromises and underdelivers, has low marketing impact and never surprises competitors etc.
  • Apple is the reverse of all this, repeatedly taking bet-the-company risks, always focusing on the end user, repeatedly canibalising its own products, being secretive and never publishing roadmaps, constantly leading and redefining categories (without necessarily being first mover), all in manner of what Steve Denning calls Radical Management, which has led to its current position as the world’s most valuable company.

While I agree with most of these points, here is what I think Siracusa missed.

Clayton Christensen and The Innovator’s Dilemma

Clayton Christensen‘s The Innovator’s Dilemma is the best business book I’ve ever read. Unusually, it contains a thesis that can’t be reduced to a single sentence. His interest is in how great companies get overthrown by disruptive innovators. His key ideas are as follows:

  • Christensen defines a disruptive technology as one that is worse than the incumbent technology on the key metrics that are usually used to measure quality in that space, but better in some other, traditionally less important metrics.
  • Although he offers several examples, Christensen’s clearest example is disk drives. Here, the two traditional key metrics are speed and capacity. Disk technologies have been replaced in waves, first with 8” disks being replaced with 5.25” disks, then 3.5” disks, then 2.5” disks then 1” disks. (Solid-state drives are now gradually starting to replace rotating disks.)
  • Christensen argues that incumbent leaders almost always succeed with sustaining (non-disruptive) innovations that improve the performance of the technology against the standard metrics, but almost always fail to bring to market new disruptive technologies, even though these are often first developed by the market-leading company. He says this happens primarily because leading companies tend to be “well managed”, and are strongly influenced by their best customers and partners, who are, almost by definition, mostly bought into the existing metrics. So when, for example, Winchester (the leading 8” disk manufacturer) asks its customers “would you be interested in lower power, physically smaller disk that has lower speed and less capacity they say “no, that’s a terrible thing, we need speed and capacity”.
  • New entrants, often start-ups, see an opportunity to serve new markets, often consisting of people not using the incumbent technology, for whom the alternative metrics (in this case, size and power consumption) are more important than the traditional ones. For example, 8” disks didn’t work for PCs but 5.25” disks did; 5.25” disks didn’t work for laptops but 3.5” disks did (and then 2.5”); 2.5” disks didn’t work for iPods but 1” disks did. Now solid-state memory, which is fast but expensive/lower capacity, works for phones, cameras, tablets etc. in a way that even 1” disks didn’t.
  • A key point Christensen makes is that the new market, of non-consumption, is often unattractive to the incumbent leader, who typically sees it as small and offering low margins, but is highly attractive for newcomers, who typically hone themselves on lower margins as they serve it.
  • Over time, sustaining improvements to the new technology tend to improve it against the traditional metrics as well as the new ones: current 3.5” disks have much larger capacities and better latencies than did early ones. As they improve, they become more viable in increasing parts of the “old” market, and the old leader tends to be reduced to ever smaller, more niche parts of the market. Eventually, the new technology tends to get good enough for mainstream use and at this point the advantages of the new technology start to be more interesting to old customers. (“So I can enough speed and capacity, but with a smaller footprint, less power consumption and a lower price: well sure!”) If it survives at all, the previous leader ends up serving only the very high end where the extremes of the old metrics are required.

iPads, PCs and the Innovator’s Dilemma

Apple was not the first to come up with the idea of a Tablet PC. In fact, Alan Kay came up with many of the key ideas in his remarkable 1972 paper on the Dynabook. But in the more recent past, Microsoft (especially Bill Gates) championed tablet computers and brought them to market a decade before Apple built the iPad. Microsoft, however, saw a tablet, through the ever-present and distorting lens of its Windows cash cow, as an enhancement to a traditional Windows PC: you add a touch-screen (and a stylus) to traditional laptop running (of course) Windows and voilĂ , a tablet is born.

The iPad received a very luke-warm reception when it was launched, and was widely derided as (merely) a giant iPod Touch. It was criticized for being underpowered, closed, not running even standard Mac applications, let alone Windows software, not supporting “true” multi-tasking or windowing and more besides. Yet it quickly sold in the tens of millions and is clearly now replacing PCs for some people.

With some caveats, this fits Claytonsen’s model very well. The iPad is a worse general-purpose computer against the traditional metrics. It has slower hardware (though rarely feels slow), few ports, no user accounts, comparatively little storage, no hardware keyboard, limited, vetted software and (cough) no true multitasking, no Flash, no replacable battery and limited upgrade options.

But look at the alternative new metrics, that show all the ways in which it is better for some people and purposes. It is extremely small and light. It is fantastically easy to use. Thanks to Apple’s control-freakery, installing software is simple and worry-free. It has a touch screen. It has no significant issues with viruses etc. Its battery genuinely lasts over 10 hours even when you use the machine intensively. It has stores for software, books, music and videos built in (and it probably already knows your credit card number). It has numerous sensors (cameras, microphones, accelerometers, gyroscopes and more). Software for it tends to be really cheap and some of it is of fantastic quality. It is supremely relaxing to use.

For people who mostly surf the web, do light email, play games, watch films, read books etc., the iPad is not just a “good enough” alternative to a laptop or even a desktop PC: it may actually be signficantly better. The iPad 2 (and iOS 5) followed the pattern of sustaining improvements, both on the new metrics (usability, weight, size, sensors etc.) and the old (speed, capacity, ability to link to an external monitor, multitasking etc.).

Crucially, while Microsoft saw a tablet as a way to extend the PC, and added Touch features to Windows and made its tablet PCs full Windows PCs “with added Touch”, Apple redesigned all the upper layers of the operating system to give the best possible experience for the iPad as a new class of device. It didn’t worry about disrupting sales of its own Mac laptops, still less (naturally) those of Windows PCs: it just made the iPad as good as it could, in its own right.

Risk and Perfect 20-20 Hindsight

The other major point I feel Siracusa failed to make, and many people are missing, is that Steve Jobs’s and Apple’s Radical Management is a genuinely high risk strategy: it can fail as well as succeed, and frequently does so. I think we need to separate out two ideas that I feel are being conflated. The first is “betting the company” on an uncertain new thing, which isn’t necessarily a good idea for a leading company, but makes more sense for a struggling company. The second is the the aggressive development and marketing of new technologies that might canibalize your existing business; this probably is a good idea, even if the new business is lower margin or lower value, because almost certainly someone will do it, and it’s better for the leader to do it to itself than for a competitor to do so.

113/365: Flippin' coins

[Image: Flippin’ Coins , by Pauli Antero on Flickr, Creative Commons, some rights reserved.]

In terms of the risk side, a comparison I like to make is with finding lucky people. Contrast two situations. If I say to you “Give me a coin and I’ll toss it ten times and get heads each time”, and then I do it, you’ll probably think that is quite impressive and either very lucky or (more likely) manipulated. But if I take a thousand people and get each of them to flip a coin repeatedly, and after each round of flipping I get all the people who got tails to stop, after 10 rounds I might well have a single person who got a sequence of 10 heads. But there would be nothing odd about that, and it certainly doesn’t require the person to have special powers or be “lucky” (in any non-scientific sense).

Apple now has the largest market capitalization of any company in the world, with massive success and profits, after a series of audacious, high-risk moves that worked out. I’m not saying for a moment that this is pure luck, or that Apple is like the one-in-a-thousand kid who got ten heads in a row, but I do think that the world has annointed Apple after the fact when many other companies have made “audacious” moves that didn’t work out and, in some cases, sent them under. (Time-Warner’s merger with AOL was certainly audacious.) I think the modern Apple has made a series of good moves, and combined those with backtracking where necessary (allowing native apps, giving Final Cut Pro a stay of execution, allowing various apps and books into the stores after poorly judged bans etc.), and has won for reasons that combine skill and luck; but even if Steve Jobs had lived, that doesn’t mean he didn’t have more lemons in him, and that these might not have come out and eventually hobbled or even killed the company.

Even today, when Microsoft is routinely left off the list of the key tech companies (now typically Apple, Google, Facebook, Amazon), or is at least seen as the laggard among these, it remains massively profitable and powerful. I think it is in terminal decline, and deserves to be, but it is far from irrelevant yet.

02 November 2011

Everyone Needs a Little Privacy

I’m delighted to announce two new features in Fluidinfo—the existence of a private namespace for everyone, and the creation of a readable Fluidinfo version number. Thanks are due to Jamu (@jkakar) and Manuel (@ceronman) for implementing these changes. They were both my requests/suggestions, so blame me if you hate them.

The private namespace

If you have an existing Fluidinfo account, you will now find that you now have a top-level namespace called private. If you had such a namespace anyway, it won’t have been touched, but if you did not, it has been created, and all of its permissions have been set, as the name suggests, so that only you can access it.

Using Fish (or the online version at http://shell-fish.appspot.com), you can see this by using the ls command. So for me (logged in as njr), I can get a Unix-style listing of the permissions with:

$ fish ls -ld private
nrwc------   njr/private/

or a more detailed, Fluidinfo-style listing by saying

$ fish ls -Gd private
njr/private/:

NAMESPACE (/namespaces)
  Read
    list (read):        policy: closed; exceptions = [njr]
  Write
    create (create):    policy: closed; exceptions = [njr]
    update (metadata):  policy: closed; exceptions = [njr]
    delete (delete):    policy: closed; exceptions = [njr]
  Control
    control (control):  policy: closed; exceptions = [njr]

New users registering from now on will also have this namespace created for them, with the permissions set to private.

We have given everyone a private namespace by default for two main reasons:

  • It means that, without having to know anything about how the permissions system works, all Fluidinfo users have any easy way to create both private and non-private information: if you want your data to be public, by default all your tags not under the private namespace are readable by everyone (but writable only by you); where you want data to be private, just use a tag in your private namespace.
  • Just as importantly, we expect that many Fluidinfo applications will now place some data in a user’s private namespace (as appropriate) and some at the top level, or in other namespace that aren’t private by default. So an application to allow users to share clipboard between devices, for example, would probably use private tags by default, but a rating application would be more likely to use tags that are public by default.

Just as most people never change any file permissions, we expect that most Fluidinfo users will not want to be messing around with tag permissions, and this change means they should not have to do so.

FAQ

  • Q1: I hate this: I don’t want a private namespace! Can I get rid of it?

    A1: Of course. You can safely delete the private namespace. In Fish, assuming you haven’t added anything to it you can do this simply by saying:

    $ fish rm private

    (The fish part of all these commands can be omitted if you are using the online version of Fish.)

    Or, if you prefer, you can alter the permissions on the namespace to make it non-private. For example, if you say

    $ fish perms default private

    that will reset the permissions on the namespace private to the defaults (making it readable by everyone, but writable only by you). I wouldn’t particularly recommend this course, but it’s up to you.

  • Q2: I already had a namespace called private, but its permissions aren’t set correctly. How can I fix them up?

    A2: You can do this with Fish’s perms command:

    $ fish perms private private

    Note that this only changes the permissions on the private namespace itself. If you have tags or namespaces under it, their permissions will not be affected, but new tags and namespace that you create under private after this change will be affected. (I will add a -r option to Fish soon, for recursive permissions changes, but it isn’t there at the time of writing.)

  • Q3: I used private as a tag: have you just trashed all my private tags?

    A3: No. Fluidinfo is quite happy for you to have a tag and a namespace with the same name. If you had a private tag, this hasn’t been affected at all by the new private namespace.

  • Q4: Is everything under my private namespace private?

    A4: If we’ve just created the private namespace for you, yes; but if you had one already, it depends:

    A few months ago we made a change to Fluidinfo so that when a new tag or namespace is created, it inherits permissions from its parent namespace. So everything works as you would expect, and if you create new tags and namespaces under your private namespace, everything will work as any reasonable person would expect.

    It is important to note, however, that the Fluidinfo permissions system is not hierarchical, in the sense that changing the permissions on a parent namespace has no effect on its existing child namespaces and tags.

  • Q5: Will I run into problems if I buck the trend and don’t have a private namespace called private or if I make other tags and namespace private?

    A5: No. It is obviously possible that Fluidinfo applications you use might make assumptions that your private namespace is private, or that it exists, or even that tags not under your private namespace are public, but such apps would be making unjustified assumptions.

    There should certainly be no problem at all with making any tag or namespace you like private, whether it is under the private namespace or not. Indeed, you can make your top-level namespace private if you like (though again, doing so will only affect new top-level tags and namespaces).

    But if you don’t have a strong philosophical objection, your life probably be simpler if you go along with having a namespace called private, and probably by making its contents private too.

Fluidinfo API Version and Release Date

The other small but useful change is that Fluidinfo is now publishing information about the versions of the code and API deployed.

Every time a new version of the live Fluidinfo code is deployed, the tag fluiddb/release-date on the object with about tag fluidinfo will be updated. This is a plain text string (MIME type text/plain) in ISO8601 extended format. Because it is a plain-text string, you can view it in a browser at

http://fluiddb.fluidinfo.com/about/fluidinfo/fluiddb/release-date.

or with Fish by saying

$ fish show -a fluidinfo /fluiddb/release-date
Object with about="fluidinfo":
  /fluiddb/release-date = "2011-11-04T17:40:27Z"

The intention and commitment from the team is that every time the live Fluidinfo code changes, this release date will be updated (even if there is no intended change to the API). This obviously allows library and application writers to make statements such as:

Fish version 4.12 has been tested with the Fluidinfo release of 2011-11-04T17:40:27Z and all tests pass.

(which is true).

There is also an API version published using the tag fluiddb/api-version on the same object. Again this has MIME type text/plain, and can be viewed at

http://fluiddb.fluidinfo.com/about/fluidinfo/fluiddb/api-version

It can also be displayed using Fish with the command

$ fish show -a fluidinfo /fluiddb/api-version
Object with about="fluidinfo":
  /fluiddb/api-version = "1.13"

This is updated whenever a deliberate change to the API is made. If, at some point in future, multiple APIs are supported, the intention is to extend this to be a space-separated list of APIs supported in the current release.

The API change log can be viewed at

http://doc.fluidinfo.com/fluidDB/api/changelog.html

and I’m guessing that from this point forward the change log will include the API version numbers for new features.

Labels