Building SaaS

Why On-Premise Software Vendors Can't Innovate

Vinnie Mirchandani started a firestorm with his observation that "in existing Oracle internally-developed and acquired products in the last 5 years, Oracle’s enhancements have been anemic."

How should we measure innovation for enterprise software? I think it should be measured by customer business impact - not press releases or software demonstrations or even what's "available for download" from the vendor's website, but what is actually used by customers and how much it improves their business results. After all, enterprise software is all about streamlining business processes and enabling enterprises to do things they couldn't do before.

And this is where on-premise software (not just Oracle) falls woefully short. It doesn't have anything to do with talent or effort, there are thousands of hard-working, smart developers at Oracle and other on-premise software companies.

No, the reasons for lack of innovation are endemic to the on-premise business model and the on-premise customer ownership experience. (Bob Warfield starts the list on his blog). The bottom line is that on-premise vendors can develop all the code they want, but because of the high hurdles to upgrading to actually use the new software, most customers can't or won't upgrade for many years, so any "innovations" remain on the distribution DVD and have zero impact.

Why can't on-premise software vendors innovate? Because:

• Development talent is wasted maintaining old versions: since customers don't upgrade, the vendor must support old - even ancient - versions of their software. And upgrades must work with many old versions... again multiplying the effort to write upgrade and migration scripts.
  
• Development talent also wasted porting to multiple platforms: porting the application code to multiple databases, operating systems, and application servers requires a significant amount of development work and time, not to mention significant testing and documentation efforts, and also further multiplies the technical support efforts.
  
• Multi-platform support constrains innovation to the least common denominator of the various platforms: it's hard to be innovative when you're focused on making every new feature work across multiple versions of four different databases.
  
• Long release cycle times reduce ability to innovate: All the porting, multi-path upgrades, and testing efforts mean that releases are very slow in coming - maybe a release a year at most. By contrast, even SaaS applications that have been around for a decade can release new functionality every 3-4 months because all these wasted efforts are eliminated.
  
• On-premise vendors lack intimacy with how customers use the software: On-premise vendors have no idea what the customer's business processes, configurations, setup or data looks like. In addition, they are shielded from customers by the system integrators who perform the lengthy implementation projects. Innovation involves applying technology to solve customer needs, but since on-premise vendors are somewhat blind to how their software is used in practice, their ability to innovate is severely hampered.
  
• Customers don't upgrade: Even when some modicum of innovation is achieved, customers must upgrade for the innovations to have impact, and upgrades are infrequent because they are so costly to customers. For example, even after two years of availability of Oracle E-Business Suite Release 12, less than 5% of customers have upgraded to it.

This is the core issue with on-premise software's lack of innovation - existing customeres, who have committed to the vendor's software, get trapped for years and years on their go-live version with static capabilities, ever-declining support, and no-value maintenance fees, until they decide to disrupt their business and undergo a costly upgrade project.

Of course, SaaS doesn't have any of these issues - that's why it's a better way to build software and deliver innovation to customers. Most enterprise customers don't yet understand the benefit they receive from ongoing innovations delivered by SaaS, without upgrade headaches or costs. But this is changing as enterprise customers experience SaaS's ongoing innovations first-hand.

On-Premise's Wasted Development Efforts - Who Misses It?

I was talking with one of the analyst firms this week about SaaS, and one of the analyst's questions was "which of your costs can you leverage across your customers?"

The answer is: SaaS takes advantage of economies-of-scale for many costs of operating the software, including the production infrastructure, operations costs, upgrade costs, and many support costs.  Instead of each customer incurring these costs separately and duplicatively, a SaaS provider leverages these costs across all customers, greatly reducing the cost of ownership for each customer.

For example, a Fortune 500 customer's installation of an enterprise application requires about a half of a person for database administration - installing and maintaining dev/test/prod, performing backups and recoveries, applying patches, monitoring and tuning, performing upgrades, etc. So 50 enterprise customers pay for about 25 database administrators in total, whereas a multi-tenant, single-version SaaS provider uses a fraction of the database administrators to deliver the same or better administration quality.

But just as interesting, I told her, are the costs that are completely eliminated by the SaaS business model. Chief among these are the costs related to "porting" - i.e., making the software run on different platforms and supporting hundreds of platform permutations.

