Early stage SaaS companies survive and thrive by creating new customer value as fast as they can. Ignore feature requests from your early adopters at your peril. They churn, you fail.
Some feature requests are simple, obvious, and addressed quickly. Of course that new integration makes sense. No wonder that screen is confusing. New features are shipped. Customers are happy.
Then, the inevitable happens. ‘API’ rises to the top of the customer request list. Panic ensues.
Product teams are herded into endless workshops for countless days. Open-ended questions like “what problem are we solving with our API?” and “how can we rethink the SaaS API from first principles?” are accompanied by confounded chin-stroking and endless debate.
But nobody stops to think of what you customers really want. Or the acronyms behind the questions.
SaaS: Software as a Service
When we’re building and selling software, we’re building and selling a set of problem solving tools to enable customers save or earn time, money, or both. When we’re making that software available as a Service, we’re enabling anyone, anywhere, anytime, to interact with the software we’ve built, through a set of services we make available over the internet to enable that interaction.
One of the first services to get built by SaaS startups goes by various names. Some people call it the frontend. Some people call it the UI. Some people call it an app. Whatever you call it, it exists so customers can interact with your product.
This is not your product. It’s one visual interface into your product. It’s a means to an end.
API: Application Programming Interface
Increasingly, customers of SaaS businesses aren’t just demanding access to software anytime, anywhere. They’re also demanding that every new service they choose to use can access and interact with the other services they already use.
Stitching these services together as integrations saves customers time and money by automating repetitive processes, connecting workflows, and syncing data across systems.
These demands manifest themselves through customers requesting ‘API access’. This isn’t a feature request. It’s your customers telling you they need the existing services they use to programmatically interact with yours. Basic feature parity is the baseline. Excellent developer documentation is the cherry on top. Not new features, just a programmatic interface to complement your existing web, iOS, and Android interfaces. Sounds easy, right?
For product teams who treat APIs as features, the reality is usually a lot more complicated.
Kicking the API can down the road
API requests treated as feature requests always end up at the back-end of backlogs. Why? Product teams are rewarded for shipping tangible value. For many product teams, APIs are intangible. If the design artefacts covering your walls mostly consist of screens and user flows, it’s easy forget that those screens and user flows aren’t the only ways your customers will interact with your product.
As new features are released to your web, iOS, and Android interfaces — but not your API — your product steps further and further away from feature parity across your visual and programmatic interfaces. Naming conventions are non-existent, or or inconsistent. Integrations become complicated to build, and impossible for developer partners to build. Your product becomes a silo’d black box.
Customers churn. Because your product is inconsistent and isolated. Not because you didn’t build new features.
Parity, from product to platform
APIs and integrations are fast becoming table-stakes requirements, particularly for SaaS businesses with ambitions to graduate from ‘product’ to ‘platform’ company. As a result, the number of surfaces your customers interact with has expanded from low single digits, to tens or even hundreds.
Slack, with over 1,000 integrations available to their customers, is a great example of this. In April 2018 alone, Slack added 58 new integrations to their app marketplace, most of which were built by partners. This sort of scale demands feature parity across all customer interfaces — visual and programmatic, built by Slack and built by their developer partners. Slack don’t just think about how new features will work across their web, iOS and Android apps. They think about how those features will be represented in their API, and through thousands of other tools.
Feature parity across every interface is more important than ever.
The intangible is the seed of the tangible
It’s also easier than ever to guarantee feature parity across every interface throughout the product lifecycle. A rise in API design tools like Apiary and Mulesoft, in addition to the creation of API design standards like OpenAPI/Swagger, has democratized the API design process. Meanwhile, visual design tools like Marvel’s Handoff are bridging the gap between visual and programmatic interface design processes. Soon, we’ll see API design and visual design happening in tandem, with shared workflows connecting to shared sources of data, and across design and engineering teams.
We’re not far from a future where APIs are thought of as first class citizens early in the product design process, potentially even before visual designs are considered.
To borrow a quote from Bruce Lee “the intangible represents the real power of the universe. It is the seed of the tangible.”