Innovation: Beware the cool idea

I’m reading What Would Google Do by Jeff Jarvis. The chapter on New Imperatives focuses on encouraging, enabling, and protecting innovation. Jarvis attended a seminar on innovation at the World Economic Forum in 2008. In that seminar, a large group sat in a circle. Each participant shared an idea with their neighbor, creating a sort of idea mashup (See WWGD page113).

Then a scientist stood up and stopped the madness, stating that scientists didn’t develop innovation by sitting around trying to think of a cool idea. He explained that they started with a problem and tried to find a solution. To quote, “Beware the cool idea.”

The same is true in the world of APIs. In my consulting gigs I always ask companies why they are creating an API. Do you want innovation? Are you improving integration for partners? Or do you want to reduce the costs of doing business on internal projects? Are you trying to be transparent, or are you opening up because everyone else is doing it?

Frequently companies will suggest they are doing it to drive innovation. That is a good start. Better yet, ask yourself, “What is the problem we want solved?“

Somewhere in the secret laws of how to launch an API and attract developers, the word has spread that you must “do a contest” and you will get cool mashups – and recruit lots of developers. The Programmable Web contest page highlights a wide range of contests – all in the attempt to woo developers to help them innovate. One of my current projects is working with Symbian the mobile platform player and the issues are the same in the mobile space….case in point this long list of contests for mobile apps – we will pay you thousands of dollars for building a really cool mobile….we don’t know what we want it to do, it just needs to be cool.

OK, that can work. Sometimes. But if you create an API and expect millions to flock to it and create something innovative, think again. They will create something that solves a problem for them; or for you, if you ask.
So who is doing it right? Best Buy. The Best Buy Remix Challenge asks the developer community to help them solve business problems…help us sell more laptop accessories…They created a contest that was focused on developers solving a problem with their API.

Think back to the first mashup we know about – Paul Rademacher’s Housing Maps. Paul used Google Maps and Craigslist to create a visual housing search page. Why? So he could better understand the availability of apartments in an unfamiliar city.

Random innovation won’t happen. When you launch your mobile app store, your API or even a Data Store (Guardian or Wolfram), know that innovation will happen out of necessity or interest – not randomness. If you intend to launch an API and run a contest, ask the community to help you solve a problem that is worth the time and effort you are putting into the contest.

Google says, “Make innovation your business.” I say, “Make innovation about your business!”

API Value Creation, Not Monetization

On a daily basis I get questions about API monetization models. I planned on writing a blog post on the topic and in the process began trying to model monetization to verticals which led me to think about why people have so many questions about API monetization. There are two reasons: The API is a distribution channel, and when you think new distribution channel there is an expectation around revenue opportunities. And, if you are the person in your company trying to define the business case for an API to the executive team, there is a hurdle to overcome. Business executives tend to see an API as a cost center and want to know how to measure the pay-off.

The big mistake is that because the API is a whole new thing, companies expect something different than their current business. In reality companies need to start by looking at similarities to their existing business. The question that companies should be asking is “What is the value created by launching an API?”

What does that mean? It goes beyond tying your business model to your API; it is about tying your business goals to your API.

I had a chance to speak with Daniel Jacobson at NPR and he provided a great framework for the first example – NPR focused on three primary business opportunities when making the decision to launch an API. The first opportunity for NPR was the good will with the community, which would be generated by a public, open API. As a non-profit member-based organization, they could gain tremendous clout by offering open access to content.

The second was simplification of content syndication to member stations that pay dues to get access to the content for their local stations. With 800 member organizations and varying access levels syndication became complex. The API gave a standardized and simplified model for delivering content. This gave the less technically sophisticated member organizations a chance to move closer to a Web 2.0 model and many are re-writing their websites with APIs.

The team at NPR was also working on a website redesign and wanted greater flexibility in content production and deployment cycles. The API would allow them that flexibility for updates to the site.

As an unplanned upside, an unexpected business opportunity came out of the public API.  Daniel said that in the past companies had approached NPR to become a service provider for content.  With limited customization resources, only a handful of partnerships could be implemented. Their selection of these partners was based on the amount of custom work that needed to be done, as well as the total dollar value of the relationship. The API not only drove increased interest, but also gave them a standard way to make content available to non-member third parties on a contractual basis.

Retailer Best Buy has a similar story.  Kevin Matheny, the e-Business Architect and API guy at Best Buy shared the three classes of anticipated benefits their team identified.  The first was the opportunity for increased reach through affiliates; the goal was to increase “sourced” traffic by 1 % – a reasonable and achievable goal. The second was innovation on the BestBuy.com site (similar to NPR). There were things they wanted to do on the site, such as A/B testing for various functionality they thought might help drive increased purchasing on their site. The API gave them a quick and easy mechanism to try things without spending tens of thousand of dollars on site redesign efforts.

New partnerships were identified as part of the plan for Best Buy. The partnerships they were targeting included incentive programs, corporate customers, and other large volume partners. It wasn’t about thousands of new partners, but those of higher value.

