Paul Chen, President, Managed Services

June 19, 2008

SaaS vs Software for Vendors – Lesson #3: The Real Potential Lies in Business Model Innovation

Posted by Paul Chen, President, Managed Services

I ended my last post by discussing how at Fortiva, understanding our cost to serve helped us to improve our product and even introduce a new product offering. This leads me to my third and final lesson on the difference between SaaS and traditional software – business model flexibility.

The business model for traditional software is typically fairly straightforward – you create and develop it, produce it (on some type of media), and sell it to the customer either directly, or through a channel. From there, you typically have very little communication with the customer, with the possible exception of customer service.

SaaS businesses, on the other hand, have far more flexibility to adopt different business models, even taking advantage of more than one business model at the same time. This flexibility provides significantly more opportunities than traditional software to continually innovate and find new ways to leverage a product in different ways to improve revenues.

Let me give you an example. Google’s founders started out with a business model based on licensing their search technology to key portal vendors, such as Yahoo. Little did they know that just a few years later, they would introduce a keyword advertising program that would ultimately form the basis of Google AdWords, which today makes up the majority of their revenue. If they had stopped with the licensing business model, Google as we know it would not exist today.

Here’s another example – this time, a hypothetical one. At Fortiva, we charge a per-user licensing fee as well as a fee for blocks of storage to access our email archiving solution – essentially a pay-for-use model. But what if we decided to offer email archiving for free? It may sound crazy, but it could be a valid business model. Consider this – a large portion of businesses archive their email to meet requirements in the case of future litigation, and those businesses often have little need to access archived data before that time. Hypothetically, we could simply charge those customers to search and access their archives when litigation arises. This would give us the chance to target companies that don’t feel they can justify the cost of a pro-active approach to legal risk (by implementing an archive), while still benefiting in the long run from the inevitable.

I’m not suggesting that this is something we’re going to do, but it gives you an idea of the type of innovative thinking that can open up new business opportunities in the SaaS world.

At the end of the day, business model innovation can be a key competitive advantage for any company. SaaS opens the door to far greater flexibility in this area, and businesses embarking on this delivery model should not lose sight of that.

Read more on the SaaS vs Software: Lessons Learned series
Part 1 - Part 2 - Part 3 - Part 4

June 05, 2008

SaaS vs Software for Vendors – Lesson #2: Never Lose Sight of Your Cost-to-Serve Model

Posted by Paul Chen, President, Managed Services

I’ve already talked about how different SaaS is from a traditional software venture, and I shared with you one of the lessons I’ve learned firsthand about running a successful SaaS organization (Fortiva) . Today I’m going to talk about another point that, from my experience, is a critical component to any successful SaaS venture.

I recently came across a very interesting guest post on Will Price’s blog, entitled Magic Number for SaaS Companies. The post is about a talk given by Josh James, CEO of Omniture, at this year’s Opsource Summit, which focused on something called the “Magic Number”. The basic theory is that SaaS companies can determine the health of their organization by measuring the increase in monthly recurring revenue and dividing it by the previous period’s spending on sales and marketing.

The theory is sound, and it’s a must read for all SaaS vendors; however, by focusing purely on sales and marketing, it misses a key metric for many SaaS vendors. In fact, just because you have a strong magic number, does not mean you necessarily have a healthy SaaS business.

Since any SaaS business, by definition, provides customers with access to a managed infrastructure, vendors will always have ongoing costs for backend hardware. This is quite different from the traditional software business where the cost of goods are largely upfront (and mostly involve the printing cost of the CD and user manuals). For some SaaS businesses, the infrastructure investment required will be quite high, and will be subject to change. This is the case at Fortiva, where we are constantly adding new storage infrastructure to support the archive growth of our current customers, as well as the needs of new customers.

This is one of the reasons why, over the past year, I have focused heavily on developing our cost to serve model. This model has helped us to understand and quantify exactly where our biggest costs are – and sometimes the results have surprised us.

By understanding and tightly managing our cost to serve, we have been better equipped to take advantage of both economies of scale and technological improvements (ie. cheaper storage). We’ve also been able to make small product fixes that have resulted in a significant impact on product performance as well as the bottom line…we’ve even been able to develop new product offerings that we otherwise might have overlooked.

The key point here is that unlike in a software business, where your cost to serve is a known entity (eg. initial development costs, media, packaging, etc), in a SaaS environment, that cost is subject to constant change due to new product features or technology changes. As a result, it’s critical that you place a significant focus on understanding the costs involved, how they change as the product evolves or adoption increases, and how you can optimize those costs to improve revenue margins.

Read more on the SaaS vs Software: Lessons Learned series
Part 1 - Part 2 - Part 3 - Part 4

May 22, 2008

Welcome to SaaS, Nick

Posted by Paul Chen, President of Managed Services

Last week, it was announced that Nick Mehta, former general manager of Symantec's archiving product, Enterprise Vault, was appointed CEO of LiveOffice, a SaaS provider of messaging solutions, including email archiving. 

I must say that I am excited about the announcement.  I have spoken to Nick in the past and have found him to be quite knowledgeable in the email archiving space.  I admire him, not just as a competitor, but as a pioneer of our industry.  Under his leadership at Symantec, Enterprise Vault “crossed the chasm” and became the market leader in the on-premise email archiving space.

I’m sure Nick had many other career options after spending some time as an entrepreneur-in-residence at venture capital firm Trinity Ventures, but he chose to continue his career within the message archiving industry.  This tells me he believes what basically every industry analyst has been saying, that the industry we’re in will be growing by leaps and bounds for the years to come. 

