Thoughts from a Venture Capitalist on Software, Software-as-a-Service (SaaS), Cloud Computing, Mobile, Internet and more

Tuesday, March 24, 2015

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 helpfulPANEL:
We're built on APIs

-
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 communityAdam 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

-
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

-
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.

-
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

No comments:

About me

French native, I have been working in the technology industry for more than 15 years, both in Europe and Silicon Valley. I started my career in 1998 advising large tech companies with McKinsey&Co, before moving into venture capital in 2006. Some of my past investments include CornerstoneOnDemand(Nasdaq: CSOD), Eloqua (Nasdaq: ELOQ, acq. by Oracle),Criteo (Nasdaq: CRTO), Intacct (Acq. by Sage) and Bizo (Acq. by LinkedIn).

I moved back from Silicon Valley to London in 2011 to Join Accel Partners and focus on investments in Cloud Computing and Online Marketplaces

Beyond technology, I like everything with a board on snow, water or land