So, what does a genuine cloud-based product vendor look like? Typically, this is a company that provides continuous product upgrades, support and maintenance as part of the subscription, and the product is served from a multitenant architecture. All customers immediately reap the benefits as the product evolves and improves.
Typically, more than 70% of a true product vendor's revenues are recurring, and come primarily from product subscriptions. Like its on-premise counterparts, a cloud product vendor owns its intellectual property, has product managers, follows product release cycles, and provides upgrades and support for the life of the product. Unlike an on-premise vendor, a cloud product vendor may use a platform-as-a-service (PaaS) or an infrastructure-as-a-service (IaaS) as the base, making it dependent on other cloud providers (for instance, FinancialForce is a cloud product vendor built on Salesforce.com's Force.com PaaS). In other words, a product vendor in the cloud is often the front-end of a consortium of cloud vendors, providing a bundled offering with multiple players supporting parts of its offering on an ongoing basis.
Since this reliance on other PaaS/IaaS vendors is a newer concept, it creates complexities of its own, putting the cloud product vendor in uncharted territory. The concept of multiple vendors working together to meet SLAs, without having exclusive partnerships, is still evolving and generates a lot of competition and conflict. In addition, building multitenancy into the product proves to be challenging and expensive.
To find an easier path, a product vendor sometimes takes a page out of the services vendor's playbook. As opposed to focusing on building a product that can satisfy most customers, the product vendor starts implementing solutions tailored for individual customers. Since each customer pays for the implementation services on an hourly basis, the product vendor is able to generate more dollars upfront as well as avoid making difficult product architecture decisions. The danger is that this temptation may lead the vendor down the road of even more single-tenant engagements (see my previous blog, "Why Multitenancy Matters in the Cloud"). The single-tenant model forces it to continue supporting the unique needs of each customer, increasing its operating costs considerably over time. A product vendor in that situation is, slowly and steadily, forced to follow the path of a services company, and eventually starts becoming one. Customer Hand Holding
Pure services firms (like Deloitte, where I spent part of my career), meanwhile, help companies implement cloud apps and infrastructure, and then charge them for these services. However, some services firms aspire to go a step further and dabble into selling products. The reason is simple: third-party cloud apps or platforms make it cheap and easy for them to create "templates" or "solutions" that they can offer to their customers to create a recurring revenue stream to their otherwise one-time revenue model.
What a service vendor going down this path may not realize, however, is that the recurring revenue model requires it to provide continuous customer handholding for product support, which can be a low-margin business unless it's implemented using a multitenant architecture. The services vendor then becomes even more reliant on growing cash-flow friendly service revenues. It may then use its templates or solutions as bait for customers (so that it can eventually charge them for more services); nevertheless, that makes it look like a product vendor.
In the majority of cases, a product vendor offering multitenant software is the best choice for companies attracted to the cost/value benefits of cloud computing. They'll receive continuous upgrades and support, and will always benefit from the highest point in the evolution cycle of the product. All of this could translate into significant costs savings and added value for the customer. That means, of course, that the product is going to change over time, and the customer must be willing to go with the changes.
A services vendor, however, might make the most sense for customers that believe their needs are very unique. Maybe they want very specific customizations or to build custom apps - or, maybe, they are confident in their own abilities to deliver the cloud computing benefits to their organization. Going with a services vendor would mean that the customer would have to bear the ongoing cost of activities such as customization, enhancement, maintenance and support.
In either case, it's important for a customer to understand what type of company it wants to do business with and choose accordingly, since there can be significant cost implications. It's also important for the cloud vendors to ask themselves the product vs. services question, since the kind of company they need to build can be very different depending on the answer. And venture capitalists and investment bankers need to look beyond standard financial numbers/projections of cloud companies, to ensure those companies aren't inadvertently heading down the wrong path. At a minimum, if you look at how the vendor is providing maintenance, support and upgrades for the entire solution, you should have a pretty good idea of whether they are a product or a services company.
Alok Misra is a cofounder of Navatar Group, which provides cloud apps for the financial services industry and helps software companies launch and support SaaS.
InformationWeek has published an in-depth report on cloud computing and service-level agreements. Download the report here (registration required).