Accel APX conference: short take aways

A NEW GENERATION OF APPS AND THE APIs THAT POWER THEM

I was lucky to be able to attend our Accel APX conference in San Francisco last week. In an environment becoming increasingly more competitive, it is becoming critical for companies to leverage external platforms & APIs to build a product fast and concentrate their resources on their core products. The objective of the conference was to understand how APIs will power the next great web and mobile companies and share some best practises in understanding when to use APIs or not and how can API company best market to developers. We were fortunate to host  very talented speakers from our portfolio (Ilya Sukhar from FB/Parse, Steve Marx from Dropbox, Bill Ready from Braintree, Ali Rayl from Slack, Eric Wittman from Atlassian, Sam Mac Donnell from HotelTonight...) and from leading companies (Jeff Seibert from Twitter, Mina Radhakrishnan from Uber, Adam Fitzgerald from AWS among others). We had around 300 attendees and our room at the Terra Gallery was packed. I loved it

The major themes of the discussions were around

• What to build on APIs vs develop internally
• Developer evangelism and fostering a community
• How to launch a successful API, documentation best practices
• Customer service and sales for dev-focused companies
• Developing an API vs a platform

Here are a quick set of notes that our team (thank you Andrei!) gathered at the event. It is not very polished but was designed for a fast read. I hope you will find this helpful

PANEL: We're built on APIs
Andy Fang, CTO Doordash
Sam MacDonnell, CTO HotelTonight
Mina Radhakrishnan, Head of Product Uber

- what to build in house vs. use from outside: think of what's core to the transaction, use 3rd party as much as you can
- DoorDash "delightful delivering": refuse to outsource customer support; but open to outsource payments, fraud etc.
- HT: don't outsource communication b/c part of core UX even though APIs available
- healthy dev environment around APIs, very important to get confidence you can build your platformon on top of them
- APIs give you freedom, don't have to invest both people and tech in maintain internal platforms
- HT had to totally revamp their infra, to manage 10x supply, allow advance bookings etc., so needed to ingest a lot more data (and already had performance); they totally ripped out their inventory system and moved everything to Elasticsearch, removed their Rails endpoint; got this going in 2 months, would not have been possible 10 years ago
- very challenging to build a solid external API, on the roadmap of HT but need to allocate lots of time and resources for it
- need to be clear about brand guidelines for how 3rd parties use your APIs; T&S are very important for Uber

FIRESIDE CHAT: Launching a platform and driving community
Adam Fitzgerald, Global Head of Developer Marketing at AWS

- founder of Springsource, then at VMWare and Pivotal
- APIs are important for building a community of developers
- need to understand who your developers are
- devs are hard to market to
- devs are the connoisseurs of tech, they've been sold so many techs that never panned out, that they're very discerning about the techs they use
- they're protective about the intellectual capital needed to get familiar with a new tech
- metric is "if I spend X hours learning this, will I save XXX hours later to not do this type of work again?"
- devs very interested in productivity and simplifying their lives, not in chasing new techs
- Rules:
1) Do documentation right: keyword rich, want engineers to write it; e.g. GitHub is using GitHub to write GitHub docs, engineers more willing to do it, and then can easily launch it as part of project, devs can fork it
2) Remove barriers to get started: use free tiers, reg-free accounts, allow people to experiment easily, give starter kits; e.g. Twilio does a phenomenal job; also look how devs are using your services
3) Be responsive
4) Find a community hero
5) Be a cheerleader
6) Listen actively: the opposite of marketing or broadcasting

PANEL: New vertical APIs
Adam Ludwin, CEO, Chain
Daniel Yanisse, Founder & CEO, Checkr
Andrei Pop, Founder & CEO, HumanAPI
 
