Building your API strategy requires you to pave the way to success by understanding what third party developers need and delivering it to them.
Hugh Durkin, senior product manager at Intercom, has led the redevelopment of Intercom's Developer Platform over the past year. The Intercom Developer Program launched in November 2016 and is seeing rapid traction with over 50 integrations already created by external developers.
While Intercom had previous externally available APIsTrack this API, mostly used by large SaaS partners to create integrations into their public tool offerings, the customer messaging platform has found that increasingly their own customers want to access Intercom's services programmatically. According to Durkin:
"As a product company, you build the layer of services you need to build your own product. Then you sell the product, the visual interface into those services," says Durkin. "You are consuming these services as resources to build your product. So, if you're building and consuming these services yourself, you start to think about ways for people outside your company to consume these services programmatically. When customers start to demand programmatic access to your services, this is where the move from product-first company to platform-first company begins.
Customers want the functionality of the product, but they want it programmatically and that is how we built our Developer Platform. We first needed to understand our customers and define the jobs they wanted to do. In 2015, we ramped up the integrations we had, led by customer demand, and started dogfooding our publicly available APIs ourselves. We gained momentum in that way, and developed the common internal and external standards we needed in our infrastructure so that developers could build integrations in a way which is consistent with how we build our own product."
Durkin says many of the first integrations Intercom offered were bespoke, and while they did similar things, each was built uniquely. As they moved towards a shared services infrastructure that could support their platform vision, they were able to reorient their APIs to be more consistent and help speed up both internal and external development. They're now hoping that by introducing an API specification format they can scale that even faster with the automatic generation of sample code and documentation.
"We are developing a shared language across Intercom on what APIs and services exist, and want to make sure that language is shared internally and understood externally. We're putting a lot of effort into our tooling to achieve that goal," says Durkin.
With the infrastructure in place, Durkin's work this year focused on rebuilding their developer portal and fostering a new generation of external developers. To create Intercom's developer portal, they focused on documentation and tutorials for things like authorization, so that developers could get started using their API quickly.
To evaluate the effectiveness of this effort put into offering getting started guides and other documentation tools, Durkin is exploring "time to first API call" as a metric. "Having that as a metric has been part of a long-term focus and has helped us measure that our documentation works really well," says Durkin. "We have a number of quick start guides, and now we are working on an iteration of that metric around what happens if you want to apply for API keys. We also want to surface metrics to developers that will give them visibility on what matters to them. If API calls are failing, then we want to surface this quickly to developers and tell them why proactively."
Durkin says a key part of the successes they have created through their documentation is because they have involved content strategy alongside their Developer Support team since inception.
"We have an amazing content strategy team," says Durkin. "All of this is about building a shared understanding of your APIs and services, so we have a content strategist who works closely with us on an ongoing basis to refine documentation and tutorials and map out those APIs, so others inside and outside the company are able to understand them easily. Content strategists are crucial to building a consistent API offering: get them on board early," he recommends.
Durkin credits this approach as the reason that other business units are also able to make use of their developer portal. For example, sales teams and customer success staff refer to the developer portal to help customers use APIs, even without technical knowledge.
To improve the metrics and feedback loop continually, Durkin says they currently know where developer conversations start by looking at their documentation metrics, but next they want to dig deeper into using metrics to understand which languages are used by developers within their community, so they can continue refining documentation over time.
Aside from documentation as a measure of developer experience, Durkin is now working on metrics to evaluate the entire developer economy. He says:
"It is hard to measure a developer ecosystem, and communicate the value of it relative to the rest of the business. We see that there are three buckets:
- Value: The utility value of the APIs that we're exposing to developers and to customers who are building and using integrations. Example metrics could include the frequency of use of an API endpoint or the activation and churn metrics for an integration.
- Distribution: How the ecosystem is distributing your product and letting people know about your product. You can measure this through metrics like visits to your website that come from developer referral sources.
- Revenue: You can measure revenue by understanding how your APIs and developer ecosystem impact average Monthly Recurring Revenue (MRR) for your products, or the net customer lifetime value for someone who has one integration activated versus a customer who has, say, seven integrations activated."
Durkin points out that an ecosystem is also an economy. As a platform business, measuring the value exchange on the platform is important, and doing that in real time gives you a good picture of where the business is and how to manage growth.
Within these three buckets, Durkin explains, you can go as high-level or as deep as needed, but he recommends that for wider business reporting, less is more. For high-level reporting, he recommends no more than two metrics in each of those themes. For example, in the "utility" bucket it may be enough to measure the percentage of all customers who are using APIs and integrations. For distribution, looking at how the ecosystem is influencing top of funnel activity may be easiest, and for revenue the easiest metric is to look at the dollar value of all your MRR, which is connected to customers using integrations and benchmarking against customers who do not use integrations.
Establishing developer metrics is the most immature and challenging stage of API lifecycle and product management. Several API providers use the Net Promoter Score to measure the perceived value to developers in their community of both their APIs and the associated resources. Others are tracking monthly active users or API calls made. But having clear metrics that map from the API strategy — aligned with goals such as ability of the APIs to drive creation of innovative products, or by calculating the financial impact of APIs on business models measured by cost efficiencies or explicit revenue generation — is a relatively new task that is now becoming essential as more API providers mature sufficiently enough to be managing a platform approach and are collaborating consistently with a widening network of external developers, suppliers, partners and stakeholders connected to them by APIs.
As Durkin and Intercom prove, it is not necessary to have a fully fledged metrics system in place immediately, but instead to start tracking key indicators across a range of business goals — platform reach, developer engagement and financial impact, for example — that align with your API strategy and wider business plan.