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
- 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
- Andrew Nacin Of WordPress @APIStrat Chicago
- Push Button API Deployment With The Heroku Button
- WordPress Style API Modules For Government
- The Heroku HTTP API Design Guide
- What I Have Been Calling API Trends, Are Slowly Being Baked Into API Operations
- FDA Finding Their API Mojo With A New Drug Label API
- Adding PokitDok To Healthcare Research And The API Stack (Well They Did)
- Why I Am Continuing To Integrate Zapier In My Business Workflow
- Who Is Going To Build The Uber API Platform For The Sharing Economy?
- The API Focused Dev Shop
- Route SMS Messages To Google Spreadsheets Via Twilio API With TwilioSheet
- Publishing Your APIs To Product Hunt
- Providing Users With Reciprocity Tools So Important Intuit Purchases itDuzzit
- Bing Developer Assistant for Visual Studio Delivers Relevant API Code
- Average Number of APIs Used In A Modern App