Notes on developer product adoption

I've written before about how much I have come to appreciate the role of timing and catalysts in successful startup outcomes. It's hard to brute force your way into massive product adoption. In this post, I want to double click on some of the tailwinds worth thinking about for developer product adoption. I’ll share some notes I’ve gathered over time on how macro forces can spur adoption, and internal tailwinds can create an adoption flywheel.

New platforms

New platforms are the primary driver behind developer tools adoption — this is the most dominant macro tailwind. New platforms introduce fundamentally new modes of user interaction and reshape how consumers experience products. When a new platform emerges, it offers an opportunity to rethink a handful of core developer needs. These tend to fall into a few buckets:

• how code is written
• how applications are deployed/hosted
• how applications are monitored in production
• how user behavior is monitored
  

New markets arise out of the nuances of how each of these needs is implemented. For example, deploying to the app store and monitoring a mobile app requires different tools from deploying and monitoring a web app. I concede this is a bit of an oversimplification. Sometimes tools are inherently cross-platform — for example, teams today use tools like Mixpanel across both web and mobile for user analytics. But, developer products seldom start that way. Instead, cross-platform capabilities mature over time. Focusing on a specific platform is a superior go-to-market motion because it gives you a tighter feedback loop for taking advantage of a new platform shift.

New platforms tend to create fundamental and enduring effects. Several decades after a platform has gone mainstream, new and better tools continue to emerge for the core developer needs.

Architecture shifts, architecture volatility

Developer tools also evolve with changing architecture. How developers organize code and wire components together partly determines what tools they need.

Each iteration of software architecture is a best-guess estimate for solving the existing constraints of building software and meeting user expectations. Monoliths give way to microservices that scale more easily and allow for point changes. Event-driven architecture evolves to model business processes that have asynchronous dependencies. Serverless frees up developers from being infrastructure experts.

I often think about all the iterations we've been through when serving static sites in the browser — a seemingly simple developer need. We’ve cycled through architecture solutions shifting the burden of asset generation and manipulation from the client (vanilla HTML + JQuery) to the server (LAMP stack) and back to the client again (JAMstack).

The back and forth — architecture volatility, if I may — exists in almost every sphere of software development. It is a natural consequence of the march towards more efficient and secure code and is why there will always be new opportunities for startups.

Ecosystem flywheels

The final catalyst I'll talk about is ecosystems. Ecosystems form around a developer tool when a ton of activity comes from developers who are not the original creators. As a result, the number and type of use cases start to transcend what the original creators had in mind.

Creating an ecosystem around a developer product is an active catalyst — it is a conscious choice as part of product strategy. Ecosystems contrast with new platforms or architectures that are passive — external macro forces that you don't control. There is no one playbook for nurturing an ecosystem. Successful developer tools startups have approached this in a number of ways including:

• an open-source project nurturing external contributors
• startups showcasing what other developers have been able to build with their product
• flexible APIs that allow for building higher-level primitives on top of a developer tool
  

Ecosystems are strong catalysts because they allow for cross-side network effects. Cross-side network effects describe an ecosystem where there is an increase in value to users on one side of a network by adding users to the other side. For developer tools, the value flows between the contributions made by both sides: creators and users. In the case of open source, as creators invest in nurturing an ecosystem, more developers contribute to a project. As more developers contribute to a project, the capabilities grow, which further increases adoption.

Final thoughts

None of these tailwinds are sufficient for building a massive company. But, they are necessary to think about when answering why now is the time for a developer product to take off. Solid early adoption is the best signal of potential product-market fit for developer products. It trumps early revenue traction. It's much harder to convince developers to trade their time for potential value than to persuade them to exchange money for potential value. Paying attention to significant macro shifts and leveraging your developer community to create a flywheel are baseline ways to increase adoption odds.