In an on-premise software company, when a new version is ready to ship, the development isn't actually completed - the software has to be ported to all the databases, application servers, and operating systems that the company supports. For an enterprise application software vendor, this includes all the major databases (Oracle, SQL Server, DB2, Sybase), the major application servers (WebSphere, WebLogic, Oracle AS, Jboss), and a dozen or so operating systems.

A SaaS provider, by contrast, runs only on its "reference port" - i.e., the platform that the software is built on, tested on, and operated on. This avoids a huge amount of effort, delay and complexity in several areas:

• Porting effort: Developers really don't like to do porting work, as this is a frustrating and low-value "just get it working" effort. It's also not enough just to port to another platform, often the software must be ported to multiple versions of the platform, further multiplying the effort. Installation scripts and release notes also have to be written and maintained on each port for each version - and all this effort is completely obviated by SaaS.
• Maintaining port and version compatibility matrices: With all of the software versions and various platform versions, someone has to keep track of which combinations have been confirmed to work and are supported. This is a non-trivial task, as thousands of combinations are possible and hundreds are typically tested and supported -- here is an example of a resulting compatibility matrix. With SaaS, the compatibility matrix is reduced by a couple of orders of magnitude, at least, and the customer doesn't have to worry about any of it.
• Supporting the various ports: Once the software gets out "into the wild" - i.e., installed at a customer site - whatever platforms and versions combination that the customer choose must then be supported by the software provider. And since customers really don't like to go through the hassle and cost of upgrading (which breaks what's already working), they'll stay on old versions of the database, application server, and your software for as long as possible. So when the customer calls with a problem with the software, the on-premise software vendor has to re-build the old versions of platform software to try to match what the customer is running, apply patches and customizations, and try to reproduce the issue. This is all wasted effort compared to supporting SaaS software, where the vendor already knows the software version, platforms, data, configuration and usage patterns - all automatically.
• Building abstraction layers: When building application software that runs against several different relational databases, eventually the engineers will write an "abstraction layer" that generates SQL that every database can understand, in order to insulate the application from the many differences among the databases. These abstraction layers must be developered and maintained across all the various platform types and versions, a significant effort that is simply unnecessary with SaaS.

All this wasted effort - greatly increasing cost, delay, and complexity  - is eliminated by SaaS, enabling SaaS vendors to apply a far higher percentage of their development effort on new functionality and value to customers, and lowering the total cost of ownership for customers as well.

Who misses this wasted effort?  Certainly not SaaS developers - I can't imagine asking them to do low-value-add and unfulfilling tasks like porting our code to various databases, writing abstraction barriers, or diagnosing bugs in 3-year-old versions of our software.

As usual with SaaS, there are not only cost advantages, but also increases in value to customers.  Related to porting, running on only one platform and one version allows SaaS vendors to provide far better support of the entire SaaS solution.

Another key aspect is that on-premise software vendors must write to the "least-common-denominator" of the platform software, and cannot take advantage of any helpful features or aspects of any one platform - while SaaS can and does take advantage of their chosen platform's distinct features to deliver more value to customers in terms of performance, functionality, and cost of ownership. This will be detailed in an upcoming post.

Why We Don't Offshore Product Development (Part 4)

So far I've outlined why we don't offshore product development from a customer's point of view - mainly because onshore development gives much better responsiveness and quicker cycle time. SaaS's collaborative, fast-response product development and maintenance processes don't lend themselves to overnight development.

Now for the "internal" reasons. These aren't as directly visible to customers but have big impacts on the team's productivity and product quality. Because of these reasons, we have found that we can develop higher-quality and higher-value SaaS software in Denver for the same cost as in India.

