How To Launch A New Developer Platform That's Self-Service Software

Enterprise software companies sell very differently today than just a decade ago. Previously, most software was shrink-wrapped, required a lot of effort to distribute and implement, and was sold to an executive who would have to deploy it throughout their department or organization. The buying process involved a long sales cycle and often included pilots, cost-benefit analyses, procurement, and legal reviews. Today, enterprise companies are building developer platforms where an individual developer can sign up for a SaaS service, integrate the SDK, and start paying via a credit card in a matter of minutes. Everything from payments and telecommunications like Stripe and Twilio to e-commerce search like Algolia can now be delivered via an API and SDK. With the rise of SaaS, enterprise companies are disrupting new industries by taking a page out of the go-to-market playbook for latest generation of mobile focused and web 2.0 companies like Facebook, AirBnB and Uber. This means ads, onboarding experience, and self-service is taking a higher priority over field or inside sales. The transition is not easy though. This article lays out some of the key elements required. Self-Service Onboarding How to transition from enterprise-only sales and add a developer first offering that's self-service. Any developer platform or self-service SaaS must start with their onboarding flow. Whereas the previous generation of enterprise companies could simply rely on a "Schedule Demo" or "Contact Us" form, developer platforms must now enable everything from sign up, to paying for the implementation via a no-touch or low-touch model. Because many enterprise software products require engineering expertise to set up and are more complicated than signing up for Netflix, a large emphasis should be placed on your onboarding flow. You'll want to gather some information such as the company name and the role of the person. This enables the experience to be personalized - is the person is a developer or non-developer. You'll want to clearly define the next steps for implementation, whether that's installing an SDK or authenticating with a third party tool. Measuring Onboarding Success Time To First Hello World (TTFHW0, or sometimes called Time to First API Call, is a key metric to track the effectiveness of your onboarding. Specifically, TTFHW is the time it takes for a developer to sign up for your service and make their first API call. Some products may have a short TTFHW in the range of minutes, but others may be weeks or even months if serious investigation is needed. Keep an eye out for any user segments that exhibit a better TTFHW than others. For example, which marketing channel is the most effective, what integrations are they using, etc. Their first API call could be as simple as a test from Postman or from their production code. For more info, read Best practices for Developer Relations Programs to measure success of an API platform Reducing Onboarding Friction To reduce friction, keep the onboarding flow to around three steps or less. Even if your platform has a large surface area or large integration component, identify what is the minimum integration required to demonstrate value to the developer as quick as possible. This means less critical steps such as setting up custom rules or configuring app settings should not be shown during onboarding. For example, at Moesif we only prompt our new customers to integrate the middleware SDK to get instant visibility into their APIs. Moesif has additional SDKs to enrich the user profiles with demographic info, like plan quota or company name, but we don't prompt users to install those during our onboarding. Instead, we nudge our users via progress check lists and drip emails. When a user redirects to an area of the product not set up, then we display the relevant secondary onboarding page. This practice is sometimes called . gradual onboarding Self-Service Pricing Self-service should imply no- or low-touch sales and almost always include a free tier or a limited-duration trial. If someone from your team has to be on the phone to demo the product or provision a new account, and involve engineering for implementation, then self-service will be extremely hard to pull off. Instead, simply share your enterprise pricing publicly, as the cost of acquisition will far exceed the lifetime value of the customer. Similarly, self-service is not ideal for high contract values. initial While a customer who was initially self-service can increase their usage over time and mature into more expensive plans, they may not have been willing to initially pay for higher plan. Don't launch a developer platform that's self-service just to reduce cost of sales and support effort. Instead, view self-service as a way to open new markets that are too expensive for traditional sales (such as smaller businesses), or reduce the effort required for demand generation (such as in markets with a large user base that can be driven by word-of-mouth). Ways To Price While some companies can garner higher rates, most self-service models do best when the price point is less than $1,000/month, or even less than $500/month. Ideally, you want multiple price points that target a variety of customer profiles and sizes. This can be done through usage based, number of seats, multiple or bundles, add-ons, or a combination of the above. Pick only one pricing model to prevent decision fatigue for customers. Mixing tiers with usage based and seats can confuse the customer. tiers What To Price On In order to scale with customers, many API first companies have some sort of usage-based pricing connected to a value metric. This can be transaction volumes (such as SMS sent), monthly active users, dollar volume, etc. If different customers care about different value metrics, you may need more than one in order to capture the full market. Auth0, a login API, is a clear example of this. Besides company size, they have two types of customers: B2C and B2B. B2C has very high monthly active user counts. Auth0 may appear extremely expensive if they only offered 100 or 1,000 MAU in their lower tiers; We've seen 1,000 MAU for invite-only beta apps, that aren't even launched yet; 7,000+ MAU might be more appropriate for their free plan. Many B2B companies can be in the $10's to $100's of millions of annual run rate, without ever breaching 7,000 MAU. In order to capture value at this end of the spectrum, Auth0 decided to package certain high-value features, such as enterprise sign-in support and advanced role based access control, in their B2B plan. More information on pricing can be found in . The Anatomy of SaaS Pricing Strategy Data-Driven Pricing Once you decide on the packaging and positioning of your self-service platform, you still have to determine actual limits. Does the free tier have 10,000 API transactions per month or does the free tier include 1 million API transactions per month? The best way to determine these amounts is first decide on the price points based on your customer profiles such as free, $100/month, and $500/month. Then, use your tool of choice to cluster users based on their usage data. A simple quick visual glance even scripted k-means will do. Can you find a local maxima in certain groups? You may find trends such as majority of companies with less than 10 employees have around X usage. In order to do this, you need to track usage data per customer and be able to visualize that easily through an API analytics tool like or alternative analytics for API platforms. Moesif Self-Service Support Third-party developers hate emailing or getting on the phone with someone just to resolve a support issue. In addition, solutions engineers, consultants, and engineers are very expensive as first line support. They should be available if a developer cannot find their answer online. This means you need to put effort in documentation, tutorials, GitHub examples, and other self-service resources. Empower the developer to research and resolve their own problem, rather than relying on expensive first-tier support staff. Read for an overview on how to structure your various resources. Designing good Static REST Documentation