Increasingly in tech, the Software-as-a-Service (SaaS) business model requires a rapid momentum towards gaining enterprise customers. Over the last several years, this need has sped up, with the start of this year proving that since the broader market does not fully understand the SaaS model, the need for SaaS-based businesses to future-proof themselves by having enterprise customers on board is even more urgent. Nowhere is this need for market survival greater than amongst API products and service providers, who are increasingly entering the market with a focus on enterprise uptake from day one.
SaaS models are an approach the tech industry has seized on since around 2012. SaaS has been the economic context that has influenced the rise of the distributed architecture paradigm now driving application development globally. The startup and agile model of providing a minimum viable product and iterating new features and capabilities via a continuous delivery pipeline are part of what gave SaaS a key opportunity amongst early adopters willing to bet on the risk of choosing an untested product. In tail-wagging-dog fashion, it has become a microservices model for how tech startups can continue to innovate and deliver new value to customers without requiring a monolithic download to upgrade business or consumer software.
Initially, while there were SaaS products targeting business, many SaaS-modeled startups focused on end customers and consumer-related products. LinkedIn, Dropbox, Spotify, Airbnb, and countless others all focused on end consumers. The idea was to grow a massive consumer base to strengthen their longevity and then pivot towards enterprise customers.
This was most recently evident in Slack’s playbook, which has a consumer-facing design aesthetic that appeals to individual consumers who decide to use it. Slack has been able to increase its uptake amongst business teams in this “Shadow IT” manner before a more concerted strategic focus on appealing to enterprise customers. (Slack first brought on a team to lead enterprise uptake in June last year, while consumer-facing social media giant Facebook only officially launched their Facebook at Work product in December 2015.) This is not a particularly new insight: Roderick Morris pointed this out a year ago in his Medium post, but since the start of this year, it has become a more essential driver.
At the end of the first week of February this year, many publicly-listed SaaS products suffered a market drop of between 40% and 60%. Now at the end of April many have bounced back (Salesforce has almost completely recovered its market price, for example), most are now averaging the same valuations they had twelve months ago, having shaved off all their growth that occurred through the second half of 2015.
Financial Times cloud computing analyst Richard Waters says one of the reasons for this is that businesses with a heavy upfront investment and cloud software model “have yet to show they can execute” on a business plan that will grow cash flow profit margins from subscriptions, singling out Salesforce (now with 16 years operation under its belt) as the “first SaaS company to have made it into the mainstream enterprise software market.”
Tech companies offering API products and services, then, are entering this economic context with two additional pressures. First, they cannot leverage the “consumerization of enterprise” advantage in quite the same way as, say, Slack, via a broad appeal to end users and a fun user experience that encourages viral growth. Secondly, as API products and services, they are more often building a platform that requires not just a SaaS model, but the ability to share revenue across the value co-creation chain with partners, suppliers and end customers in a more programmable configuration.
This year, we are seeing some API product companies using five key strategies to gain an enterprise foothold.
Route One: CloudRail Treats API Devs as Consumers and Takes the Consumerization of Enterprise Approach
“The problem with APIs is that developers are seeing the need for more and more integrations, but they are not building them because it is more and more complicated,” says Felix Kollmar, CEO, and co-founder of CloudRail, an API interoperability platform. CloudRail allows developers to create a custom API built on multiple SaaS services and provides an SDK so that the developer can integrate the multiple services via the one API. The API works like a funnel, drawing in disparate APIs with a variety of data schemas behind them, and creates the one API for the developer to use.
“Developers aren’t in the core business of integrations, but they are faced with problems of integrating services every day,” says Kollmar. “We help them create a universal API so they can bundle everything into one endpoint so all the services they need to consume, feel the same way.”
To encourage community growth, CloudRail is focusing on a crowdsourced, social platform-type approach where developers are encouraged to share which resources they need available in the CloudRail catalog. “We currently have 32 resources available via CloudRail,” says Kollmar. “A developer who is missing a service can add it to CloudRail, or a provider can add it.”
Currently, CloudRail is treating developers as their end users, and appealing to them directly. (A strategy that The New Stack’s Lawrence Hecht is following in regards to how Slack is influencing the enterprise.) Developers can use the CloudRail workbench product for free when building applications and the team is focused on community marketing techniques that interact with developers directly, with the hope of having developers contribute back to the community. So far, that has helped drive CloudRail’s decisions around which APIs to integrate into their platform next, with “mainly developers identifying which APIs to integrate, our focus is particularly coming from mobile developers.”
Eventually, CloudRail hopes to push into the Internet of Things market — perhaps with a better model than previous attempts have done which in the past have focused (unsuccessfully) on charging developers for API integrations. Kollmar can see CloudRail becoming “the API for the Internet of Things, particularly in smart homes and wearables,” he also believes it is still “a bit too early” to see an end market for this frontier.
To reduce the risk barriers for developers, CloudRail avoids a vendor lock-in system. Kollmar is quick to explain they are not open source (it is being considered) but they do have a “developer-friendly proprietary license.” It lets developers use CloudRail to create their API funnel, allows developers to embed the code into their products, and sublicense it through having it available to end users and partners through their applications, but developers must not share the code directly.
“The cool thing is, we don’t have something in-between. After you have installed the SDK, it works directly because it doesn’t come via a middleware platform.
Kollmar is circumspect about talking up enterprise use cases at present, saying those who are on board are at an early adoption stage and not wanting to speak publicly. In the main, CloudRail’s users are developers who want to create a consumer-facing app but are already ending up using 50% of their time on building integrations. As CloudRail builds up its developer community around its product, it is also introducing an enterprise pricing model, with service level agreements, enhanced customer support, and an on-premise delivery option.
Route Two: StreamData.io Chases B2B Market Opportunities
Real-time push API service, Streamdata.io, chose to focus on B2B customers initially, rather than target larger enterprise specifically but has already picked up both large customers and businesses that are working directly with consumers. Winning several awards for innovation, fintech and getting votes on developer platforms like StackShare is also giving them kudos. Streamdata.io works on top of existing REST APIs to introduce real-time stream processing so that the API can act as a real-time stream. The service has seen take up amongst fintech and other API services like Restdb.io and Restlet.
“We focused on B2B acquisition from the beginning as a corporate decision,” says Streamdata.io CEO, Eric Horesnyi. “We chose to be a technology-focused vendor. B2C monetization requires different skills and cultures, and investing in these resources would have defocused us from exploring the tech frontier. Our first B2C customers started to use the platform three months after our launch. They went beta when we went GA (roughly another three months), at which time B2B monetization started for us. Large-scale implementation started three months after that.”
Horesnyi shares advice on how API tech startups should focus on growth: “The important thing is to focus on yourselves as a team, your skills, and your aspirations.” He cautions that Streamdata.io’s approach works because it suits the business values and goals. “B2B seems a less-risky route for tech-heavy startups, but, with the right skills, an API-focused company could start servicing B2C while staying lean and technical. My best advice would be to go lean: find early adopters, develop step-by-step, and raise funds only if necessary, once the market is identified.”
Horesnyi admits that one of the greatest difficulties for API startups focusing on enterprise is that at first, new enterprise customers are reluctant to talk publicly about using the product, but it is when enterprise do share their examples that other enterprises are more interested. (This is the chicken-and-egg situation that CloudRail are trying to get around with a dev-as-end-consumer strategy.) Storytelling becomes essential, says Horesnyi. “Using PR for initial success is fundamental: Nobody starts listening to what you intend to do until you can present a real life use case,” he says. “You need to plan for it from the beginning. From the first interaction, you need to think about all the valid reasons that this enterprise’s communication team needs to be associated with your company based on the project. Going public is fundamental from the very start.”
Horesnyi is quick to caution that while sharing the enterprise use case is important; it shouldn’t be to the detriment of a focus on value: “With limited resources, at some point, you may want to focus more on just offering the best service and value for the money. Happy customers are always your best sales team.”
Route Three: Cloud Elements Bridges B2B to B2E
Cloud Elements offers an API integration middleware platform that allows businesses to create a universal API to move data, automate workflows and build apps. CEO Mark Geene differentiates the Cloud Elements offering from CloudRail and other API funnel-type services saying it is more customizable with an enterprise’s system of record than those integration services that connect to an end user applications’ resources.
To appeal to enterprise customers (which now already includes unicorns HubSpot and KISSmetrics), Cloud Elements has focused on an in-depth understanding of the enterprise context.
“In enterprise, you have a whole heap of business units that have a system of record with serious data objects that have custom data. 99% of CRM systems, for example, have custom fields and the ability to map and transform data from those fields is the next level of sophistication that it is required,” says Geene. He points out how in the past, an integration platform as a service would typically be responsible for a business process like connecting customer data with an invoice, but that is now being done at a business unit level, requiring more departmental tooling rather than organizational-wide IT systems.
This year, Cloud Elements has seen an increase in Internet of Things use cases, where enterprise and larger business customers are creating new interactive products.
“We are providing a way for IoT developers to abstract IoT devices,” says Geene, who thinks this will be a leverage opportunity for Cloud Elements in the increasingly IoT-focused enterprise space. “A lot of what we are seeing is that companies are saying we have to do things differently to enter the IoT. They are using AWS to control those devices. They don’t have public APIs; the devices are not open and public yet. So they are creating an application that is open and public, and putting the API there, at the application layer.”
Route Four: ClearBlade Leverages IoT To Go Deep into The Enterprise
Like Cloud Elements, API management platform ClearBlade is focusing on where enterprise is moving into the Internet of Things to grab their foothold. “IoT is a huge problem,” says Aaron Allsbrook, CTO of ClearBlade. “At the bottom, there are devices that may be the best of their breed and using the best protocols, but they are probably not doing REST calls. Then above that is ClearBlade’s Novi Platform, which lives in the cloud, and allows you to build an HTTP-based REST API, and an MQTT-based API. And then above that are the enterprise systems of record where the real world has occurred in the past 20 years, and we connect that up and down.”
Like Geene, Allsbrook is acutely aware of the enterprise context and is making sure that is communicated through their product offering. “We are very enterprise-focused, ClearBlade fits very well with industrial IoT.” He describes two use cases: one where a ‘smart factory’ is using their product to integrate customer data from legacy systems with machinery and systems in a smart factory.
A second use case involves ClearBlade’s Novi platform being used to enable a trucking company to combine driver and HR data with vehicle sensors and weather and traffic data to improve engagement with truck drivers. “These enterprises have lots of good data about their trucks in their backend systems — turning speeds, tire pressures — but now they can put that data in front of the driver immediately, understand loyalty, efficiency and tie that data together a little more tightly. Enterprise is trying to enrich the impressive amount of data they hold, which up til now has been lazy data and sitting data.”
“This is where we are finding a ton of traction with the enterprise. For each company, there are 18 different ways of understanding the holistic view of their data; we are helping them integrate all of that. That is the pattern I see coming for IoT this year,” Allsbrook says. To win enterprise over, they have been focused on handling data security and managing the integration platform that brings all of the APIs together, rather than on GUI front-end interfaces, which Allsbrook says the enterprise developers want to control themselves.
Like Geene, Allsbrook says API products appealing to enterprise need a deep level of integration: “We work really hard to go back to enterprise. It is not enough to say your product gets to Sharepoint. The real value is when you can get deep into the enterprise.”
Route Five: Hitch and StopLight Launch with an Enterprise Customer in Place
New API startups Hitch and StopLight have both launched this year with a high-profile enterprise customer already in place. Here the lean startup model is being tested directly with the enterprise in the initial case to ensure market fit and customer alignment.
Hitch, built by API industry leader Bruno Pedro and co-founder Luke Miller, aims to act as an intranet-like portal for enterprise so that internal developers can see all of a company’s APIs in one place. While ‘API dogfooding’ is considered an industry best practice, the truth is that many API enterprise programs struggle to get internal developers to notice what is available to them by way of API.
Hitch launched with Atlassian announced as an initial customer, with CEO Luke Miller pointing to the enterprise software company’s willingness to share a testimonial on their website as a key strategy to demonstrate their suitability for enterprise adoption. Development Manager Seb Ruiz writes that “Hitch gives us greater visibility of our internal APIs and keeps the Atlassian developers and product builders informed of the current state of play of their entire API supply chain.”
API Design Studio StopLight took the same strategy when they launched in February this year. Having tested their product with early adopters, CEO and Founder Marc McLeod built strong relationships with another tech unicorn, SendGrid, to ensure the enterprise was getting high value across the business from using the tool. SendGrid were even able to ‘launch first’, talking publicly about how they use StopLight in a blog post before StopLight’s official launch.
Building and Monetizing Enterprise Solutions in the API Space
API products and services can be a hard sell in investment circles because they are the behind-the-scene drivers that are helping enterprise speed innovation and create a new generation of digital products. But they are not necessarily the front-facing end user tools that grow virally in the enterprise. That often means that they must more convincingly prove their market value before gaining (smaller) pools of venture funding. So any investment they do receive gets burned through faster, meaning enterprise deals need to be locked down at a rapid pace.
Now, as API products and service providers get used to that, even more, change awaits. Responding to new entrant demand, industry thought leader Kin Lane recently released detailed research into API monetization strategies to help this competitive and active market to calculate better a long term strategy for survival. Meanwhile, the serverless application environment and ease of accessing cloud storage and compute power is shaking up business models again. Serverless app developer platform Syncano is a good example of how new pricing models are being implemented in the API space. They offer their product for free for those developers building applications, and when at the production stage, API calls, and code computing power are charged on a thousandth or millionth of a dollar. StopLight’s McLeod sees this as the future for a lot of API product business models.
Fast-tracking enterprise customer acquisition will be at the heart of success for many businesses offering API products and services in 2016.
Read the original article by Mark Boyd on The New Stack.