API Metrics: Focus on Hidden Value, not Loud Voices

Just wrapped up my summer blog post series on API metrics, and my recommendations for measuring top 3 most commonly reported numbers:

1. Total number of developers
2. Total number of applications
3. Total API call volume activity

There are lots of other numbers I recommend measuring as well, but getting these basic three right -- and measuring them correctly -- can reveal a lot of value attributable to an API platform.

The two major learnings I had in writing this series are:

a) counting partner developers (biz dev partnerships, vendors, agencies, consultants) as "internal" developers because they are building an internal project for you (read: your iPad app) undervalues the reach and extension of your API. Internal development should be designated for core roadmap projects being built by employees of your company. If their paycheck doesn't show your company name on it, then they are an external developer that has been hired to work on an internal project. External developer value is a lot greater when you break it down into internal/partner/open segments instead external equating to third party developers exclusively. Many partner developers get exposed to your API initially through external-facing touchpoints (blog, twitter, discussion threads, hackdays, FAQ, Knowledgebase, events) and use it to evaluate the value potential of consuming your API using your basic open developer portal. If you think you have the answer to all your business challenges within the walls of your company, and don't want to fund or support an API platform for external developers, the value of your API will be much harder for you to justify.

b) analyzing data grants you the perspective to prioritize your roadmap based on where value is being created, not just reacting to the loudest voices. Too often companies and organizations let a minority of customer opinions weigh proportionally higher than the value of their usage would otherwise indicate. Listening is always good, especially when they are fresh perspectives without a lot of value history built up yet, but incorporating implicit behavior patterns in addition to explicit feedback is too often overlooked. "Do as I say, not as I do" is a uniquely human condition that it is wise to recognize and compensate for with actual usage data.

Off on vacation!

evans data developer relations conference

i spoke at the Evans Data Developer Relations conference last week, which is an event focused on companies and folks who run or are looking to start developer networks. I met all kinds of great people from other developer programs - Intel, Adobe, RIM, Citrix. I particularly enjoyed Chad's session on Yahoo! Hack Day, and how they pulled off such a kick-ass developer event. (thanks for including my quote, Chad!) I wasn't able to make it the second day, but I heard Jeffrey's Approver.com session was also very good and entertaining. He has posted his slides from his session, too, if you want to see them.

Since many folks came up and asked for a copy of my preso "Architect your platform for developer participation", here it is. Like I said in my session, my topic was architected for participation as well, so go ahead and share your comments if you were not among the folks who came up to see me after my talk. Developer community is a fun place!