Six questions for Mashery CEO Oren Michels
Oren Michels
With 10 tips for success with APIs
Mashery manages APIs – the software “secret sauce” that helps media companies, retailers, Twitter, Google and others distribute their content throughout the digital universe. The most famous API-du-jour is the Twitter API. That’s the set of instructions and programming code that has enabled legions of independent developers, from companies with names like Tweetie, Hootsuite, Seesmic and Tweetdeck, to create apps and services based on the database of status updates, timestamps, account photos and geo-locations posted to Twitter. The Best Buy Remix API, maintained by Mashery, allows review sites and anyone else to incorporate product information and links to make purchases at BestBuy.com. APIs encourage mashups and wide distribution of content into the atomized universe of digital experiences across a multitude of brands. They fly in the face of traditional media business models built around monolithic branded, packaged, “build-it-and-they-will-come” content products – like web sites. APIs are all about explosive, viral distribution and use of content anywhere – and building businesses around that use. Mashery’s co-founder and CEO, Oren Michels (@orenmichels), will talk more about APIs and how they are driving new digital businesses in a conversation at We Media Miami, our annual innovation conference coming up next month (register here). He’ll be joined by Krista Thomas, head of marketing and communication for OpenCalais, a semantic web and content tagging service from Thomson Reuters that’s also built around an API to encourage widespread use, mashups and innovation by anyone. – AN
1. Company status, trends, milestones.
Mashery is nearly four years old, and has been generating revenue for over three years. We have about 70 customers and over 80,000 developers registered across the APIs we power, about half of whom are active in any given month. We make money the old fashioned way – our customers pay us a monthly or annual fee to use our API management and scaling platform. Major milestones include our founding in May 2006, first revenue in January 2007, and funding rounds closed in 2006, 2007 and 2008. Our investors include First Round Capital, Formative Ventures, .406 Ventures, and a collection of the best angels a CEO could ever hope to work with. 32 employees, the vast majority of whom are based in downtown San Francisco (and we’re hiring!!!)
Like most infrastructure, our primary competitor would be an in-house development team making a buy-vs-build decision. We tend to win against an in-house solution based on time-to-launch (days or weeks vs. months or years), feature-completeness (in-house solutions would skip a lot of what we do), cost, product roadmap, and the need for in-house teams to focus on core technology rather than infrastructure available elsewhere.
2. Some bio/personal background notes about you.
MIT undergrad, UCLA MBA. I’ve spent the past twelve years running online services companies; before that I ran a couple manufacturing companies and a comedy improv theatre company in LA called The Groundlings.
3. What kinds of companies – or which companies in particular – are doing the best at “exploding” their content and expanding their business through massive distribution of information via APIs?
When done right, the API should be a new or expanded distribution channel that extends your existing business model. If you are an e-commerce company, your API should result in more sales. If you are an ad-supported media company, it should drive more traffic or ad revenue. If you get your revenue from subscriptions, you should increase subscribers or decrease churn. If you sell data or data services, you should sell more data by enabling your customers to embed it in their app or service. We have great examples in each of these – Best Buy and etsy in retail, the NY Times and the Guardian in media, Hoovers and Open Calais with data, and Netflix with subscriptions. There are lots of others.
4. Which have struggled, and what are the key difference you’ve observed between the winners who “get it” and losers who don’t?
We worked with one media company that really wanted to make its content available by API, but unfortunately could not secure the rights to do so. Their API therefore lacked sufficient usefulness to spark developer adoption, and they eventually discontinued it.
The key things that differentiate winners are:
1. GREAT developer communication (documentation, forums, etc)
2. Instant developer provisioning – you need to be able to register for and access the API, at least in a sandbox or development version, immediately. Developers have a tendency to show up at 3 am wanting instant gratification – they want to know then and there if the API will meet their needs or solve their problems.
3. Lots of sample apps available. The reason that we saw so many google map mashups a few years ago were that there were a few great examples that got a bunch of attention, and pretty soon it snowballed.
4. Developer-friendly terms and conditions. If you tell a developer that they can’t make money using the API, they won’t waste their time using it. Remember, you’re building an ecosystem, and for an ecosystem to work you need mutual benefit.
5. Open EVERYTHING. The more flexible the building blocks, the more creative the developers can be and the more innovation will happen. If you only have 2×4 red legos, your projects will be pretty boring. Our advice is “open everything unless you have a very compelling reason to keep something closed – don’t keep things closed unless you can come up with a compelling reason to open it”
6. Don’t be afraid of cannibalism. As the saying goes, if you’re not willing to eat your young, someone someone else will eat them for you. It’s hard to have your API extend your business model if you prohibit your partners from also using the very business model you’re already succeeding at.
7. Good developer outreach, evangelism and support – like any community, people want to be part of something active and vibrant
8. A healthy mix of API use by internal developers, large partners who you work with directly, and independent developers who interact primarily through the developer site and ecosystem
9. Fair treatment of developers – you may have to change the rules, but the more frequently you do it, the less likely you are to have a happy, healthy developer community
10. Uptime and reliability – I list this last, since twitter has certainly proven you can build a massive developer ecosystem with modest success at uptime and reliability
5. News companies such as The New York Times, NPR and Guardian have set up APIs to expand distribution and use of their content. What do you think of their efforts – and how might they do more/better?
I’m a big fan of all three, two of whom (NYT and Guardian) are customers. News companies face a challenge on how to monetize content that is syndicated, and are understandably reluctant to provide full-content APIs until they are comfortable that they have found the right business model to do so. NPR has a bit of an advantage there, as a member and community supported nonprofit. But the conversations I’ve had with numerous news organizations – both our customers and our prospects – make me optimistic that they will figure out a model that makes gathering, editing, curating and distributing great news a profitable, sustainable business. It may look a bit different than it does now, but it’s not going away.
6. Paid news content, iPad: What are your predictions?
I was very optimistic about both based on the demo Chris Anderson of Wired did at TED last week. I haven’t bought a kindle primarily because I enjoy news magazines, photojournalism, and great design (whereas my wife, who is more into books than news, loves her kindle). Chris’s demo of the wired prototype on the iPad made me believe that I may be able to ditch the sack of printed magazines I bring on long flights, and in general go to a smaller, lighter bag for travel. I’ll happily pay for that – it is, absolutely, an improvement on what we have today. Of course the devil is in the details. If I need to pay more for the electronic version of a magazine than I pay for the dead tree version, that might be a problem.
This is different, though, than getting us to pay for the website version of news that we currently get for free. There’s no improvement there. For instance, I’m typing this on an 8 hour flight from Europe to the US. No way that the paywall version of a news site would have any value for me – heck, even if I preload pages, I have to remember to download the “single page” version or I can only read the beginning of a story. Good content, available in a great format that can be enjoyed offline, at a reasonable price will do just fine.