• The Collaborative and Creative Nature of Software Development: As described the last post, a customer-collaborative process increases the value of software through frequent feedback and course corrections. Just as importantly, the internal software development process benefits from close collaboration among product management, development, quality assurance, and customer-facing personnel.
  
  Collaborative refinement of specification and design will deliver far higher-quality software than rigidly following a spec. KANA Software, in their offshoring efforts, found "that our offshore developers often told us, 'Here's what we built, exactly as you wanted - but it won't work, and here's why.'"
  
  In addition, software development is different than product manufacturing because every software requirement is unique, and requires creative and learning problem-solving to get to the best answer. If you're making thousands of exact copies of a widget to a specification, then offshoring is great - but "software factory" is an oxymoron.
  
  In fact, some researchers have characterized software development as "artful making", as described in this excerpt from IEEE Software Journal: ("Software Making as Art"; Austin, R. and Devin, L., pp. 93-95, January/February 2003):

  "Artful making... has a recognizable structure. It’s iterative and thus involves doing and doing again... It de-emphasizes planning in favor of learning from experience. It delegates control to makers themselves, aspire to enhance individual and idiosyncratic talents, and uses the environmental uncertainty of ongoing change to fuel innovation... The difference between a good and bad system is not how well it meets the requirements you know in advance. Meeting requirements is a necessary but insufficient condition for producing an excellent system. What makes a system great is details that are not specifiable in advance—aspects that must evolve in the making... As long as our processes are structured for conformance to advance specs, we’ll have problems because software development’s essence is creation, not conformance."

  In short, software development is a creative, collaborative process, and offshoring breaks the short-cycle value-increasing collaborations.



• Far Lower Maintenance Effort With SaaS: Offshoring product development to India initially gained momentum with offshoring software maintenance to India. The first impetus was the Y2K effort, where lots of COBOL programs were shipped overseas for scrubbing to ensure that next-century dates were correctly handled, and in the process India built up infrastructure and capabilities maintaining software offshore.
  
  The second impetus was actually driven by the nature of on-premise software - over time, the on-premise software vendor has to maintain more and more old versions of the software on a myriad of platform software combinations (operating system, database, application server, etc.). The longer the software vendor has been around, the more maintenance effort there is, and The Economist has estimated that up to 80% of development effort and cost is absorbed by maintenance.
  
  Once offshoring became a viable option, on-premise software executives started saying "Why am I paying six figures to each of my senior developers just so they can create hundreds of patches each month? We can offshore maintenance and lower our costs by more than half, and if patches are a little lower quality or slower to be delivered, well that doesn't matter because our customers on maintenance are locked in anyway." Plus, developers liked being relieved of this effort because maintenance required them to work on 3-year-old code and repeatedly fix the same bugs across multiple versions, which is a lot of unsatisfying grunt work. So by offshoring maintenance, everyone was happy and maintenance fees became even more of a money-maker for on-premise software vendors.
  
  With SaaS software, maintenance is a much smaller effort because the SaaS vendor only maintains the current version, and whenever an issue arises the SaaS vendor already knows the customer's configuration, click-stream, and data - so issues are easy to diagnose. Working only on the current version also means the context is already there - the developer is fixing a bug in code that they worked on a couple of weeks ago (rather than years ago with on-premise). As a result of these factors, in our instance, maintenance is typically about 10% of the workload. In addition, maintenance is a key feedback mechanism on the quality of the software and UI design and implementation, improving our internal learning and consistency. So offshoring SaaS maintenance is simply a non-starter - it's a small part of the development cost and also has a lot of value to the development team that would be eliminated by offshoring it.



• System Engineering: Finally, development SaaS software involves a lot more than just adding functionality - since all users will be able to use the feature overnight, the software developer has to design and develop for performance, deployability, UI consistency, monitorability, diagnosability, maintainability, flexibility, enhanceability, etc. - a lot of "abilities" that helps operations deploy the software and monitor it, helps the developer diagnose and fix any issues quickly, and helps enhance the functionality for the next version.
  
  With on-premise software, many of these "abilities" are pushed to the implementation consultants or customers' IT shops to figure out. Others are deferred until the release is out and customers upgrade to it years down the road. The on-premise developer's goal is to get new functionality working well enough for sales to demonstrate it, since customers won't actually use the software in production for quite a while. By then, the offshore team is fixing issues.
  
  But SaaS is used immediately in volume by all customers with their varying usage patterns. So SaaS developers do a lot more than design and code functionality, they are actually system engineers - envisioning how users will use a feature in context, how their code will perform in the real world under load and with the other system components, and what likely directions the maintenance and enhancement effort will take.
  
  Many of the system "abilities" are unspecified in typical software requirements, and some are even unspecifiable as they are internal to the development process and not visible to the software users. Consistent with the creative process outlined above, the system engineering to address all these "abilities" requires highly knowledgeable and highly versatile developers who have the customer context and full range of understanding of how the software will be used, in order to make many judgments and tradeoffs among the various "abilities" when building a software feature.
  
  So while offshore development can develop software so that the screens behave correctly, attaining this level of customer-knowledgeable system engineering that incorporates all the abilities - critical for successful SaaS software - is close to impossible.



