Product lessons: Building APIs for developers

startup_API_TT

“…the data returned doesn’t match the documentation…”
“When it’s complicated to get started…”

It seemed a logical stating point to ask (software) engineers what makes a good API experience in order to build one. The responses (some above) were mostly about letdowns & shortcomings.

Below is a list of product lessons I’ve come to learn during the development & iteration of the latest release of the PeerIndex API:

  • Start with empathy for the end user and take the time to understand their needs and what works for them, in this case, usually an overworked web developer
  • There’s lots of talented developers out there that could do mashups/cool things with your data, make it easy for them to create and play – quick to get an API key and start making calls – Sounds easy but you’d be amazed at how hard this is with some APIs
  • Write down and share the principles, strategy and roadmap for your API product – they act as a beacon of guidance when decisions need to be made (something I got from Marty Cagan)
  • Get someone to help who does this day-in-day-out. At PeerIndex we work with Mashery
  • If you do provide a good developer experience you will be recognised and thanked for it – it feels good
  • When you have a paid offering as part of your API, make sure you give people enough data for free to work out if they want to pay – we had signup buttons for our paid plans – how many people signed up by clicking those buttons? No-one. Let your end users/customers win first and win convincingly.
  • If your pricing structure isn’t working, change it – we initially had fixed price tiers until we found that the developers using the API were in two categories, those playing around/using data at low volume (not ready/wanting to pay) and high volume API partners.
  • If you’re lucky enough that someone takes the time to ask you a question about your API – take notice, something isn’t clear enough

This is not to say that the PeerIndex API is ‘done’.

It’s a product that needs to grow and evolve: more use cases (examples), more data exposed (more things for developers to play with) etc.

Useful resources:

Image credit: redpoint.com

Internet Trends

At the end of every year, Mary Meeker, partner at the venture capital firm KPCB, puts together a presentation that serves as an internet status report – identifying and commenting on current and likely future trends in the tech space.

2012 was no different and you can find Mary’s complete presentation (updated in December 2012) embedded in the slideshare below:

2012 KPCB Internet Trends Year-End Update from KPCB

Earlier this week, I attempted to pick out some headline points from Mary’s 88 slide presentation (and some other complementary ideas) that caught my eye. I then presented them as a summary to the PeerIndex team as part of our monthly Lunch & Learn.

I had fun doing it (challenging myself not to include any of Mary’s ~30 graphs/charts in my presentation!) and thought I would share a few of my summary observations report here:

  • Emerging markets are arriving at the table to be served, what’s cooking?
  • Yes, we’ve all heard it, mobile/tablet rapidly eroding desktop internet usage – build for that
  • If you’re lucky enough to have people using your service, they want the benefits of usage, 2 minutes ago. No waiting, just seamless service (think Hailo). If I transact on your site, or increasingly with your app, you better show me a result, instantly, or at least appear as though you do (automated order confirmation email), if not, I’m gone and I might tell the 500 friends I’m connected to not to bother as well
  • Expectations on (social) customer service are going through the roof (think train company twitter accounts) – build automated tools & data services to take care of 80% of requests
  • Got the keys to the social data warehouses? Make the most of it and get it right – businesses and consumers will be queueing up