kip/bot/blog

Our current Apple-besotted climate has focused many conversations on the critical, almost singular, importance of innovation in the success of an offering. My recent and regular struggles with Office/iWork, iPhoto/Aperture, Entourage/Outlook, skitch, and brightkite are making me think that we’ve fetishized innovation to the point that we’re overlooking more powerful dynamics that drive the adoption of new technologies or switching from one product to another.

EverydayUX has a post about how much web2.0 we can handle, which highlights a couple of adoption dynamics:

The biggest challenge is not only finding the ones that work best for you (or quickly recognizing the ones that don’t) but also trying to predict the ones that are going to be around for the long haul and stand the best chance of getting some uptake with your friends that might not roll in the same techno-circles as the Scobles and Winers of the world.

As I keep adding services to my day-to-day life, the challenge of integrating new ones becomes greater as they invariably begin to overlap (see dodgeball and brightkite).

Here, Alex highlights some key points:  will the product you’re considering be around; does the slight, even subtle difference between two products with overlapping features warrant a move?

I think there’s an interesting freako- micro- economic dynamic worth looking at here — in grad school, I learned it as “sticky downward.”

Mainstream economists love their maths (I love saying that) and they love smooth curves in graphs.  Smooth curves mean smooth tranfers into and out of self-equilibrating markets, the holy grail of economic policy.  Neo-classical economists like to kink those curves by reminding us that people aren’t perfectly rational price-seekers, and that many other dynamics drive even the simplest market choices.

In labor economics, a great deal of time has been spent arguing that smooth downward sloping labor demand curves are inaccurate.  In grad school, I had to learn multiple arguments against this shape, BUT the interesting one here is the argument that labor demand curves are “sticky downward”.  Take a look at the typical supply and demand curves (and ignore D2, that’s not relevant to this argument).

D1 implies that as the price of labor (P) goes down, the quantity demanded (Q) goes up.  Conversely, as the price goes up, the quantity demanded goes down.  The smooth, continuity of the curve implies that, in large markets, even the smallest shift in the price of labor will cause people to be hired or fired.

But companies don’t work that way, they are responsive to price in very lurchy, semi-rational fashions.  Many factors contribute to a ’stickiness’ that keeps people from being fired even as the cost of keeping them on increases: managers become socially connected to employees;  there are significant but hard to measure replacements costs; it’s just a hassle to can this person; no one wants to do the deed; you already have overhead; morale for the rest of the team etc. So, yes the increase in the price of labor creates a downard pressure on demand, but there’s a stickiness with labor that you don’t have with impersonal commodities like loaves of bread, widgets, screws, etc.

So what?  There’s a sticky downward dynamic for adoption of high-consideration, comlex products.  While I am sick of talking about Apple, my experience with the iPod highlights the sticky downward adoption dynamic.  I owned four MP3 players before finally buying an iPod. The hours I had spent ripping my CDs and labelling the tracks (80% of my music is classical or jazz, the worst parts of CD database information), were a massive stickiness factor. All my stuff was here, and I would have to move it there . . . is the iPod really that cool, the wheel really that nifty, the thing really that much better? In the end, I moved because iTunes seemed to have hit critical mass in its catalog and I tested a bunch of my classical CDs on a friends’ iTunes installation and saw that their CD database was much cleaner (and easier to clean) than any others. To drift into an innovation conversation for a moment, this does highlight Bill Buxton’s point that the success of the iPod goes waaaaay beyond our adulation of Steve Jobs and Sir Jonathan . . . it’s also the lawyers who negotiated the contracts for the music and the wonks who cleaned up the messy German names of composers and pieces, the complicated Kochel and Opus groupings, and the inconsistent movement notation, the people who made the data transfer faster, etc.

The point, though (I dream of the time when I can go a day and not talk about Apple or the iPod) is that the switch was very sticky . . . it took months to decide, and then weeks to actualy complete that switch, and it was a sticky, messy switch to make.

As always, the point must be made that this isn’t new. We’ve been aware of switch dynamics for years (and those of us in marketing and advertising are used to briefs that highlight whether this is a switch or join message). But there are a few notions embedded in stickiness  that make it useful for designers and design thinking people:

- sticky implies a tugging, ripping away process. It acknowledges the pains of those switches

- sticky gets us out of rational actor thinking and acknowledges the long, multi-centered process of decision-making
- sticky elevates the conversation back up to perceived value of the overall product experience rather than a mapping of individual features to something’s success

- sticky is a user-centered phrase, where innovation isn’t. To say that something succeeded because it was innovative isn’t nearly as informative, rich, or empathy-inducing as understanding how stickiness was overcome

