New SaaS Objections?
Wednesday, January 16, 2008 by Lincoln Murphy
I'm always trying to learn about real life, in-the-field objections that sales people are having when it comes to selling SaaS products, especially to enterprise clients. There was an article published today on Silicon.com that features an objection to a SaaS product that I have not yet heard of... limited feature set. Wait, yes I have, and this is not a SaaS problem just because the product in question was a SaaS product.
If you aren't interested in reading the article, or the synopsis of the article, here is my take on it. Basically, the vendor showed the client some pre-release features that they couldn't deliver in a timely manner so the client looked for a product that could deliver. Unfortunately to get the features they needed, the client had to take a best-of-breed (do we still say this?) approach rather than an integrated one. This new approach caused problems since sharing data with the systems chosen proved to be a challenge.
This scenario could have occurred regardless of the software delivery method. First, integrating products that are not built to share data is not easy. Whether deployed or SaaS, products that are built without data sharing in mind often cause problems when forced to integrate. I think the mentality with a deployed solution, where you generally have access to the underlying database, is that if push comes to shove, you can drop down and query the data manually. Queries are one thing, but often people think they can import and export data this way. What they often miss is that business rules are enforced within at the application level and by writing directly to the database they could be causing data integrity problems.
Since SaaS products are hosted, a mechanism to directly work with the underlying database is generally not available, nor should it be. The SaaS vendor should know their market, know where they fit in the market, and know what products they might have to integrate with. They should learn this early in the process and create the tools necessary to allow for integration with those third-party systems. This should not come up as a concern to the client if the SaaS vendor has done their homework.
Second, in the case of the scenario referenced in the Silicon.com article, the vendor made the error of showcasing features they were not ready to deliver. Again, this is not a SaaS problem but an age-old problem in the Software business itself. Selling features that do not exist yet, or even products that don't exist yet, is not new, and not limited to SaaS. Software vendors of every kind must be cognizant that over promising and under delivering is not the way to build a sustainable business.
If you aren't interested in reading the article, or the synopsis of the article, here is my take on it. Basically, the vendor showed the client some pre-release features that they couldn't deliver in a timely manner so the client looked for a product that could deliver. Unfortunately to get the features they needed, the client had to take a best-of-breed (do we still say this?) approach rather than an integrated one. This new approach caused problems since sharing data with the systems chosen proved to be a challenge.
This scenario could have occurred regardless of the software delivery method. First, integrating products that are not built to share data is not easy. Whether deployed or SaaS, products that are built without data sharing in mind often cause problems when forced to integrate. I think the mentality with a deployed solution, where you generally have access to the underlying database, is that if push comes to shove, you can drop down and query the data manually. Queries are one thing, but often people think they can import and export data this way. What they often miss is that business rules are enforced within at the application level and by writing directly to the database they could be causing data integrity problems.
Since SaaS products are hosted, a mechanism to directly work with the underlying database is generally not available, nor should it be. The SaaS vendor should know their market, know where they fit in the market, and know what products they might have to integrate with. They should learn this early in the process and create the tools necessary to allow for integration with those third-party systems. This should not come up as a concern to the client if the SaaS vendor has done their homework.
Second, in the case of the scenario referenced in the Silicon.com article, the vendor made the error of showcasing features they were not ready to deliver. Again, this is not a SaaS problem but an age-old problem in the Software business itself. Selling features that do not exist yet, or even products that don't exist yet, is not new, and not limited to SaaS. Software vendors of every kind must be cognizant that over promising and under delivering is not the way to build a sustainable business.
Labels: marketing, product management, SaaS, sales, start-up, technology
| »