On June 17 I gave a lightning presentation at the Open API Meetup, along with Evan Cooke of Twilio and Oren Teich of Heroku. It was a really nice event, well-organized by Sam Ramji and Shanley Kane of Sonoa/Apigee, and hosted at Twilio's beautiful new digs.
The title of my presentation was "APIs and the Growing Influence of Developers". The gist of my presentation takes many of the elements I have written and spoken about in the past and puts them together in the context of the meetup's topic like this:
Just as we have seen with B2C, we are increasingly moving towards a "frictionless business model" with B2B products, including those targeting enterprises. This means that as a vendor you are trying to remove any barrier from the customer to acquire and succeed with your product.
To succeed with the frictionless business model, you have to adhere to a couple of principles:
Zero Touch
The idea here is to look at every phase of the customer interaction -- from demand generation, through customer acquisition and product delivery to customer success -- and eliminate touch points which create friction. A zero touch model has several benefits: it removes friction for the prospect/customer, making it easy to buy and use your product, and it also significantly reduces customer acquisition costs (CAC) and operating costs.
In the demand gen phase you want to rely heavily on inbound marketing such as SEO/SEM, social media etc. You're then bringing the prospect to your web site where they should be easily able to self-educate (with short video tutorials, easy documentation, etc.), sign up for a free trial and get up and running with something that provides value within minutes. You also remove barriers by providing flexible pricing (such as pay-as-you-go).
In the last phase, which I'll call "customer success", you want to find ways to provide low-touch/no-touch support, upgrading and up-selling/cross-selling.
There is a lot more to say about this topic and it's probably worth several dedicated blog posts, but you get the idea. I will add that although it sounds fairly obvious, it is not trivial to implement successfully.
Bottom-Up
This principle is less obvious. One of the implications of the frictionless model is that it relies on bottom-up adoption. So you are targeting not the CIO, business executives or central IT, as in the old days of enterprise software sales, but on the rank & file, whether business users, IT ops personnel or developers -- depending on the nature of the product.
With this point, I wanted to establish the fact that developers are becoming increasingly important when marketing your software (something I have written about several times before).
Product Delivery and the Frictionless Model
Given that the meetup was about APIs, I focused my presentation on product delivery. Over the years, software delivery has changed, increasingly removing friction from the process.
We can generally think of three main periods, I'll call them: High-Touch, Open and Cloud.
High-Touch Era
In this "classic enterprise" era, folks at big companies who had an interest in a certain software product couldn't touch that product without talking to a sales rep from the vendor. In addition, pricing was never revealed on the vendor web site and contracts were always one-offs that required prolonged negotiations.
You can easily see how this is a top-down model. It requires the involvement of legal, procurement, management authorizations, budgets, etc., and that's only to run a proof-of-concept.
But the delivery of the software product itself was an extremely high-touch approach. Software vendors "darkened the sky"1 with professional services folks in an implementation project that would take weeks, months or sometimes years.
Open Era
But slowly, things started to change, especially as the Internet had started to become a mainstream, commercial medium. Some startups, such as WebLogic2 (before it was acquired by BEA, before it in turn was acquired by Oracle), started offering B2B software for downloads on their web site. And as they did that, they were targeting developers, not executives. And they had to make it easy for people to help themselves with documentation freely available online (a novel concept then) and with easy access to support via email (another innovation).
I intentionally called it open era and not open source era, because source code was just one element of making B2B software products more easily accessible to developers. but certainly, the open source movement is an important part of this phase.
It is because of the removal of these adoption barriers that developers had access to software like never before. First, they downloaded and played around with it, the started developing with it -- next thing you know it's in a production application. I call this phenomenon "enterprise creep-up"3, and it explains much of the success of open source software such as MySQL and JBoss.
Cloud Era
(Not to be confused with Cloudera)
Eventually, as both the business thinking evolved and web technology matured, we came to the realization that software doesn't need to be "delivered" at all. Instead, it's provided as a service. With the concepts of Infrastructure-as-a-Service, Platform-as-a-Service and Software-as-a-Service, the idea expanded to raw IT resources, infrastructure software (OS, VMs, middleware, databases, etc.) and applications.
With this phase, almost any friction involving product delivery is removed. The user/customer does not need to download, install, configure and maintain software. There are no issues of OS and hardware versions. There is no hassle in upgrading -- upgrades happen behind the scenes and you benefit from them every time you log in.
This explains the massive success of Amazon Web Services, and particularly EC2. Developers had unfettered access to IT resources, which they could pay for by the drink and expense to their credit cards, without the need for any approvals. They started by kicking the tires, the prototyping, then developing -- next thing you know, there is a production application on the public cloud.
Software Delivery Models in the Cloud Era
So we now have a range of software delivery options, many of which I listed in Software Delivery Models in the Era of Cloud Computing. The list goes something like this:
- Professional Services
- CDs
- Downloads
- Physical Appliances
- Virtual Appliances
- Images for Internal Cloud
- Images for External Cloud
- Add-on/Plugin/Extension
- Software-as-a-Service/Platform-as-a-Service via Client
- Software-as-a-Service/Platform-as-a-Service via GUI
- Software-as-a-Service/Platform-as-a-Service via API
Developers and APIs
As we are moving to a world where software is delivered as a service, if you want developers to use or integrate your service with their applications, the preferred access method is an API (and as other speakers mentioned at the meetup, a RESTful API at that). An API is a programmatic (i.e., automated) way to access the service, and therefore, the most frictionless delivery method of all (at least when it comes to developers).
Tying It All Together
So with all this background out of the way, the point of my talk was quite straightforward: As developers are growing in influence in the purchasing cycle of software, and as we are trying to move to a frictionless business model, and as APIs are the most frictionless approach to deliver your service to developers -- providing an API to your cloud service is critical.
What's your take on this? As a developer? As a vendor? Let me know in the comments.
Footnotes:
Footnote 1 - At the meetup I mentioned that I borrowed the phrase "darken the sky with professional services" from former Sun Microsystems CEO Scot Mcneally, who used to say this about IBM. That phrase always reminds me of the screaming flying monkeys from The Wizard of Oz so I showed the picture below.
Footnote 2 - As I mentioned at the meetup, a few months ago I exchanged some emails about this with my friend Weblogic co-founder Bob Pasker. As a homage to the Weblogic guys I showed a screenshot of their web site circa 1996, which I picked up from Archive.org:
As a footnote to the footnote, someone on Twitter got excited by the use of Papyrus font!
Footnote 3 - At the meetup I had a slide titled "The Tale of PTB". PTB, or Ponytail Boy, is JBoss founder Marc Fleury's nickname for former Sun Microsystems CEO Jonathan Schwartz (the only Fortune 500 CEO in history with a ponytail). I talked about this blog post from Schwartz that describes the "enterprise creep-up" phenomenon nicely:
I was with a big customer of ours last year, and reading through my account briefing before the meeting, I knew we were doing well. An analysis of their download activity showed they were heavy users of Solaris and OpenSolaris, and they had a large internal community of MySQL users, as well. In the meeting, their CIO said "we love where Solaris is headed." I then asked if we could help with MySQL, and he said... "I banned it."
Not exactly a buying signal.
I was stunned. I asked, "why?" He responded, "Oracle is our global standard, and with 20,000 developers, people need to follow the rules." I said we had a very good relationship with Oracle, and started talking about how fast Oracle runs against our new Open Storage products. 
Until he interrupted me, "...but my ban failed." What? "We hire lots of people out of college every year, and they all come in knowing MySQL. All my prototypes are written to MySQL, and now I have a big base of MySQL apps I don't want to port, and a bunch of MySQL programmers I don't want to retrain. So I'd like a commercial relationship."
In a nutshell, that's adoption in action. Change in IT isn't just a top down phenomenon - it's more often bottom up*.
Recent Comments