Inspiring morning about invention, innovation, design, and the cognitive surplus. It started with reading Clay Shirky’s web2.0 expo talk on the blog White African (”where Africa and technology collide!”). On White African I read an interview of the founder of CraftSkills, Simon Mwacharo. I’m having one of the moments where accessible technology + surplus time + application to small aspects of big problems == something amazing.
Craftskills focuses on bringing affordable energy to parts of Kenya that are currently off the grid. It has a special focus on wind power because it’s more readily available and less prone to theft than solar equipment. My favorite part of the interview is the origin story. The founder knew that he wanted to do something with wind turbines, and got it moving thus:

I started with two workers. I could not afford to hire trained people so I decided to train myself first then train my two boys. Then I got a friend who repairs radios and TVs in Kibera to help me design and put together a charge controller.

There are so many powerful dynamics in that simple story.

• cognitive surplus: he saw something he wanted to do and trained himself in the skills he needed to do it

• physically accessible technology: he collaborated with friends to acquire the basic skills needed

• intellectually accessible technology: those basic skills (managing electrical power) already existed, just in another place (TV and radio repair) and partly obscured. (Intellectually accessible, doesn’t mean that it’s simple. Rather, it refers to the fact that this technology is transferable among non-experts, without need of a lab or deeper training.)

• small aspect of big problem: the problem of getting people on the grid was defined as simply as: I need to figure out how to build a charge controller

And just like that, Mwacharo is transforming the lives of thousands of people directly, and many thousands more indirectly through the promotion of an industry.

I blogged an HBR article a while back, questioning, among other things, how innovative Google really is.  Some news stories today, highlight some overlooked areas where Google is doing some interesting, potentially innovative things:

• App Engine — NYT article today talks about Google’s plans to move App Engine into the enterprise space by opening it up to 10,000 developers.  It’s a small launch, limited to apps written in python in the beginning, and it’s a late entrant to a field where SalesForce and Amazon have experience, if not dominance, but it’s a real move, based on another innovation:
• GFS — not news, not surprising, and I can’t tell if it’s good or not, but Google File System can fall under the umbrella of innovation, or innovation-friendly.  (Taking control of the infrastructure.)
• SalesForce alliance — NYT article briefly describes how Google is tying its Office apps into SalesForce’s suite of offerings to compete with MSFT.  Whether Google’s productivity apps on the web will win out over MSFT’s client or server based apps is the big question, but I have to acknowledge that the apps are lightweight, clean enough to hook into other software, and scalable.

I don’t think this makes the HBR article less silly, however.  The examples above are reminders that there are other things going on at Google beyond the usual gmail, Google Earth, ad serving, and blogger acquisition that most articles talk about.

Google’s ability to develop them and wait years to monetize them, however, still comes down to cash flow.  This still means we have little to learn from Google about innovation.

There’s probably not an agency or tech-UX company that hasn’t talked several times about adopting Google’s 80/20 rule. In the search for ways to become innovative, this is the one technique everyone seems to know and understand, at least at some level.

But, it seems like most attempts to pursue this idea suffer an early death in the face of billable reality: we need our agency folks to be billable, or we have too much work to do to hit our next set of goals. As a result, the implementation gets watered down (do what you want, but make it billable to the client), shrunk (90/10, 95/5, monthly brainstorm), or transformed into good old-fashioned pluckiness (after you work 50 hours, you can spend 10 more hours in the office on whatever you want). The simple fact is, devoting 20% of your workforce’s time is very hard to do unless you’re fabulously profitable, are tasked as an innovation engine (in which case the ratio would be reversed), or have incredibly patient money.

This month’s HBR has an article about what companies can learn from Google about how to innovate. I’ve been reading HBR on and off for about 20 years, and I seem to remember articles in this format — Summary of fabulous results, A look inside, Summary of what they do, What it means to you, Sidebars with tips and reminders of how to make it work — for Miscrosoft, 3M, Sony, P&G, Toyota and a dozen others. This one, though, pains me. While Google is fascinating and absurdly successful, I have a hard time buying into the premises of the article: that Google has a track record of creating successful products, that their R&D engine can be reverse engineered.

Start with the first paragraph, which has the line: “Not since Microsoft has a company had so much success so quickly.” Feels right, at first, but what do we mean by “so much success”? This is hard to parse, but Microsoft’s innovation success involves a wide range of products in the pre-internet days: operating systems, Office, programming languages. These are products that went on shelves and which people bought and used in large numbers. Whether you believe that MSFT innovated these products or coopted ideas and stitched them together doesn’t matter: it was a lot of complex software to code, debug, ship, and support — and the masses bought and used them.