• Internal Design Consistency: Another implication of the "abilities" in the last point is that the resulting code needs to be internally consistent in order to maximize maintainability, and also to be compatible with all the non-functional components that make up SaaS software - the monitoring subsystem, configuration backbone, integration framework, etc. Using established design patterns which are supported by the underlying framework will result in more consistent and higher-quality software, since the design patterns and framework have been proven out through multiple maintenance iterations.
  
  We found out the hard way that a separated development team can get the functionality working right and pass all the software quality assurance tests, but under the covers use some new approaches that prove much more difficult to maintain and requiring significant rewrites. Fixing this issue with more training and constant oversight just increases the time and cost of offshore development, not to mention also decreasing the satisfaction of the local development team since they're reviewing checkins and writing emails and checklists rather than coding.
  
  With our local development team, design consistency comes from continual hallway discussions, ad-hoc design reviews, and real-time "ask the expert" queries of the subsystem owners. Sure, an offshore team can read the wiki and email their questions, but answering a question right when it arises with high-bandwidth conversation results in far better software, compared to a day-later email response.

In short, building SaaS software requires a fast-response, customer-knowledgeable, collaborative system engineering effort that also satisfies unspecified (but highly valuable) customer and internal requirements. Satisfying these requirements - and iteratively evolving an excellent system through artful making - cannot be done effectively across 12 timezones.

Measuring Developer Productivity

Joel on Software, as usual, has a great post about software development with a lot of truth in it - in this case, about the impossibility (and even inadvisability) of measuring software development productivity.

As Joel points out, measuring software development productivity is a subset of the problem of measuring knowledge worker performance, which is prone to gaming once a quantitative metric is applied. (In a Dilbert strip, when the programmers were awarded $10 for every bug they found and fixed - even if they created the bug - Wally says "I'm going to write me a minivan this afternoon"!).

But gaming aside, the even bigger reason knowledge worker productivity is hard to measure (and manage) is: How do you measure knowledge worker output, or more importantly, value?

It's especially hard to measure the value of a software developer's work, since there are so many variables that confuse activities with software value, as The Parable of Two Programmers deftly demonstrates.

One of the great things about running a Software-as-a-Service development group is that the software's value is a lot more readily apparent than with on-premise software. With SaaS, the feedback cycle is so quick and direct (through immediate usage by all customers) that many of the components of software value are apparent very quickly - the software's robustness, maintainability, usability, and performance.  All the elements that go into software quality are fully visible to the developer and to management within days, giving excellent insight into each developer's productivity (i.e., value per day) and improvement trajectory.

In addition, the entire software development process benefits from fast customer-based feedback. For example, if Product Management prioritizes a feature that customers end up not using, the software developer challenges them with their future prioritizations.  This accountability helps ensure that Product Management is focused on features that will be used and provide the most value to customers. 

Another aspect that I regularly push is to get a feature in front of customers so we can see how they use it and give us guidance on version 1.1 within days or weeks, not years (as used to be the case with on-premise release cycles). A fast-turn SaaS development approach makes it cheap to fail, delivering more course corrections and customer-determined value while greatly decreasing wasted effort on unfruitful features.

So by continually applying the development team's time on the highest-value features for customers who are currently using the software, the product's value progresses as quickly and efficiently as possible for the development investment. By contrast, with on-premise software, the development investment yields little benefit for customers - feature prioritization is typically targeted at making software demonstrations compelling to the next customer, the several-upgrades-per-decade means that the feedback cycle to the software developer and manager is many years rather than weeks, and a huge percentage of development effort is wasted on maintaining old versions of the software on a myriad of platforms.

The most important part is that the SaaS development process leads to higher value to customers, more quickly and continually increasing over time. The additional value from SaaS after go-live gives customers ever-increasing business benefits, which is why the free ongoing ugprades of SaaS make such a difference in the customer ownership experience vs. on-premise software. Only an ERP practitioner could love the idea of living in the straitjacket of one software version for years and years.

Why We Don't Offshore Product Development (Part 3)

