Video and Slides - “Developer segmentation for your API”  strategy webinar »

Thanks to all that attended last week's API strategy webinar "Developer Segmentation for your API" on developer community and market size. (And thanks to our speakers @sramji  and @landlessness).

Here are the video and slides (and as always, you are free to use under Creative Commons).

Video and Slides: Developers Hate Marketing! Launching Your API and Attracting Developers »

Thanks to all that attended last week's API Best Practices Webinar #7 "Developers Hate Marketing! Launching Your API and Attracting Developers." Here are the slides and video! 

In this webinar we share our experience, best practices and toolkit for API and platform adoption. We cover creating a beautiful developer experience, audience segmentation, offline and online community, the top 10 things you need to launch your API and more.

Join us next week for the next webinar, OAuth for Your API: The Big Picture with our CTO Gregory Brail and Senior Architect Brian Pagano. We'll discuss business and operational benefits, the different versions of the spec, and answer your questions.  

Developers Hate Marketing from Apigee on Vimeo.

Video and Slides: Your API Sucks!  Why Developers Hang Up and How to Avoid That »

Thanks to all that attended last week's API Best Practices Webinar #6 "Your API Sucks!: Why Developers Hang Up and How to Avoid That" (and thanks to our presenters @earth2marsh and @landlessness).

We apologize for the audio problems during the actual webinar - but Henry - our amazing filmaker - did a great job of cleaning it all up for the video below. 

Need to transact credit card information with your API?  Then check out our next API webinar, "Does your API to be PCI Compliant" with @brianpagano, our Sr. Architect, and @scottmetzger, our VP of engineering,  is July 14th at 11am PST (sign up here!)

(for our entire video series, check out the rest of our API best practices webinars)

Need API and developer adoption?  Try a Hack Day! »

Want to launch your API with a bang?  Or get more internal adoption?

Hack Days (or Hackathons) give developers a day off to build anything they can dream up. No rules. At the end of the day, developers demo for glory and free beer.

Check out the recent FourSquare Hack Day. LinkedIn had a great one. And there are independent Hack Days.

If your API is only available to developers inside the company - even more reason. Why?

- Get the word out - Hack Day is a high profile way to drive adoption and build grass-roots excitement internally.

- Showcase innovation - with great new Hacks and product ideas you'd never have thought of.

- Get those example apps! -  need example apps and code on your developer portal?  Don't DIY or pay someone -use the best Hacks!

- Eat your own dogfood -  Find bugs before releasing your API to partners.

-Get recruits! -   Need good hires for the API team but don't want to ask?

Here are a few tips:

- Dedicate time  - give developers a full day with no distractions.  

- Team up!   Encourage developers to team up and mix skillsets.  

- Demo for glory.  Get your CEO and execs to judge demos at day's end.   The Hack doesn't have to be finished.  Prizes are nice but recognition might be enough.

- Feed me!  Beer and free food can take a OK Hack Day and make it a *great* hack day.

- Start small, but rinse and repeat.  Your first Hack Day might be small and a little rough.  Buy the 3rd or 4th time - you might have Beck playing on your lawn.

- Productize!  Have a labs page or a way to turn great hacks into real product.  

- Provide tools.  Give your developers an API console to learn your new API and debug API problems.

(Thanks to SimpleGeo for the image above)

Developers Hate Marketing: Launching and marketing your API »

Once you build your API, will developers come?

We've picked up some good stuff from our customers on this topic, many of which we've posted as developer adoption best practices on this blog.

So today we've rolled these in a new whitepaper with our friends at Evolved Media  - Developers Hate Marketing:  Attracting Developers to your API.  

Topics include some thoughts on:

• what do developers expect?
• do's and don'ts in launching your API
• patterns in successful developer programs

You can find it here, we'd love to hear what you think.

Developers ignoring you?  You can’t afford it »

Last week Will Richmond of @VideoNuze posted a fantastic piece, Comcast's New iPad App is Full of Surprises, about Comcast’s cool new iPad Xfinity remote app.