What is even more exciting is Nick’s move from an on-premise solution to an on-demand email archive.  I see this as validation of what we have been seeing here at Fortiva, that growth in SaaS email archiving will far outpace the growth in on-premise email archiving over the new few years.  As Nick said himself in his new blog, he felt that “messaging and message archiving are universal needs and yet not every organization was equipped to run these systems themselves.”

As we have pointed out in previous posts, the nature of the problem that email archiving solves makes SaaS a great option for many companies – and any vendor that can provide a reliable and cost effective solution that takes the headache away from customers will definitely be leaders in the industry.

So, welcome back to email archiving, Nick.  You made the right decision betting on SaaS as the long term winner.

May 01, 2008

SaaS vs Software for Vendors – Lesson #1: Product Management Is Not Just About Features & Benefits

Posted by Paul Chen, President, Managed Services

In my last post, I talked about a number of traditional software vendors are now entering (or considering entering) the growing SaaS market. I also noted that while the two models (SaaS and traditional software) appear similar on the surface, there are significant differences between the two business models that require you to approach them in very different ways. Today, I’m going to share one of the three key lessons I’ve learned about building a SaaS business, and explain why in my opinion, it’s critical to success.

Before founding Fortiva, I started a company called FloNetwork, a very early example of a SaaS company that offered an email marketing automation service (FloNetwork was ultimately purchased by DoubleClick). Back then, one of our bigger customers came to us with a specific product feature request. It was a fairly basic addition for us, and something that we could easily pull together to make the client happy – so we did. Soon, a lot of other customers wanted the same functionality, so one by one, we added it for them.

Before long, we found ourselves with an operational nightmare on our hands. Since we made the change on a case-by-case basis, any overall product upgrades or backend changes required us to individually check and make fixes to those customers that had the feature in place – and each fix was slightly different.

Looking back, we could have avoided this problem by following a few simple rules:

  1. Never offer “one-off” custom features
  2. All feature changes should be developed with scalability and large-scale adoption in mind
  3. Consider long-term support of any product changes
  4. The product scope doesn’t end “at shipment” – it encompasses the life of the solution, including all operational and support requirements
  5. Keep it simple

Unlike with traditional software, adding a feature is not simply a matter of identifying a customer need, building it, testing it, and deploying it. Instead, it requires a long-term approach that takes into consideration future support requirements, operational needs, scalability, and the potential impact on future product upgrades.

Ultimately, within a SaaS environment, the scope of all product management decisions should include the impact on the vendor – not just the impact on the customer.

Read more on the SaaS vs Software: Lessons Learned series
Part 1 - Part 2 - Part 3 - Part 4

March 21, 2008

SaaS vs Software – Two Fundamentally Different Business Approaches

Posted by Paul Chen, President, Managed Services

It’s clear that Software-as-a-Service is continuing to grow, and as a business model, it has the potential to be very profitable. According to Gartner’s estimates, by 2011, 25% of new business software will be delivered as SaaS. Compare this to their assessment of traditional software licenses, which Gartner says have been stagnant for the past 36 months, and you’re left with a very healthy outlook for the SaaS market.

This recent growth has led a number of companies (and individuals) to consider developing a SaaS-based solution. As part of the decision process, there is often a significant focus on how long it will take, and how much capital is required to build and market a successful, profitable SaaS solution (particularly in comparison to traditional, licensed software solutions). This comparison will almost always lead to a conclusion that SaaS is more expensive, and takes longer than traditional software to reach a point of profit.

While these are important metrics to consider, the way I see it, the real question is not, “how much will it cost”, but instead, how do you “do it right” to help ensure success (and the profits that come with it)?

I am not claiming to have all the answers, nor do I think there's only one right way to build a successful SaaS business . I do, however, know that there are a lot of important issues that are overlooked by many people entering the space, especially when they’re coming from more traditional software markets. While the two models (SaaS and traditional software) appear very similar on the surface, I would argue there are a lot more differences between them than similarities. When you consider that, approaching the two business models in the same way does not make any sense.

Fundamentally, the switch to a SaaS model requires you to first understand that SaaS is not simply another delivery mechanism – it’s a paradigm shift that affects virtually every department in the organization. To be truly successful, a SaaS-based offering needs to be built from the ground up as a service, rather than a product. Every business decision should be made with this in mind – from product feature decisions to sales and marketing efforts.

In my next posts, I will share with you the three biggest lessons I’ve learned building a SaaS business, and explain why these three things are, in my opinion, critical to the success of any SaaS initiative.

Read more on the SaaS vs Software: Lessons Learned series
Part 1 - Part 2 - Part 3 - Part 4

March 19, 2008

Building a Successful SaaS Business – Lessons Learned

Posted by Paul Chen, President, Managed Services

As a founder of Fortiva as well as an earlier generation SaaS/ASP venture (FloNetwork, which was sold to DoubleClick), I have a number of years’ worth of experience in the Software-as-a-Service space. Looking back on the mistakes and successes of both companies, I realized there are some important lessons that I (and the team that I’ve worked with) have learned over the years. With the growing interest in SaaS, it seemed like a good time to share some of those insights.

Over the coming weeks, I will discuss some of the key issues we faced in starting a SaaS venture, from understanding the differences between building SaaS compared with traditional, licensed software-based solutions, to the importance of an engineering product roadmap and achieving economies of scale. I will also share with you some of the best practices we learned through trial-and-error, as well as some things we would have done differently. I welcome your thoughts and feedback.



About

About
Contact

 Subscribe in a reader

Subcribe by Email:

Archives

Search


Powered by TypePad