I don’t see the parallel with Google. Outside of search, which apps have had meaningful market penetration? Gmail is a small, small fraction of Hotmail and Yahoo mail users, Google docs is a smaller fraction of Office users, Google Reader isn’t even a fraction of an established market. In terms of innovating new products that succeed in the marketplace, Google is still 80% (or more) search. Don’t get me wrong, I dig their stuff. But to lump Google’s proven success in search and unproven success in their interesting projects to MSFT’s proven successes in OSes, productivity software, and development languages is misleading. (And I think it’s worth harping on the programming languages. Visual Basic has millions of user/developers who build cool things for themselves and others and that’s a community not as web-notable as the mashup types, but arguably of equal or greater economic significance.)

Anyway, I have a hard time believing that Google, at this stage, has much to teach other ordinary companies. Google’s revenues, margins, and dominance in search are so massive that they have a cushion no other companies have. When the HBR article cites “Practice Strategic Patience”, the authors make a fair point that Google has a clear mission that ties its acquisitions of YouTube, Picassa, Urchin, Keyhole, and others into a coherent strategy. But the paragraph that follows is the kicker:

With such a farsighted mission, the short-term profitability of a new offering doesn’t seem to matter as much to Google as it might to other businesses. The company’s managers are strategically patient. CEO Eric Schmidt estimated that it will take 300 years to achieve the mission of organizing the world’s information. His 1200 quarter forecast might invite smirking; still it illustrates Google’s long-term approach to building value and capability. Google, unlike many companies, can afford its broad broad mission and collection of innovations simply because search-based advertising is a fantastically profitable product that provides cover for many unprofitable ones. The company certainly care about accumulating customers, but its executives believe that over time the model and the money will take care of themselves. at a 2007 Bear Stearns conference, Schmidt put it this way, “Ubiquity first, revenues later . . . If you can build a sustainable eyeball business, you can always find clever ways to monetize them.”

This acknowledges, in classier language, what I wrote up top, but there’s a rush past some key dynamics that make me wonder if there’s anything we can learn from Google. If it weren’t post-IPO Google, referring to a 300 year goal, and saying don’t worry about revenue let’s get people would be seen as a revisiting of dot-com silliness. Another hard-to-relate-to dynamic is the short-term profitability one. Not only do most companies lack the revenues and profits to acquire a YouTube without monetizing it, but most also lack the capital to acquire companies without incurring debt. Most companies would have to borrow and pay interest . . . so what are we to learn in that reverse engineering?

The article has a table of factors to help companies figure out how to emulate Google. The intro reads “If your company aims to improve innovation capacity, consider emulating these key attributes that have contributed to Google’s success.” The list of factors is interesting, but are they useful or new?

1. Strategic Patience — haven’t we always known this? The challenge is balancing the quarterly needs against the multi-yearly demands.  The Google is answer is to make so much money that your quarterly needs are covered and then some.
2. Infrastructure built to support innovation — Yup, but how many companies are actually doing infrastructure or analogous work?
3. Ecosystem that enables architectural control — yup, if you’re big
4. Innovation built into job descriptions — begs the question doesn’t it?(* see English language pet peeve below)
5. Cultivated taste for failure and chaos — true, this is the one point that I think we should dwell on. Learning how to be smart, wise, informed enough to manage a culture that experiments and fails, and which lets go to innovate is something that is still tied to Google profits, but which Google does seems to take seriously and approach intelligently.
6. Use data to vet inspiration — yup, but aren’t we all number-crunching these days? More important, though, Google is testing to see which works better, not what constitutes a viable product. GMail is optimized within its idiom and its small audience, but are they using to data to grow the audience substantially?

Don’t get me wrong, Google products are cool and some of them excellent, but it’s a mistake to say they’re profitably innovative. They’ve created an idea factory, built on very smart people, and have an interesting formula for advancing the current core business, the long-term core goal, and cool stuff. But I’m not sure this is a model we mere mortals with less than billions in market cap should be looking at.

(*) Begging the question is a horribly misused phrase in today’s language . . . to the point that the misuse is probably the use, but I’m terrible at letting those things go. The original, and to my mind more interesting, meaning of “begging the question” was not a fact that raises a question so powerfully as to beg it. Instead, “begging the question” was the proof of a proposition by invoking the proposition itself as a premise. In the instance above, question is begged in the sense that we want to know how to make innovation part of our culture. The answer? Make it part of people’s jobs. Doesn’t take you very far.