- rise of vertical APIs in new categories
- Checkr for background checks (Accel portfolio)
- Chain is a blockchain API: indexing the large volume of data and providing fast access, managing private keys
- Human API: health data API, solves data liquidity and data mobility in healthcare
- need to abstract complexity from end user
- first set of customers: go for bleeding edge or big reference incumbents: once you prove product market fit with a couple of customers it's easier to get additional ones
- Checkr: 200 customers after 1 year live, now they're the 4 or 5th background check company in the US
- Chain: large market share in a small but fast growing market of bitcoin devs. To get started: you can "do things that don't scale": first sales were with customized prototypes
- first hires: need excellent engineers early; where you need domain knowledge is in product and once you start enterprise sales
- when you're building an original product, your team will become that source of domain knowledge in a matter of months
- Human API: no healthcare expertise in house; don't want to hire people with too much baggage (this can't be done), this can slow down company a lot
- for new thinking on old problems, you can't bring old thinkers
- need strong generalists and have to love the mission
!!! ninja hiring tactic: check Twitter lists of engineers, curated, then send them to mechanical turk, and filter them by focus, works well for specific areas like bitcoin
- useful API monitoring tools: Runscope
- tools like intercom are good, but still generalist-targeted
- most big companies end up writing API documentation in house, needs to be alive -- there should be a good tool for that

PANEL: Building a business model around developers

Bill Ready, CEO, Braintree
Calvin French-Owen, CTO, Segment
Eric Wittman, GM & Head of Dev Tools, Atlassian

- Braintree: payments are a big part of margins (can be 3% of the 10% take)
- need to remove barrier to entry
- key to propose a very simple pricing, so developers can make the buying decision,  not the CFO
- at scale, can't avoid talking to CFO
- need to build things that allow pricing development over time
- at Braintree they try to be proactive on pricing: when volume increase by 10x they reach out before to decrease pricing before the customer ask
- at Atlassian, they eventually land in front of CFO b/c of virality inside a company
- no one has left Segment b/c of pricing; it helps that they give easy access to customers' own data; if switching is easy, people stay
- Segment: stay away from custom agreements and consulting work; only add feature if they help the whole customer base; do one thing and do it well; don't do consulting work
- most of sales for Segment are inbound, no sales reps involved
- Braintree: don't want sales people who just want to shove product down people's throats; want to make sure sales people try to help customers, understand if product is a fit or not
- don't want to aggressively hit quotas, sell to customers who will churn in a year
- breaking discipline to not do custom work for customers can have huge repercussions down the road: you won't be able to serve customers well because of not maintaining the different tech stacks etc.

 
PANEL: Best practices for developers evangelism and support
John Milinovivh, Founder & CEO, URX
John Sheehan, Founder & CEO, Runscope
Ali Rayl, Head of Developer Support, Slack

- everyone needs to see all support communication, helps build trust and deliver a consistent message
- need clear SLAs across all channels
- need tiering of support, but no need to artificially slow down support for small customers
- support team needs to be well versed in any language
- support is the one opportunity to delight customers
- Slack: API should not be versionalized, backwards compatibility is part of the customer proposition
- API relationship is a long-term business relationship; e.g. some customers use multiple API keys to override limits, once they scale, do you want to keep them this way? Successful on your platform but not sticking to guidelines, can also affect the rest of your customers
- you need to help developers become more successful
- can you outsource support in an authentic way? No!
- metrics of success: time to first contact, time to resolution, customer satisfaction score
- if you see some feature that's grossly underutilized, it's probably very hard to use
- customer support at Slack: triage channels, basically one each support channel there's a dev that can answer; also all past discussions are searchable

PANEL: Facebook, Twitter and Dropbox - Building platforms at scale
Ilya Sukhar, Founder & CEO Parse/Facebook
Jeff Seibert, Director of Platform, Twitter
Steve Marx, Head of Platform, Dropbox 

- Crashlytics sees about 5B crashes a month
- roughly 3B active users around the world - experience shaped by roughly 3M developers
- customer support: need to respond to everyone fast, but also appropriate levels of depth depending on customer relationship
- Dropbox: app approval process if you want to go beyond 100 users
- people doing automated creation of apps: cat & mouse game, need to use captchas, look at metrics
- Facebook will charge if you get scale, weeds out a lot of folks
- Twitter: make their Fabric API very restrictive, let product guide use cases; by contrast, the broad Twitter Rest API is very broad
- Meerkat: comes down to intent; unhealthy if goal is to build identical graph
- Dropbox: need to be very intentional with why you're building on the platform
- the more data you have on how devs use your platform the better you can scale it. Need to run native code, just relying on API calls not enough