Read on Twitter
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:
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.
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.
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.
