One avoidable mistake for SaaS sales
Web APIs as a lever to gain traction, retain users and win big
Most SaaS startups are fighting an uphill battle.
They're taking on incumbents who have momentum on their side. At the same time, they're fighting for relevance and mindshare amidst industry noise. Even with a solid team, idea, and product execution, things can go sideways. Many startups will fail to get initial traction and the few that do can still fail to retain their most important users.
Why is this?
Software purchasing decisions are not made in isolation.
Organizations want to buy a suite of tools that work effectively together.
Startups can rarely afford to sell an "island solution" and expect to win.
Even if you're selling the globally optimal piece of software for a given problem, there's no guarantee that a customer will choose you over another piece of software that's more interoperable with the rest of their tools.
Organizations find bundled SaaS especially compelling.
Software suites like GSuite, Atlassian, Microsoft 365 are able to sell their customers on an umbrella of solutions, even if some of the individual offerings are lackluster (s/o Google Meets). Customers value data portability, unified product support, and consolidated billing enough to look past it.
A prime example is Slack vs. Microsoft Teams. While virtually nobody prefers Microsoft Teams, the fact that's it present and already connected with Active Directory, OneDrive, and Exchange makes it difficult to pass up. Each individual component of a software suite doesn’t need to be a standalone category leader, they just need to fall close enough that the efficiencies outweigh the benefits of switching.
So, how can startups compete?
Startups that strategically use Web APIs can achieve many of the same advantages as larger, bundled incumbents in their space.
Aside: What is an API?
As tired of an analogy as it is, you can think of APIs or "Application Programming Interfaces" as digital Lego blocks. Each block has a well-defined shape and can be connected in a standardized set of ways. Rather than having to build the whole toy car from scratch, you can expedite the process by using a few prebuilt blocks.
APIs allow developers to hand off the heavy lifting to a 3rd party, giving them space to focus on the problems they're most well suited to.
Along with Open Source, Web APIs are one of the most democratizing technologies for building software.
A small development shop can feasibly verify a user's identity (Checkr), confirm their bank account information (Plaid), and send them an ACH credit transfer (Stripe). What would take years, complicated government licenses, and hundreds of thousands of dollars can be done in minutes, paying a small usage-based fee.
While all startups will use Web APIs to build their product, they can also lean on them as a mechanism for winning new users and creating stickiness with existing ones.
Approach 1: Consume a complementary platform's APIs and win their userbase
Startups can go after existing clusters of users who rely on an *existing* software platform (Salesforce, Atlassian, whatever).
They can use that platform’s public APIs to build value-add integrations that make the combination of (platform X) and (new tool Y) compelling to customers.
If I was a new video calling platform and I wanted to go after Sales organizations, I might use Salesforce’s public APIs to build a Salesforce integration that syncs information about leads and enriches CRM data with call metadata. Now, when selling to Salesforce users, I’d have a relevant benefit to anchor on. The more that users rely on this integration as part of their workflow, the harder it will be to replace my product.
Secondly, this approach lends itself to improved discovery. Many platforms have hosted “solution galleries” that highlight 3rd party integrations. Even if you’re a smaller fish for category X, being featured in a “solution gallery (eg. Salesforce Appexchange) will provide outsized credibility among that platform’s audience.
This approach takes a reasonable amount of effort but has a fairly predictable payoff. You can target exactly the sets of tools you want your product to work with, and expect that customers will value the interoperability.
The main trick is anticipating what tools your *future* customers will care about and building integrations accordingly.
Approach 2: Expose your own APIs and nudge developers to make the connection
A higher-effort approach is building out your own developer platform. By exposing your product's data and business logic via a Web API, 3rd party integrators can freely innovate and build their own solutions.
Prospective customers may be able to overlook missing features if you have a public API that they can build against (eg. the lack of scheduling functionality can be hacked together through a Cron job or Lambda function).
Note that building the API won't produce an active developer ecosystem without a lot of legwork.
There's an art to crafting an approachable developer experience, managing API development, and engaging with a developer community. For instance, a consideration is whether you want to bolster 3rd party development with a few integrations of your own (built atop the same public APIs).
While all of this may seem like a large lift (which it is!), the payoff can be immense.
The real magic happens when 3rd party developers build out unexpected integrations (both good and bad!) that can address long-tail needs and target blind spot solutions you may not even be aware of.
Lastly, your users can lean on no-code orchestration tools like Zapier and IFTTT for connecting your “hub” API to a variety of "spokes." By building out a single "hub" integration, you'll unlock the ability for your users to remix your API capabilities with other tools (eg. a Forms tool that connects to not just Airtable, but also Excel, Google Sheets, SQL, and more).
Customers who use your API to fill in feature gaps or to create highly tailored workflows (eg. orchestration alongside internal tools) are bound to be the stickiest, most invested users.
Parting thoughts
Think about how you can Web APIs not just as a tool for building software, but ALSO as a distribution mechanism for getting your SaaS product into more hands.