« August 2006 | Main | October 2006 »

September 09, 2006

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.

September 01, 2006

The SaaS Customer Ownership Experience

I was reading an AMR Research note this morning about Oracle's Fusion progress, and one of the first points was that Oracle is doing double development: building out functionality for existing customers while in parallel building the "brand new Fusion platform".

So I got to wondering, how much effort is Oracle applying to each of these two efforts?

Software companies, like any company, will invest in product development based on the expected revenue return - no new revenue means no new investment.  This leads to a truism of on-premise software companies:  They are always working for the next customer.

This is because licensed on-premise software companies grow their revenue and profitability through new customers.  The next potential customer is making a product evaluation based on the software functionality, and will give a big check to the winner.

But what about maintenance revenue?  Well, customers of licensed on-premise software are locked in - they fork over the 20% maintenance every year because they have no choice.  It doesn't matter if the software has a new release or not, if new functionality is there or not, or even how bad the support is, 99% of the customers pay the 20% each year.   Since there's little risk of losing revenue, existing customers' needs are lower priority.

So the on-premise software company's resources - both product investment and sales efforts - are dedicated to getting the next customer. As soon as the contract is signed with the new customer, the nice salespeople and those amazing technical people that made the software sing and dance will start to dissolve away like they're in a Star Trek transporter - they're being transported to the next potential customer. And the customer is stuck with a license-fee bill for a CD of software that hasn't been installed or implemented yet, much less deliver business value.

SaaS providers, on the other hand, have to earn their customers on a continuous basis, since customer usage and adoption determines the SaaS provider's revenue.  SaaS vendors actually help customers increase usage and adoption.  Since the customer can leave at any time, the SaaS vendor must continuously work to keep them happy with the software's functionality, value, availability, performance, support, and overall business value.

This continuous accountability to customers leads SaaS providers to invest in functionality that makes customers satisfied.  This investment has an immediate positive revenue return - if the provider doesn't invest in current customers, they will quickly lose revenue.

Even more importantly, most SaaS providers grow within their customer base - in our case, about half of our revenue growth is from increased usage and adoption within our enterprise customers.  So we have to prove out our value with every new group of users, so they recommend it to the next set of users. 

This forces investment where the increasing revenue comes from - both existing customers and new customers for SaaS providers.  So, as a customer buying software, which would you prefer - a software vendor who forgets you as soon as you sign their contract, or one who continuously works to keep your business and increase the value they deliver to you?