Posted by Tom Grant on December 7, 2010
One of the face palm moments I had while researching PM's role in SaaS was the timeline for platform and app development. The traditional path for on-premise products was platform first, then application. The cloud products flip this sequence, putting the applications first, then the platform. We're so used to seeing this pattern that it's easy to take it for granted, or mistake the reasons why it exists (hence the face palm).
There were two reasons for this evolution in the natural history of a tech vendor's portfolio. The first is distance from the customer. In an on-premise world, where there's a lot of geographic and organizational distance between the producers and consumers of technology, the collection mechanisms about customer adoption (infrequent "How ya doin'?" conference calls, cryptic bug reports, etc.) are labor-intensive. For however much effort you put into this research, the information returned is often incomplete, distorted, or just plain wrong. For example, the game of Telephone played among product teams, customers, and the salespeople in between often leaves PMs with more questions than answers about what a customer really wants.
Therefore, the product strategy for on-premise products have to accommodate a lot of uncertainty about how customers use the technology. While it's not the only reason for customization and custom application development, it's certainly an important one. Rather than guess wrong about customer adoption, on-premise vendors tend to say, "Here's a toolkit. Go build what you want."
With the cloud, tech vendors can collect more accurate information about customer adoption at a lower cost. Armed with better information, development teams have greater confidence that, if they build an application, it's the one that most customers want.
But that's not a sufficient information of the flip in the portfolio's roadmap. Tech vendors might still build toolkits, or toolkittish applications, to cover a wider swath of potential customer requirements. Which brings us to the second reason for the "application first" strategy, the company's ability to deliver value.
Salesforce.com just announced Database.com, the latest in a series of infrastructure components that form its platform strategy. The Force.com platform already includes an application development framework (Appforce), a web content management system (Siteforce), a Java development environment (VMForce), and an application commercialization and delivery framework (ISVForce). Appforce further modularizes many application development components, such as analytics and workflow.
Salesforce.com made all of these products available long after it cemented its position in the market as a reliable provider of salesforce automation and customer service applications. Delivering value through applications, and demonstrating your continued ability to do so in the future, is the first priority for a cloud vendor like salesforce.com. Without short time to value, what's the point of being a cloud vendor in the first place?
The value stream puts SaaS at the prow of the ship. Even the best platform technology imaginable for building an application has an inherently harder time in the market than the application itself. Customers then size up the company to see how likely it is that the value stream will continue to flow. As my colleague Tim Harmon often says, tech companies compete on the basis of their business models than their technology. SaaS is really a different business model, in which proving sustained value delivery is paramount, changing the sequence in which a vendor fleshes out its portfolio.