In his post, Will makes a great observation as to why the app didn’t happen years ago:

"There are many different ways to answer the question, but I think it boils down to 2 things: first, while most cable companies have invested heavily in behind-the-scenes infrastructure to deliver broadband and other advanced TV services, relatively few new on-screen services have been created because cable is largely a closed environment for application developers. Cable has been closed because cable operators have it in their DNA to be focused on control of what goes into their subscribers' homes. Letting "a thousand flowers bloom" is not in the average cable executive's mindset.

Second, and as a byproduct of this, most developers have ignored the cable environment. While Apple's App Store boasts of hundreds of thousands of innovative apps, the cable world has lumbered to deliver a tiny fraction of this amount, and at a glacial pace. It's not for lack of interest by developers; going back to the mid-90s there has been interest in interactive apps. But between the technology impediments and the cart-before-the horse negotiations over revenue splitting that cable operators inevitably get into, most developers have simply moved on to the open, flexible Internet. That's been a huge missed opportunity for cable, which could have been an intensely appealing platform for interactivity. Instead the door has been opened wide for others like Apple and Google to rush in."

And right on cue, last week Google announced Google TV.

Will’s point is so spot-on I’ve posted his words verbatim and I’d recommend you read them again and contemplate what this means for your business. No, really, read them again.  I’ll wait.

In a world where the iPhone comes out of nowhere with a hundred thousand apps and Netflix is streaming its movies to dozens of devices, twitter’s amazing ecosystem, and eBay doing $7B/year via APIs, you CANNOT AFFORD to keep your doors closed to outside innovation.  Our own Sam Ramji presented a very well received talk on the change in business strategy APIs are forcing.

Is your business open to outside innovation?  What would happen if your competitor opened its business to developers tomorrow?

Don’t try to market to developers.  Instead, solve their problems. »

Not long ago you could count the number of 'developer marketing' programs on one hand.  Now there are hundreds of programs as Web companies and enterprises open APIs.   These companies know that developer adoption will make their API strategy succeed or fail.

But Developer Marketing is an oxymoron.  Developers hate marketing.   

You cannot drive adoption by 'marketing to developers.'  Sure, you can send offers to your developers but your mileage may vary.

A better formula - understand what's important to developers and give them what they need to reach these goals. Developers want to:

•  build new skills that lead to the best projects and jobs.  This is why new or proprietary tools and programming models are tough to get off the ground - it's a small market of new projects for the developer.
•  increase their productivity.  With good tools and by connecting developers with decent resources and each other for help.  This is why sites like StackOverflow take off. 
•  be recognized for good work and see their products used.  Focus on showcasing their work, not your product.  It's not about you.
•  get paid.  Think App Store model, or affilate marketing networks.

Talk to the folks that made the big developer networks sucessful and you'll hear these points over and over. Some others:

• Developers are not buyers, but are very strong influencers.  There are superstars in the developer world - make them fans and that is the best marketing you'll ever get.
• You can't 'own' or 'use' developers because they have an account on your service.  Developers have lots of options and switching costs might be low from your API.
• Act on their feedback.  Developers are smart and listening and acting on their complaints and ideas is critical to your credibility.
• Developer communities are fragmented.  For example, there is no such thing as an "API developer', but instead there are Twitter or Facebook or Salesforce developers.

Once you have attracted a developer to use your service - they are like gold.   So treat them with respect - don't try to 'use' developers or you might lose them!

Apigee vs. Sonoa ServiceNet for API management »

In a few years, most of your internet traffic might come in not through your website, but instead through mobile devices, tablets and affiliate partners accessing your services through APis.  For two years, we've been helping enterprise customers accelerate their API strategy and deployments with Sonoa ServiceNet.    

Last year we released Apigee as a tool for developers building apps with APIs.   Apigee provides free, self-service website for API analytics and protection. Hundreds of developers are using Apigee to monitor APIs they are consuming (such as the Twitter, Flickr, and Facebook APIs) or APIs that they are providing.   Here are some example apps. 