Another posting delay - this time from a medical issue that had me working at about 70% the last month, and unfortunately my non-immediate items had to be dropped like this blog, keeping up on my reading, expense reports, etc. But some minor surgey on Friday has allowed me to drop pain pills for the first time in many weeks, so now back to the series "Why We Don't Offshore Product Development".

In prior posts I outlined why offshoring, in our situation, doesn't actually save any money when looking at total costs, and also our unsuccessful experience with our last offshoring partner. Now, to the meat of the issue, which is why building SaaS software is incompatible with offshoring. First, the external reasons:

High Responsiveness: Our customers expect and require fast turnaround on any software issues, because our customers are very large (almost all in the Global 2000), our software automates a financial business process for them, and we integrate with many of our customers' internal systems. As a result, when an issue occurs, our customers are relying on a quick diagnosis and understanding of the issue, and it simply isn't an option to email the overnight offshore team for an answer tomorrow morning.

We also have a close dialogue with the customers' IT group when we're finalizing and testing system integrations. From experience, we've found that waiting overnight for each cycle greatly lengthened the time to finalize these integrations, potentially delaying customer go-lives (and hence our SaaS revenue!).

Customer-Collaborative Product Development: SaaS providers are much closer to their customers than on-premise software providers, since the SaaS business analysts and software developers know how the customers are using the software, with what configuration and data, and for what business benefits. Having that context is invaluable when working on a customer request, and the only way to get it is to work directly and closely with customers over months and years - it can't be replicated through email or requirements documents.

Value and Speed to Market: All this enables a much higher-value SaaS product that is achieved through the glacially-slow on-premise release schedule. Quick turnaround and intimate understanding of the customer's business process together enable a higher-metabolism, more efficient development process that delivers more value to customers, more quickly. Since SaaS generates revenue as customers actually use the product, both speed and value are of the essence.

Next post - the even more interesting "internal" reasons SaaS is incompatible with offshoring.

Why We Don’t Offshore Product Development (Part 2)

Apologies for the gap between posts, I’ve been pre-occupied with a new release and a system problem we had to sort through.  It’s always fun diagnosing and working around bugs in platform software (in this case Sun’s Java 1.4.2); thank goodness Java can be reverse-compiled.

In any case, this is a follow-up to my previous post, in which I described why offshoring doesn’t save as much money as advertised (“Hire world-class Java developers for only $20 per hour!”).  The real-world savings are much less - if any - as the savings are eroded by additional onshore overhead, lower offshore productivity and high offshore wage inflation.

Even more importantly, we found that offshore development is inherently unfit for building true Software-as-a-Service applications, which is what this blog is about.

But before I get into that, I promised to describe our experience with offshoring product development.

Over a few years, we worked with a couple of offshore providers for several projects, and found some success when 1) we could specify very exactly what was needed, 2) there wasn’t a lot of need from the offshore team to communicate with onshore personnel for clarification, and 3) there was a fair bit of work to do (i.e., person-years of effort).

Based on those successes, we decided to work with an offshore partner for development of a new product module, and the project met the above constraints nicely.  We evaluated a dozen providers and chose a medium-sized provider with great customer references, experience in our technologies, and a focus on agile software product development.

The relationship started well, as the offshore project team managers spent several months in our offices reviewing through our application, architecture, design and coding guidelines, and the new module’s requirements.  When the development effort started offshore, we dedicated three people from our development group to support the 15-person offshore team, including our chief architect.

Even this level of oversight (1 onshore person for every 5 people offshore) wasn’t enough, however, as the development effort suffered from delays and missing functionality.  We took over testing and through months of detailed feedback, we were able to work with the offshore provider to get the module completed.

Then the relationship entered the realm of what I call “shenanigans” - the offshore provider wanted to raise rates by over 30%, and they said there were a bunch of hours that they “forgot” to record and bill months earlier.

So the relationship ended badly, but a worse outcome came later when we delved into the code to add some additional features.  Even with a lengthy up-front ramp-up period and our code review oversight during the project, the delivered code overall was worse than our most junior onshore developer would create.  Since then, we’ve rewritten much of the module to be more consistent with our architecture and frameworks and design patterns.

Now, some of this can be chalked up to a poor offshore provider, and there are certainly examples of successful offshored software development projects.  However, I keep in contact with many offshore providers and SaaS firms, and I don’t think the results for what we needed as a SaaS provider would have been fundamentally different with another provider.