On the side of the unexpected but interesting outcomes, Kevin said they have seen a flurry of internally developed business applications. In the past many valuable, internal-facing projects were turned down because the programs had to meet strict top line to bottom line ratios. With the availability to data and services, many teams within the company now have access to things they didn’t in the past, and project costs have been minimized. Throughout the company, consumers of the API have been able to launch successful projects that have created additional revenue and have reduced the overall development costs for new projects.

These are just a few examples of what I mean about value creation, as opposed to monetization. Yes, in both cases new opportunities to monetize came about – but they weren’t planned. It wasn’t about deploying content and charging on a per API call basis – all of the models tied back to their core business.

A few months ago, Tom Tague who heads up the Thomson Reuters Calais team shared some insights about their success.  Calais launched an open public API for their semantic toolkit to drive interest and adoption of their enterprise products, and ended up with people wanting commercial access. The commercial access came with requests for support and an SLA, which in turn created an unexpected opportunity for monetization. At the same time, they met their original goal to quickly and efficiently increase the pipeline for their enterprise product.

The next time someone asks you what monetization models are available, ask him or her a question back – What is the value that can be created by launching your API?

The Paradigm Shift in Web APIs

“When computing jargon slides into the public consciousness, you know something interesting is afoot. “ A journalist from the Star Ledger, a local New Jersey paper, wrote this amazing article a few weeks back that stated everything I have been feeling for a few months.

There is a major paradigm shift happening in the world of Web-based APIs and everyone needs to take notice. Over the last 5 months I have had conversations with hundred of companies that are creating business plans around something typically left to the techies – Application Programming Interfaces (APIs). Surprisingly, the majority of these companies are NOT Silicon Valley Internet companies. These are Fortune 500 companies in retail, travel, media, telcos and even healthcare. Their level of understanding ranges broadly from those who know what they hope to achieve by creating an API program and have established measurable goals, to those who aren’t quite sure what they will achieve, but know there is something out there happening and they want to be a part of it. They all know they need to do something new, different, and big to change their business. And APIs are going to play a role.

To explain the shift in what is happening I “borrowed” a great model from Forrester’s Jeremiah Owyang and his Eras of The Social Web. This new model is called the The Eras of Web API Adoption. The intent is to explain how we got to the point where everyone knows what the term API means (we already know Twitter has helped!) Note that my goal is not to categorize all the types of APIs, but to show how they were used and adopted.

The Eras of Web API Adoption

Era of Pick Axes and Shovels: The early use of Web APIs were those who had services to support the Gold Miners of the Web, the ecommerce vendors. The services they provided were the basics of shipping and payments. Yes, the folks at UPS, Fedex, USPS, all had APIs in the late ‘90s.

Era of the Internet Natives: In 2000, a pure play Internet company called eBay launched a “Listings API” trying to get more people to put stuff on their site. The goal was to get more stuff and more people. Then Amazon started using an API to drive their affiliate program. Their message: Help me build more stuff. Hoping to drive traffic and subscribers, Flickr, Salesforce, Skype, and others followed suit.

The Era of Web Utilities: In an effort to find a new place to live in Silicon Valley in 2004, Paul Rademacher built HousingMaps.com. This first mashup combined listings from CraigsList.com and Google Maps. What was amazing about HousingMaps.com is it offered a new and unique information source that was richer, and more useful, than either Craigslist or Google Maps alone. The notion of “the sum is greater than the parts” didn’t take long to catch on and has since driven creation of thousands of consumer utilities on the Web. This trend continues to grow as more content becomes open.

Era of Syndication: Internet companies and traditional content companies watched in amazement as companies like Compete gain traffic and surpassed Alexa by simplifying third party access to their information. It started with Internet companies in 2007, but by 2008 the New York Times had announced they were launching an API with access to all of their articles. The Guardian out of the UK hired Matt MacAlister from Yahoo! to run a developer program,. Mid-year NPR joined the media players looking to drive traffic and revenues with APIs. We are still in the early stages of this era. There are a few early adopters leading the way, while others look on to see how it all works out.

Era of Business Automation: In the first quarter of 2009 interest from enterprises across traditional industries such as Retail, Media, Healthcare has grown. Their interest in participating in the Social Web movement that Jeremiah Owyang outlines is why many are creating APIs (see Era of Syndication). Along the way, there is opportunity for new distribution channels and new revenue opportunities.

The Best Buys of the world are looking to drive innovation and increase revenue by creating Amazon-like affiliate programs. Tesco’s goal in releasing their API is find innovative ways to engage their customers and take more of the fewer dollars they are spending. These are primarily all Web-driven models. Internet Native player Ribbit wanted to be Silicon Valley’s first phone company and was a pure play API offering. Now traditional telco’s want to join in and their counterparts in cable want to figure out how to leverage all their assets to increase the value of the triple play.

Adoption of this model will take us beyond the Web and mobile devices, across platforms and even appliances. Netflix leads the way as their partnership with companies like Xbox will leverage APIs for syndication. We are just at the beginning of this era. I can’t wait to see what is ahead.

Over the next few posts ahead, I hope to share more insight about what is happening as enterprises continue to adopt APIs as their new distribution model across platform