There's an interesting anecdote in today's New York Times that underscores how Software-as-a-Service, through instant usage feedback and frequent updates, can quickly learn what adds value to real users and drive the software in that direction:
"For Jana B. Eggers, general manager of QuickBase, a division of Intuit, the software giant, looking at her market is as easy as clicking a mouse. QuickBase applications run over the Internet, so when lots of new users sign up for a trial, or existing users flock to a new feature, Ms. Eggers and her colleagues see the patterns instantly."
The article describes how Intuit saw that rather than small companies adopting QuickBase, large companies were using it for different tasks. Intuit redirected their marketing and product development in that direction, leading QuickBase to be the "fastest-growing business unit in Intuit."
Compare this to on-premise software products, where it can take months or years for enough customers to upgrade and actually use the latest release to be able to discern how well the software works for customers in practice. The feedback mechanism for on-premise software is also broken, since the vendor often doesn't work directly with customers but relies on implementation consultants to get the software running.
As an example, last year I interviewed a Quality Assurance manager from one of the big ERP software providers, who described a "bug-fest" project they were working hard on because the latest release of the software has so many bugs. Out of curiosity, I asked how much time had passed between the software being released (to thousands of customers) and the company getting enough feedback to discover that there was a bug crisis: "A year," she answered.
A year! The ERP software version had been fully tested and put on a CD and shipped to all their customers, and it was a year until enough customers were actually implementing the software that feedback finally made it back to the on-premise provider that there were more than the usual bugs.
That is why customers usually wait for the first service pack of any major on-premise software release - no matter how much Quality Assurance the on-premise provider performed, their tests simply don't reflect the customer's configuration, data, or usage patterns. The software has to get out into the real world to really get tested.
SaaS providers perform enormous amounts of Quality Assurance because if something doesn't work right, it quickly impacts their customers in 12 hours, not 12 months. Fortunately, SaaS providers already know and can easily test all their customers' configurations, data, and usage patterns - it's all in the SaaS system, and it's all tested before the upgrade is implemented.
This high-metabolism product development - create a feature, get instant feedback, improve and extend the feature within a few weeks - is a new concept for product development overall, not just software. No other business or consumer product has had the immediate relevant feedback, product agility instant deployment throughout the customer base to leverage this learning cycle.
SaaS providers who get closer to customers and speed up their metabolism will drive their products faster and more effectively in the direction the market values, creating a sustainable advantage over those behind or slower than them. According to the New York Times article, Intuit has adopted this approach:
"'So often with software, developers expect a certain feature to be popular, but a different feature winds up being what customers want,' Ms. Eggers said. 'A lot of companies try to explain away these surprises. We embrace them.'"
In other industry expert opinions, what would be the additional saas development consideration factors besides those listed here?
http://nearshoresoftwaredevelopment.blogspot.com/2008/12/rapid-saas-development-alternatives.html
Posted by: jezzaman | December 01, 2008 at 09:09 AM
Alan, thanks for the comments & questions, to respond:
1. SaaS feedback collection is built into the service - the SaaS provider has access to all the customer configurations, transactions, and data. Mature SaaS offerings keep a record of usage patterns and transactions for analysis to determine what works well, and what doesn't, in the software.
2. With multi-tenant SaaS, there aren't any customer-specific features, all functionality is available via on/off switches in the configuration backbone. So any unique situations are handled by turning on the unique feature for the particular customer, and off for everyone else. For the SaaS provider, there's still only one code base and software version to support, maintain and upgrade.
Posted by: John Martin | August 15, 2006 at 05:43 PM
Enjoyed reading this and several of your other entries. It is definitely a high-metabolism world we live in, and software development is no different.
I'm curious about two things.
1. How does SaaS collect feedback? Do you intergrate it into the service, or collect it thru more traditional means?
2. How does SaaS avoid your stated disadvantage of multiple versions - how do you handle unique and custom situations of your customers?
Posted by: aswitzer | August 15, 2006 at 09:48 AM