10  Pa&erns  in  Successful  API  Programs  

Greg  Brail  -­‐  @gbrail  

Brian  Mulloy  -­‐  @landlessness  

@landlessness @gbrail

Mapping  out  your  API  Strategy        ✓  

Pragma;c  REST:  API  Design  Fu      ✓  

10  Pa&erns  in  Successful  API  Programs  

What  to  Measure  

API  Tech  &    Roadmap  Considera;ons  

Driving  API  Adop;on  

API Workshop Webinar Series

PaHerns  in  Successful  APIs  and  API  Programs  

1.  Clear  API  ownership  and  strong  internal  evangelism  

2.  Early  and  consistent  vision,  strategy,  and  metrics  3.  Compelling  and  differen:ated  API  4.  Reminder:  Less  is  more  

5.  APIs  are  designed  for  adop:on      6.  Get  feedback  early  and  iterate  quickly  7.  Create  leverage  with  developer  community  8.  APIs  designed  to  understand  use,  prevent  misuse  

9.  Design  business  model  and  policies  from  start    10.  Scalability  and  performance  of  plaYorm  and  process  

1.  Clear  API  ownership  &  strong  internal  evangelist  

Strong  sponsor  and  leader  of  API  and  developer  program    understands  the  company  strategy  and  how  APIs  can  help  promote  that  strategy  

 Dedicated  API  team    

 dedicated  product,  engineering,    community  manager    Effec:ve  community  manager  

 extrovert,  can  code,  good  at  online  and  offline  community    constant  internal  evangelism,  excitement,  events  

2.  Early  and  consistent  API  vision,  strategy,  metrics  

Consistent  ar:cula:on  of  API  vision  –  from  execu:ves  to  engineers              Alignment  with  company  goals                Vision,  mission,  strategy,  objec;ves    Early  buy-­‐in  on  top  metrics  

 Makes  it  easy  to  priori;ze  roadmap  features    Track  actual  numbers  against  projected  numbers  

 Based  on  comparable  data  from  compe;tors  and  conversion  rates    Publish  weekly  dashboard  widely  with  discipline  

Vision  (the  dream)    Lead  our  industry  in  doing  business  beyond  the  browser  

 

Mission  (day-­‐to-­‐day  guiding  philosophy)    Applica;on  developers    are  customers  

 Strategy    (how  to  get  there  fastest)    Focus  on  mobile  and  social  developers    Smoothest  on-­‐ramp  for  new  developers    High-­‐quality,  responsive  support  

 Objec:ves  (top  3  metrics  all  agree  on  )  

Reach  -­‐  Quan;ty  of  3rd  mobile  and  social  apps  Branding  -­‐  Logo  impressions  beyond  the  browser  Revenue  –  Revenue  generated  from  3rd  party  apps  

VMSO  Framework  

Example  API  Metrics  Metric  area   Candidate  KPIs  Awareness    marke;ng  effec;veness  

Audience:  unique  users,  referrals,  page  views,  engagement  Traffic  sources  (Google,  corp  website,  etc.)  

Sign-­‐ups  messaging    effec;veness  

Registra;ons  (developer  keys)  

Adop:on  measure  of  product  fit  in  market  

Ac;ve  developers,  partners  Applica;ons  by  type,  geo,  traffic    End  users  Traffic  (%  vs.  non-­‐API),  Lost  Customers  

Quality  measures  dev  process  effec;veness  

‘Net  promoter’  score  user  experienced  problems  Cri;cal  situa;ons  (CritSits)  

Community  measure  of  customer  sa;sfac;on  

Forum  traffic  and  discussions  3rd  party  advocates  

Financial  measure  of  business  success  

Revenue?    Cost  of  data  served?    Profit  Market  share  

Example  Metrics  Dashboard  

sec:on  1  strategic  metrics  from  VMSO  vs.    realis;c  projec;ons  

sec:on  2  opera;onal  metrics  

sec:on  3  priori;zed  projects  

Objec;ve:  Agreement  on  Key  business  metrics  with  senior  management,  product,  and  developer  community  team.    

3.  Compelling,  differen;ated  API    

Your  API  should  be  valuable*    Valuable  =  useful    Do  developers  already  solving  this  problem  want  to  use  it?  

 Code  examples  =  top  priority  resource    First-­‐class  product  management  effort    Build  for  use  cases  focusing  on  developer  problem  

   Will  your  customers  really  get  this?”    Clear  differen;a;on      How  is  our  API  different?  

 *Crea;ng  successful  developer  programs  -­‐    Dave  McClure  

Product  Posi;oning  Example  

For  the  target  customer

Developers  building  web,  mobile,  and  social  apps  using  maps  and  driving  direc;ons

Who  needs  primary  need

Accurate,  free,  comprehensive  mapping

Our  Solu:on  is  category

Free,  global,  accurate  mapping  and  direc;ons  APIs

That  key  benefit

Provides  the  most  accurate  and  comprehensive  free  mapping  and  driving  direc;ons  services  

Unlike  compe::on

Error-­‐prone  Google  maps,  or  costly  Mapquest  direc;ons

Solu:on  is  greatest  differen:a:on

The  most  accurate  free  maps  and  driving  direc;ons  available  

What  we  don’t  do Not  every  feature,  no  ‘for  pay’  maps

 4.  Less  is  more  Design  for  target  developers  and  apps    Horizontal  or  Ver;cal?    i.e.  iPhone  apps?    large  partners?    Certain  plaYorms?      Who  are  we  building  for?    

 When  in  doubt,  leave  it  out    Don’t  try  to  make  everyone  happy    You  can  add  but  never  remove!    Releasing  internal  API  func;ons  to  external  developers  

 Spend  10x  more  effort  using  API  versus  building  it  

