Thread by @jgreze

Under-appreciated frustration of building an API product: feature adoption is much slower than for a UI product like Slack/Instagram. Even for your very satisfied customers.

Flip side: retention is much higher.

Here’s what I wish I’d known when I joined Plaid four years ago:

1/ If you have a UI product area, introducing a new feature or product is as easy as putting it in front of the user. You can email your customers, put a modal on startup (hi @onepeloton ), etc.

The user just clicks on the thing and voila they can use it and you get feedback.

2/ For an API product, it’s more complicated bc although you can do most of these things (email, dashboard promotions, etc.) to *tell* your user about the feature. Actual usage requires coding which requires engineers, and engineers’ work requires roadmapping. That takes time.

3/ An interesting corollary is that this makes it difficult to get existing customers to adopt incremental improvements, even if ROI positive. The activation energy of putting something on a customer’s roadmap that is just too much if the benefit is a mere vitamin.

4/ This is why self-serve and new users are so important: they are the testing ground for incremental improvements to your API and product.

5/ The other solution is to have a few close partners among your customers who are quick to try new things that require engineering and excited to help you develop your roadmap. This is a must for API companies.

Doing versioning well is the “how” you iterate API products.

6/ For worst cases, you have two big hammers -- breaking changes and API deprecation. Neither one of these helps much with iteration.

7/ Breaking changes can be useful when your API is limiting your product in a business critical way (i.e., something has changed in the world such that the API design doesn’t allow for required functionality to your customers). Use sparingly.

8/ API deprecation is a last-resort tool to manage technical debt and is very painful to customers for whom engineering is costly: the very companies that rely on you as an API provider because it was too difficult or costly for them to build it natively.

9/ When I joined @Plaid 4 years ago, I didn’t appreciate how getting this right is key to building a great API company. Luckily, Plaid had it “mostly figured out” (quotation marks bc building things is a constant exercise in humility).

Cc @umang who leads all of our dev efforts