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
- 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
- An APIs.json Collection Of API Resources Across Your Public, Partner Or Internal Resources
- One Possible Reboot Of The API Stack
- How Are Dev Shops In Chicago Using APIs? A Talk With Bryson Pouw At Blaze Portfolio
- Every API Provider Should Have A Logo And Branding Page
- What Is An API First Strategy? IT architecture And Catalyst For Engagement
- The Speed Of Federal Government When It Runs On Github
- Swagger, APIs.json, And Review For The New Developer.Trade.gov
- Student, Instructor, Classroom, Class, And Course API Planning At BYU
- Can You Add My API To Your Website Listing?
- Adding Google To List Of API Deployment Companies
- What Is An API First Strategy? Adding Some Dimensions To This New Question
- The Five Month Journey Toward A Stable APIs.json Discovery Format
- How Are Mobile Dev Shops In Chicago Using APIs? A Talk With Dave Devitt At SYDCON
- An API Case Study Format From Google Cloud Platform
- Next Stable Version of APIs.json + APIs.io Is Ready - Are Your APIs Discoverable?
- Expanding API Gateway Connectors Into A World of API Deployment Startups
- Where The Good IPAs Are In Chicago While At API Strategy And Practice In September