Crossing the Chasm: The Case for APIs

by Wei Lien Dang

Geoffrey Moore’s seminal book Crossing the Chasm highlights a classic problem that many startups face in the customer adoption lifecycle: how to bridge the gap between “early adopters” and “mainstream” users, two groups that have very different needs and expectations. Though Moore’s book focuses more on marketing to these two segments, his model can be extended to looking at how it impacts product development in young companies. Inevitably as a startup progresses towards product-market fit (PMF), it encounters two challenges: 1) how many and which features should be included in the overall product, and 2) ensuring that the product can scale once PMF is reached.

As a startup gets closer to PMF, a tension can emerge between building a product that is highly standardized vs. highly customized. OPOWER confronted this issue, and the dilemma over whether to build a custom feature that would incur significant technical debt tested the product development process that the company had in place. Startups who employ iterative product development can also run into the problem of feature overload. Over time, companies may add too much to their products, making them more difficult to use for the mainstream users that they are hoping to attract. Triangulate encountered this problem with its “Wingman” feature which detracted from the user experience. Feature overload can result from incorporating too much feedback from early adopters or from a founder/product manager’s misplaced vision. In either case, startups need to carefully weigh the tradeoffs of adding and removing features as they move further along the customer adoption lifecycle.

Additionally startups need their products to be scalable once they reach PMF. This may require changes to the existing product or to the company’s broader vision. A startup may realize that it has the potential to become a platform company or that previously unexpected network effects can be realized. Chegg is a good example of a company that has decided to pivot and try to become a platform even after it reached PMF. Adapting the product to these opportunities can give rise to a new set of challenges.

A “lean” way to address these two challenges and “cross the chasm” is to build an application programming interface (API) early on. First, allowing outside developers to tap into the existing product can enable customization to address the needs and preferences of early adopters vs. mainstream users. As Katharine Nevins pointed out, early adopters can benefit from the extended functionality that comes along with an API while mainstream users may be able to interact with different product add-ons that cater to their use cases. APIs can help prevent against feature overload by minimizing the “need-to-haves” that must be shipped with the core product and leaving the “nice-to-haves” to other developers to integrate. This can allow the startup to focus on the set of core product features that is most crucial to reaching PMF.

Second, an API can help set up the product to scale in several ways. As we’ve seen with companies like Facebook and Twitter, an API can be key to achieving significant growth. For startups that aim to pivot towards becoming platform companies, this is almost a must-have. An API also enables a new type of business development that doesn’t rely as heavily on landing large partnership deals, which can pose significant challenges for startups. Paul Graham recently called APIs the equivalent of “self-serve biz dev”, alluding to the idea that APIs facilitate B2B relationships by opening up systems, often for free. This may be enough for a small startup to attract large companies to work with them without the hassle of dealing with bureaucratic processes.

There are, of course, some drawbacks to building an API early on. One is that it takes away resources from iterating on core product development. Another is that it means startups will have to cede some control over the product vision, since this will be influenced by outside developers who add customizations. And APIs might also cause startups to get lazy and offload the “need-to-have” features to other developers when they really shouldn’t be.

Despite these drawbacks, I believe that APIs offer significant advantages to startups that have seen some traction with their products and are nearing PMF. Product development inevitably becomes more difficult when its goal is to satisfy a greater number of customers with a greater number of needs. APIs can be a “lean” solution to several of the challenges that arise when a startup is attempting to cross the chasm.