Tag yourself: a framework for developer experience maturity

As we’ve built out Usabl’s platform for getting feedback from real developers, we’ve spoken to dozens of companies building API- and developer-first products for everything from payments processing to security scanning. In each conversation, we’ve consistently seen patterns in the way these businesses engage with developers. In this piece I propose that developer-first businesses can be categorized into one of 4 stages of maturity.

Not all developer experience programs are at the same level of maturity. Where does yours fall?

Stage 1: Handholding

In this stage, the team building the product is often their own user. Think of Stripe’s “Collison-style” installations as an example. Companies at this stage may sell vaporware, building out the product only after a deal has already closed. Products at this stage usually don’t have public documentation, and often won’t even have a “request to join our waitlist” form on their website. All usability issues are immediately apparent to the product team because they’re the ones experiencing the problems.

Stage 2: Closed Beta

Teams at this stage (think Seed, 5+ customers) are starting to hand off more of the integration work to their customers to take on. Product teams will build things on an ad hoc basis, usually in response to a specific customer request.  For new customers, the onboarding process may involve some manual configuration in the backend (for example, allowlisting a subscription), but the product team won’t actually write code on behalf of the customer. Instead, they’ll invite the customer to a shared Slack channel or Whatsapp group and send a link to their public documentation. When the customer runs into an issue, they can drop a note into the Slack channel for the product team to respond to. At this stage, product teams still retain good visibility into user pain points, because there are no support teams acting as intermediaries (and possibly filtering out some feedback).

Stage 3: Self-serve

Product teams at this stage (Series A) are cleaning up the detritus from the search for product-market fit, deprecating unused components and building a cohesive experience across the features that remain.

Product-led growth becomes possible at this stage. Product teams at this stage (Series A) are cleaning up the detritus from the search for product-market fit, deprecating unused components and building a cohesive experience across the features that remain. Companies at this stage will hire their first Developer Relations/Developer Advocate employee. They usually have a robust freemium experience, where a developer can sign up and get an API key without talking to anyone. Their docs are usually hosted with a tool like Readme and provide some level of interactivity via a “Try it Now” interface. These companies are also usually experimenting with some type of community forum, for example in Slack, Discord, Gitter, or Discourse. Finally, they’ve begun handing off the work of customer support to dedicated customer support teams, so that product teams can focus on building the product. With this focus on specialization comes a cost, however, which is that product teams may lack visibility into the parts of the developer journey that are most painful.

Stage 4: Self-sustaining

At this stage (usually Series D and beyond), companies have built up so much love for their product that developers volunteer to evangelize it. Developers organize meetups and conferences to talk about the product and connect with other users. Experts will arise on platforms like StackOverflow who volunteer their time to help answer questions from other developers. If the product is open source, companies will consider moving to an open governance model. New hires will have already used the product before and will be passionate about improving it. While this stage is a common one for open source companies, it’s rare for proprietary developer-first companies to make it to this stage. Some tactics that can help foster this level of engagement include developer loyalty programs that provide perks and invite-only betas, such as the Microsoft Most Valuable Professional program. At this stage, companies may be able to get all the feedback they need from developers who have opted in to provide feedback.

StageProduct ideationIntegrationSupportCommunity
HandholdingFounder-driven, VaporwareProduct team writes codeN/AN/A
Closed betaCustomer request-drivenCustomer writes code with product team’s helpShared Slack channelN/A
Self-servePM-drivenCustomer writes codeSupport teamDevRel-driven via Discord, Gitter, Slack, Discourse, hackathons
Self-sustainingPM-driven + public roadmapCustomer copies codeSupport team + StackOverflowAll above + meetups, conferences
A summary view of the 4 stages of developer experience

No matter where you are in your developer experience journey, usability is key to getting developers to love what you’re building. When you find yourself in a position where you can no longer pinpoint the top 5 issues a developer is likely to run into when trying out your APIs, Usabl can help. By taking screen recordings of real developers attempting to use your API, we provide actionable insights on where the biggest points of friction are in using your API.

If you’re not sure how to measure the quality of your developer experience or need help figuring out where you can improve, drop us a note. We’d love to connect.

Usabl blog

Learn more about how API usability impacts your business