At the same time as this project, we had also hired additional onshore developers with terrific results, and so outcome of the offshore project stood in stark contrast with our highly successful growing onshore team. In examining the offshore project after the fact, it was clear that we can build better software, faster, at far higher internal quality, for the same cost in Denver than we can with an offshore partner.

How is this possible?  Well, the unique needs of Software-as-a-Service applications are simply inconsistent with offshore software development.

This post is getting too long, so in the next posts I’ll detail these bullet points about SaaS software development that make offshoring untenable:

• High responsiveness
• Internal code consistency
• Customer-collaborative product development
• Far lower maintenance effort
• System engineering
• Value and speed to market

Why We Don't Offshore Product Development (Part 1)

For a couple of years, it was de rigueur for Silicon Valley software startups to offshore their product development, often at the insistence of their venture capital investors.

The goal was more developers for less cost, and for that, at least, it worked – small software companies could boast, “We have 80 programmers in Bangalore!”

But then the software industry giants (Microsoft, EDS, IBM, Oracle, SAP, etc.) opened huge development centers in India, with the goal not of saving costs, but to increase the size of their global development groups. So they sucked up the best talent with globally-competitive wages and their prestigious brand names, significantly driving up both wages and turnover among software developer talent. Wages for senior developers in some Indian cities rose 50% in 2004 over 2003, and there are now reports of an Indian tech-labor crunch.

Meanwhile, smaller software developers also discovered that working with offshore development teams involves a lot of overhead for oversight and communication that eats away at the cost savings, and slows things down considerably.

In a SandHill.com editorial earlier this summer, Michael Fields, CEO of KANA, gave a very lucid case explaining why his company “back-shored” software development, from India back to the United States.

In it, he explained that they had been working with an offshore software development partner, and they examined the real economics and software delivered from the partnership. They discovered that for the same total cost, taking development back in-house in the U.S. would improve time to market and allow them to regain control of their intellectual property.

KANA ended up hiring 1 American programmer for every 3 to 4 programmers in India, while achieving the same productivity. The perceived cost advantage of Indian developers was offset because they “had little control over who was working on [their] projects” and they had to employ a program manager for every five offshore engineers, including costs of multi-week travel to India every quarter.

In addition, one cost that Michael Fields didn’t mention but that we have discovered: When working with an offshore development partner, you’re also paying for their sales costs and management overhead.

A couple of years ago, we evaluated growing our development team through an offshore partnership.  I looked at all the costs and found that, at best, we could save about 5% versus hiring here in Denver.

“Five percent, that’s all?” Yep, and here’s why:

• For a 3-5 years-of-experience Java developer in Denver, total cost is $120,000 per year including benefits, work space, tools, etc. (building software in the middle of America is a lot less costly than on the coasts).
• Rates through our partner for an offshore Indian developer with similar tenure was $20/hour ($40,000 per year).
• For a twelve-person offshore development team, we needed an onshore coordinator at $60/hour plus expenses (another $10,000/year per offshore developer).
• From past experience, we knew we needed several dedicated people on our team to provide requirements detail and clarifications for the offshore team, and to perform design and code reviews of their work (this added another $26,000/year per offshore developer).
• Also from experience, we knew that the twelve-hour offset in communications and the many clarification questions would result in rework and lost time by the offshore developers. We had seen up to a 2:1 difference in productivity on other projects, but I assumed only a 1.5:1 productivity ratio due to better communications and oversight.

The net-net was that an onshore developer was $120,000 per year, and the total cost of an offshore developer was $114,000 – a five percent savings. The wage inflation since then in India has more than erased even this small advantage.

Now, there are ways to make offshoring software development more workable – namely by 1) bypassing the partner’s markup and opening a wholly-owned offshore subsidiary, and 2) giving the offshore group complete ownership of a portion of the product that doesn’t require much customer interaction or onshore design interdependencies. Even with this approach, however, attracting and keeping good talent with the current feeding frenzy in India is, for a small software developer, a nigh-impossible task.

Which brings me back to the core topic: What does this have to do with Building SaaS?

Well, beyond the false economies, offshoring SaaS development simply doesn’t work. In my next post, I’ll review how our offshoring experiment ended up, and what we discovered that makes SaaS un-offshorable, in my view.

High-Metabolism Software Development

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.'"