How do Apigee and Sonoa ServiceNet compare?

It's much like the difference between Google Analytics and Omniture. Apigee (like G analytics) is a free, self-service API analytics and management tool that provides coarse grained analytics and basic throttling policies.  Sonoa ServiceNet is an enterprise-scale API management platform that provides a rich policy framework for customized, complex policies and enterprise-levels of scalability.  While Apigee is available as a free service,  Sonoa ServiceNet is available as both an on-demand an on-premise (both hardeware and software) offerings.  Also, Apigee is itself an app built on the Sonoa ServiceNet platform.

So if you are a developer building an app that uses APIs and want basic API analytics and rate limiting in 5 minutes - give Apigee a spin.  If you are a product or engineering executive thinking about an enterprise API strategy or roadmap, consider these potential requirements and take a look at Sonoa ServiceNet for industrial-strength enterprise API management.

If you build it will they come? Developer Community and Audience »

(The 10th installment in our API Roadmap Considerations series)

You've built a great API and have the operational bases covered.  Now the fun part - buiiding awareness, adoption, and community.

Think about it like throwing a party - you need to get the word out, have food and drinks covered, and help people mingle.

That is - 3 things need to work together  - audience, tools, and community.

(But first you must have a cool product.)

Always loved this talk by Dave McClure.  First – your product better be cool. Or..start with a great, differentiated API.

Developers will make or break your API strategy. If you focus on making developers successful you are building on a very strong foundation.

It's important understand different developer segments, what's important to each, and key contributors. And there are thousands of APIs now - maybe dozens in your vertical.  Is yours differentiated by features?  Better terms?  A SLA?  More data?

Get the word out: Audience

We often see API developer community plans that focus heavily on tools and building a 'destination portal'. 

But first - plug into existing destinations and communities.  You can sign up for most of these now, for free.  They reach thousands or millions of developers and they rely on your content and participation.  Examples include:

• API listings and resource communities like ProgrammableWeb.
• Vendor communities, like Microsoft's MSDN, Google code.   If these developers might use your API, you should be there.
• Platform communities like RubyOnRails or iPhone.
• Independent communities like Stackoverflow.

This also helps your search engine discoverability on anything related to "API + your business."  You want to rank well aginst similar APIs in Google searches.

All the fixin's:  Tools and processes

Just like a decent party needs catering and comfy chairs, you need tools and processes dialed in before your API launches.  Things like developer onboarding , developer key management, and integrations with the business (billing, compliance, etc.).   Dress rehearse these during the private alpha period so you can handle demand when it comes.   We often see teams that have licensed all the tools but haven't run the processes end to end - it's just as important as testing your API.

You'll need to make it easy for developers to find and help each other when working with your APIs. Blogs, documentation in wikis, code samples and app galleries are critical and easy to create. (most are free).   And again, not just the tools but dress rehearse the processes. (i.e. who's on duty for monitoring and responding to tweets and blog posts.).  For example, we love GetSatisfaction for Apigee.

For content and resources, code samples are consistently ranked at the top by developers.   You can use your own QA stuff for starters -  that they can incorporate in their own apps.

Take jackets and get drinks:  Community

If your API is easy to find and you have tools in place, you can tackle 'community'.   A book could be written about this, but successful communities have a hardcore group of developers that help each other be successful, an open dialogue with the API provider, show up at both online and offline events, and have at least one rabid, hardcore evangelist ringleader at the core that writes code with the API and seems to be everywhere.

The best community managers make it all about the developers – welcoming them, showcasing their work, and making them stars.  (more ideas at the end)

Should you outsource community management?  It's all about the passion - we usually see the best being full-time employees that actively seek out the position.  

Your Roadmap: Audience and Community

So if you are opening and API, think about the following for your roadmap.

Audience and distribution

• Can you get awareness and distribution through existing developer communities, such as any vendor (MS, Google IBM), Platform (Ruby, iPhone), Independent, Directories (programmableweb)
• What Web marketing - Search Engine Optimization or Adwords - can you do to make sure developers find you

 Tools and processes

