Crossing the chasm with Shawn Wang (swyx)
Shawn “swyx” Wang maps the DevTools adoption curve from enthusiasts to skeptics, explains why messaging must change at every stage, and connects Crossing the Chasm to Wardley mapping and the strategy of commoditizing your complements.
A product can delight early adopters and still fail to reach the majority. In this early Scaling DevTools conversation, Swyx uses Geoffrey Moore’s Crossing the Chasm as the starting point for a more practical taxonomy of developer adoption—and for deciding what to build, document and say next.
The framework expands from individual users into industry structure. Founders need to know where their product sits on both the demand curve and the path from invention to commodity, because the company that popularizes a technology is not automatically the company that captures its value.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
What is the chasm in technology adoption?
The classic adoption curve moves from innovators and early adopters through the early and late majority to laggards. Geoffrey Moore’s key observation was that the transition into the early majority is unusually difficult. Early users can imagine the unfinished future and forgive missing pieces; mainstream users need a product, documentation, support and proven use cases that work now. A strong MVP can therefore hit an adoption ceiling even while its first users love it.
Why is crossing it so difficult for product-led founders?
Documentation, examples and distribution can feel secondary to building the product. A few companies encounter overwhelming demand and avoid the problem, but most do not. Swyx invokes the observation that first-time founders obsess over product while second-time founders obsess over distribution: the second group already knows it can build and remembers that adoption failed. The work is to make the benefit legible to people who will not fill in the missing story themselves.
What are Swyx’s five DevTools adoption groups?
Enthusiasts build because they can. Pioneers have a pressing need, accept missing pieces and want to become part of the technology’s founding identity. Pragmatists evaluate today’s costs and benefits and expect documentation, licensing and support. Conservatives wait for certifications, social proof, a hiring market and a third-party ecosystem. Skeptics and newcomers adopt only when the choice has become unavoidable or requires no research.
How should the story change as a product matures?
For enthusiasts, the technology itself is the story: the language, architecture and unusual implementation are interesting, while price matters little. Later buyers care about outcomes, risk and cost. The product may also need wrappers, managed offerings or lower-code interfaces to reach them. Marketing, demos and documentation must evolve with the audience rather than repeat the launch message forever.
How can a company estimate its current stage?
User count is a useful rough proxy because the groups differ enormously in size: tens or hundreds suggest enthusiasts, thousands suggest pioneers, hundreds of thousands suggest pragmatists and millions reach conservative territory. The denominator matters just as much. A tool for one infrastructure role has a smaller possible audience than a JavaScript library, so founders should estimate the real population of the ecosystem and role rather than treat every GitHub account as an addressable developer.
What did the framework imply for Airbyte?
Swyx placed Airbyte in the pioneer phase: users had an urgent need for open-source data integrations, adopted before version 1.0 and built missing SDKs themselves. That made contributor identity and coverage more important than optimizing price. He also warned against multiplying product variants too early. Offering every combination of framework, styling and abstraction can communicate flexibility, but it can also expose a lack of conviction and make the product harder to understand.
Why might the company that creates a standard fail to capture its value?
Adoption and monetization are separate achievements. Docker transformed software delivery without initially realizing the business its influence implied; Lightstep helped establish OpenTelemetry but did not own the value created by the standard. An open technology may need a platform or commercial layer around it. Founders should study these failures without pretending there is a universal answer, because strategic structure can determine whether years of successful technical work accrue to the company or to its ecosystem.
How do Wardley maps add a second dimension?
The adoption curve describes demand; a Wardley map describes how the supply of technology moves from genesis through custom builds and products toward commodity services, arranged within a value chain from users down to machines. Every transition creates opportunity. If another layer becomes cheaper and standardized, the layer above it may become more valuable—a pattern captured by Joel Spolsky’s advice to commoditize your complements.
What strategic map should a DevTools founder build?
Place the product against both its user-adoption stage and the evolution of every adjacent layer. Ask which components are differentiating, which should become interchangeable and whether the market itself is expanding. That two-dimensional view gives product and go-to-market choices a context most teams lack. It also reveals that maximum growth is not always the right goal for an open-source community; pushing beyond its natural size can damage the qualities that made the technology useful.