Rule  of  3  -­‐  write  3  example  apps  similar  to  targeted  apps*  Then  publish  example  apps  for  developers  

“*How to design a good API and why it matters” - Google Tech Talk by Joshua Bloch

5.  APIs  are  designed  for  adop;on  Standard,  simple  APIs  =  more  customers    Pragma;c  REST  -­‐  easier  to  learn  and  use  without  doc      Great  developer  programs  have  great  doc  and  sample  code    Bonus:  Pragma;c  REST  is  easier  to  secure,  analyze  

 

Don't  add  ‘anything  weird'  –  straight  REST,  XML,  JSON    Keep  calls  small  and  granular    No  custom  security  schemes    Use  straight  Oauth    

 Lots  of  APIs?    Focus  on  consistent  developer  experience      APIs  look  like  from  same  company,  same  process  to  get  started    Lightning  fast  to  register  and  get  started!  

6.  Get  feedback  early  and  iterate  You  won’t  get  it  right  the  first  :me  

 Listen  and  respond  honestly  and  quickly  to  developers    “Our  customers  took  us  in  an  en;rely  different  direc;on”  

 Release  to  a  select  alpha  then  beta  group  for  early  feedback  

First,    find  internal  customers,  friends,  do  a  hack  day  Find  developers  solving  the  same  problem  and  ask,  “will  you  use  it?”    

Design  for  agility    Bad  versioning  strategy  will  drown  API  team  in  maintenance    Don't  code  in  underlying  architecture  (example:  SQL  calls)    Version  in  packages  -­‐  keep  the  version  in  the  URL    Determine  costs  of  backward  compa;bility  

7.  Create  leverage  through  community  Community  is  crucial  for  an  API  team  to  manage  and  drive  adop:on  

 Responsive  ,  open  communica;on  cri;cal  to  credibility,  adop;on    Store  feedback  to  forums,  FAQ,  stay  off  the  phone    Can  someone  not  on  your  payroll  go  do  your  demo?    

 Developer  marke:ng  !=    just  a  developer  portal      

 Before  building  your  own  community  –  plug  into  exis;ng  communi;es    Target  key  communi;es  –  iOS,  Android,  php,  …      Think  about  audience,  tools  and  community    working  together  

 Understand  what  mo:vates  your  developers  

 Developers  hate  marke;ng  –  want  problems  solved    Developers  want      skills  for  their  next  job      to  see  their  products  used      to  be  famous      to  get  paid    There  is  a  pecking  order  and  ‘superstars’  with  developers  -­‐  target  them  

Profile  Developer  Segments  

Target  specific  communi;es  

Apigee  before  and  axer  TwiHer  Chirp

8.  Good  API  design  has  many  virtues  API  design  facilitates  analysis  

Use  a  sub-­‐domain  to  balance  &  analyze  traffic;  use  API  keys  Lesson  learned:  discern  Apps  from  Developers  from  Users    

Analyze  use  and  misuse  -­‐  inten:onal  and  otherwise  Lesson  learned:    customers  observed  partners  viola;ng  terms  Lesson  learned:    observe  the  old  API  before  designing  new  API  

 

Design  usage  policies  from  beginning  Rate  limits  (ops  policy)  and  quotas  (business  policy)  Don’t  enforce  key  policies  axer  the  fact  Implement  your  terms  of  use  Don’t  cut  off  developers  or  partners  without  communica;on  

9.  Set  Business  Model  Expecta;ons  Set  expecta:ons  with  developers  and  partners  ahead  of  :me    Policies  are  implemented  and  enforced  from  the  beginning    Bake  business  model  in  from  the  start  

 Op:ons  for  mul:ple  SLAs  and  :ered  levels    Free  op;on  for  closed  APIs  to  drive  adop;on    Paid  op;ons  and  for  partner  and  premium  content  

 Set  expecta:ons  with  execs    Will  API  drive  new  business?    Will  API  expand  brand  reach?  

10.  API  Performance  Poor  API  performance  and  reliability  is  a  business  issues  

Do  capacity  planning  -­‐  use  realis;c  conversion  rates  Not  just  traffic  but  concurrency    

 Caching  and  traffic  management  controls  can  extend  scalability  

Rate-­‐limi;ng    vs.  quotas  Control  bursts  over  planned  peak  Don’t  cut  off  best  developers  

 

Design  for  scale  of  business  processes  Interview  each  area  of  the  business  to  determine  impact  of  API  Model  processes  at  an;cipated  peak  scale  Design  and  Prac;ce  processes  as  part  of  pre-­‐launch  checklist  

Great  APIs  to  Emulate  Twilio  -­‐  pure  telephony  API  Wordnik  -­‐  best  API  docs  on  earth  Facebook  Graph  -­‐  reads  like  a  book    Yelp  -­‐  poor  API  resources  but  unique  content  (user  generated    content)  Yahoo  -­‐  great  off  line  innova;on  engine    –  Hack  Day  Google  -­‐  great  online  resources  Twi&er  -­‐  laser  focus,  very  easy  to  understand,  developer  console  SimpleGeo  -­‐  smart  geo  API  design  GameSpy  -­‐  all  they  offer  is  an    API  eBay  &  Paypal  -­‐  great  resources  for  affiliates  Amazon  -­‐  API  is  not  well  done,  but  service  is  valuable  Wufoo  -­‐  ar;cula;on  of  the  API  design  and  principles  Stackoverflow  -­‐  deep  developer  community  and  engagement  ProgrammableWeb  -­‐  great  SEO,  showcase  developers,  deep  resources    GitHub  -­‐  deep  code  resources  

THANK  YOU    Ques%ons  and  ideas  to:  @landlessness  @gbrail  @apigee