• Do you have formal documentation? Can you put it on a wiki?
• Do you have code samples on how to use the API?
• Do you have a place for developers to put their own code samples and showcase their own work and sample apps? (widgets, mobile apps, etc.)
• Are code libraries needed for important platforms? Should these be open source?
• Do you have a blog for best practices and a way to get in touch with developers on important changes (such as API version updates?)
• What about adding and managing developers?  More on that in User Onboarding and Management

Community management

• Should you have a dedicated full-time employee to drive community and evangelize your product and best developers?
• Are there any offline events or meetups you should be at?
• How can you recognize and promote your hardcore community members? Do you have an evangelist that knows these folks personally?

Good resources and other ideas

Create discussions & docs on Google Groups.  Check out how some of the great developer communities use Google Groups, like:

• twitter - http://groups.google.com/group/twitter-development-talk
• iphone - http://groups.google.com/group/iphonewebdev
• ruby on rails - http://groups.google.com/group/rubyonrails-talk
• get started with your own group here:  http://groups.google.com

Make your API sample code available on a social version control system like:

• github - http://github.com/ - uses git
• beanstalk - http://beanstalkapp.com/ - uses subversion

Promote Yourself on facebook, twitter & a blog

• facebook.com - create a fan page
• twitter - look for people doing the stuff with your API and call it out
• blogger, typepad, etc all provide a great way to respond to and showcase developers

(and thanks to Richard0 for the photo..)

Welcome Aboard:  API user management and onboarding »

(Continuing our blog series on Is your API Naked:  10 API Roadmap considerations).

Just like you have processes to add and maintain user accounts with your website, you'll need the same for developers using your API.     Making it easy for developers to quickly get API account details squared away is critical to reduce barriers to adoption.

And good user management will reduce your support costs and increase customer sat.  

This includes setting developers up with an account and any authentication credentials they need to work with your API.  But you'll also need UI and processes to add, maintain (such as reset) and revoke or delete these accounts.      You may also need to take into account how to hand out keys or OAuth keys, and even consider an approval process, if you are going that route.  (although you don’t necessarily need to use API keys).  

Also, consider whether you can make things simpler by defining rights around standard user profile.  For example, ‘bronze’ customers have access to certain APIs or requests vs. ‘gold’ customers.

Finally, consider any other information you can give developers that will make it faster and easier to work with you - to get their questions answered without calling you.   For example, usage statistics and alerts on versioning upgrades and outages. 

Do you need to start from scratch? 

Before building or buying this, consider if you might be able to extend some other existing user management UI and processes to work for developers requesting access to your API.  

(For example, we built our own user management system for Apigee freemium API management over a couple days with our existing salesforce.com setup.) 

Key to this decision is - how much integration do you need into your existing business processes?   Do you need to create accounts in your CRM system, and make sure you have enough developer information to map developers to applications, and customers? 

Consider the following user management questions for your API roadmap: 

For on-boarding developers

• Do you already have a way to manage user accounts that you plan to re-use for your API? Or have you considered it?
• If you have, do you also wish to offer OAuth keys?
• If you have no user management at all, what does a user need to do in order to sign up to use your API?
• Can they sign up quickly and easily using a web browser?
• Can you simplify things by defining ‘tiers’ of users?
• What kind of information do they need to have access to?

For maintaining and managing accounts

• Can you re-set their passwords?
• What user interface do you want to create for user management?
• Can users do it using a web site or is there some other way?
• Can you monitor their usage?  Can they monitor it themselves
• Can you revoke user accounts?
• Do you need to implement an approval or screening process?
• Do you need reporting and analytics around users – active developers, engagement and retention rates?

Integrating your API users into the rest of your business

• Does your developer activity need to get mapped into your sales, support, and ERP systems?
• Does your API key structure enable you to map developers to applications, your customers, and their end users?
• Does user data need to be integrated with existing profiles or user data systems?  Can you use existing SSO (single sign-on) systems?
• Can you create the right usage incentives by providing developer access to their own usage data?