Posted on 06-06-2014
My friends over at Social Health Insights, wrote about their experience being one of the beta users for the new OpenFDA API, and what they thought contributed to the success of the API launch from the Food and Drug Administration.
What I found interesting about their post, is that contributing factors were not technical:
- Getting Feedback Early - The openFDA team solicited feedback early on in the API development process from end users and consumers of the API. This feedback was listened to and ultimately helped shape a very nice API at launch.
- Being Collaborative - If you are going to do #1 then you must be willing to be collaborative. From the get-go, the openFDA team collaborated with a number of stakeholders and was open all the feedback that streamed in. This ultimately resulted in a great product at release. Beyond the initial collaboration they are still listening and we bet they will be open to the feedback that comes in.
- Being Responsive - Send a tweet or message to the team and see what you get. You will be shocked at how fast they get back with you to answer your question. We saw questions over Twitter being answered by the community and openFDA team members within minutes (pretty cool)!
- Explaining Use Cases Well - Go to the openFDA website and you will see several queries tied to real wold questions about the data exposed by the new adverse event API. This helps consumers understand the possibilities and content of the API quicker and simpler. Beyond this, they solicited private beta testers to build solutions on top of the API which also provided additional sample use cases of solutions that could be created using the API.
I am present on the backchannel for the OpenFDA rollout, so I saw some of the back and forth on the technical aspects of OpenFDA, and there was definitely lots of tech talk, but ultimately the success depended on providing use cases, getting early feedback, while also being collaborative and responsive.
As I’ve said a thousand times before, it doesn’t matter how technically perfect your API is, without the business and politics of your API dialed in, you will fumble the ball. Always keep in mind, that the reasons why this whole API thing is working, goes well beyond just the technology.
comments powered by Disqus
Winning in the API Economy
|Download as PDF|
Latest Blog Posts
- Beyond Public APIs In Government: Internal Access to Resources
- Can You Show Me The ROI On All Of This API Stuff Before We Commit
- In The Future APIs Will Be Default For All Cities
- No Public APIs Are Not Going Away Just Cause A Few BigCos Fumble At It
- Internal API Search Engine For Everyone At Your Company (Not Just Developers)
- If You Need Assistance With Your Healthcare API Strategy I Have The Person
- Explaining APIs To Senior Leadership: Access To Company Resources Without The IT Hassle
- A Conversation With @ijroth, @dorkitude, @antonyfalco, and @medjawii In The Next Generation API Stack Panel @APIStrat
- API Evangelist Thoughts On The Right To An API Key And Algorithmic Organizing
- Explaining APIs To Your Senior Leadership
- An API Evangelism Strategy To Map The Global Family Tree
- Thank You For Your API Evangelist Blog(s)
- Video From The Hypermedia Panel At API-Craft In Detroit Last Month
- Please Open Source Your API Before Shutting It Down
- Explaining My Work Around APIs In Higher Education To Institutions
- You Can Have An API Just By Choosing Products And Services That Have APIs
- Using Excel As An API Datasource And An API Client For The Masses
- Brewing Up Something Awesome With The Jive Software API
- Relationship Between APIs And Containers
- Real-time and Visualizations Will Be Key in Financial API Deployments
- Notification Focused Startups Within Leading API Ecosystems
- APIs That Do One Thing And Do It Well Like ZipLocate
- Which API Do I Need?
- The Expanding API Conference Landscape
- Ocotoparts Open Source Google Spreadsheet