When I wrote the recent article “SaaS: 10 Trends for 2010” I used the phrase “Best Case SaaS.” I realized from feedback and some thinking afterward though that many people don’t share my vision of what it is.

What I was trying to say is there really is a path to success for SaaS products through the thicket of options out there.  But since we don’t all share an understanding of all the options – that becomes pretty nebulous.  We’ve written about the 10 Ways to Fail at SaaS – What about Success?

Whether you call it “best practices,” “optimum implementation,” or best case – to have a discussion of what it takes to field a successful product we need to have a common understanding of SaaS itself. One of the people who has been pretty clear about a vision has been Phil Wainewright – but there are several others who are advocating for various aspects. My concern is a lot of them tend to be involved in the technical side of SaaS and not a straight- forward business discussion.  Of course, it takes an understanding of technology to bring a SaaS product to market, but in truth, you can hire that expertise if you have a clear business strategy to back it up.

Before I list the six points I have outlined – let’s get our definition clear.  Software-as-a-Service (SaaS) is not as simple as, “A application delivered over the Internet on a subscription basis.” That definition is what most people think, but in truth it is far to limiting by itself. If you want to keep it simple, you could just say, “an online service” but that might be a little broad. To cover both sides of the fence, vendor and user, I’ve been using, “an application delivered across a network to a client in a pay for service model.” On reflection – even that definition has its faults.

The point of this little exercise in definitions is that we need to realize that what we once called “Business-to-Business (B2B or B-to-B)” or even the slightly more exotic sounding “B2B2C” would be called SaaS today.  Does that mean Priceline is a SaaS product? Well – Yes! The simple end-user travel services they offer are monetized on a transaction basis, but we should also understand that behind that stands an even more important service disposing of excess inventory for the hospitality and travel industry. Somewhere in the middle is an advertising platform that allows the “inventory customers” sell through Priceline directly. Does Priceline care which service you use? Not really, they make money from all sides of the transaction and with any service you select. It truly is a Long Tail offering in every way.  The same could be said of the Amazon platform only more so.

So – really we could just say SaaS is “an online service” or “service automation delivered in a pay for service model” and be accurate? When we do that we begin to realize there is a whole field of service companies that use applications to automate and deliver aspects of their services – but aren’t usually considered as “SaaS companies.”

With that in mind, let’s go forward and look at “Best Case, Successful SaaS.” The points build on each other – so follow along through them and it will make more sense.

6 Points for Successful SaaS

1. Expertise that can be sold to a reasonably large market segment in an online delivery model and can be scaled to meet the market potential over time.

This is of course the “reason for being” for SaaS.  Online services are sold on a “pay as you go model.” No matter how you look at it, if you don’t have a target market large enough to give you a positive return on investment in a reasonable period of time, you aren’t going to be successful in a SaaS business model. In a vertical, this means offering a service that is attractive to at least second and third tier markets. It could also mean “tagging along” with more general offerings that give your service more weight in an “ecosystem” model. Regardless, you cannot ignore the simple economics of online services. You cannot afford to run out of cash before you reach a positive cash flow. That means development has to be planned and controlled to yield just enough of a service to sell successfully as soon as possible. It means that you must have a understanding of SaaS Metrics and the critical Customer Lifetime Value Ratio (CLV). It means you need to have a “proof of market” investigation as a part of product planning and (for heaven’s sake!) development. It means you have to understand (and monetize) the value your end-users perceive. It means your online service must be planned to evolve after release (see point #2).

Now the second part of our first point is what brings up the application model of SaaS. To scale a service economically, it has to be automated. When you get right down to it – SaaS is service automation! We’ve been doing that for years – the most significant difference is that now the Internet offers a delivery vehicle that is pervasive and universally accepted. So – if you’re really going to deliver a service online, plan to automate your own business operations from day one or you won’t scale with enough efficiency to reach positive cash flow in time. You might be able to onboard your first 100 customers manually – but if your market plan says you need to take on 1,000 customers with 20 seats each in your first year – your operational costs will quickly eat your cash reserves – IF you are able to handle the work that involves. (See point #5).

2. A strategic roadmap that allows the product to be brought to market early in the design cycle and to adapt to user and market feedback.

Taking the first point to heart means really understanding you can’t do everything and you shouldn’t if you want to be successful. You need to have a plan, a roadmap. You need to provide a valuable service from day one the market will pay for, but you also need to have a strategic plan for where your service is going over time.  Within that plan, you need to be flexible (see point #3) and responsive to user feedback (see point #4) and market forces.

Bringing the product to market early also means not taking on development of features that don’t support the direct value to end-users. As mentioned in point #1 – you need to automate your service – but do you really need to build all your operational automation (see point #5) to bring a product to market? No. There are many operational services you can leverage to lower your development complexity (risk), time to market and total development cost.  The general rule of thumb is you will save as much as 60% of your development effort and about 40% of your total costs before launch. The services you use become part of your overhead and need to be part of your metrics. Can you develop them into your service at a later date when the cost is justified by growth? If you take point #3 into account – yes.

3. An extensible, service-oriented technical architecture that will support the expected growth and change over the long term, economically.

Before anyone calls me on it – the last word in this point covers a lot of sins that have been visited on the SaaS business model. Let’s be straight-forward. We’re interested in SaaS because we want to MAKE MONEY. If we want to do that we have to be able to operate, deliver and maintain our application economically and reliably over the long run. That means we need a multi-tenant database structure. I don’t know any other way to say it. You cannot scale on individual instances for each customer or maintain them over time and make money.

It doesn’t mean however we have one big spinning top that runs everything forever.  As your service grows, you will use several strategies to extend your application over multiple instances, and to balance your service among several applications perhaps. Do you have the idea that Amazon is one big application? Of course not. Your service might present one “interface” for users – but that doesn’t mean it is just one application. Architecturally, that is just the “presentation layer.” We have to have an understanding of the technical strategies that allow online services to scale, embed other services, extend our services outside the application, and change our service without extensive rewrites over time while continuing to make a profit.

With that understanding, we can plan our roadmap to help us decide the battles we need to take on and when. Do we need to buy infrastructure if we can rent it? Not if the market price, availability and reliability meets our needs. Do we need to build a pricing and settlement system to monetize our service? Not if there is one available at a price that can be incrementally applied as we scale and with the level of maturity we need.  Can we eliminate some maintenance concerns with virtualization? Yes – when it makes business sense – if we have a properly architected application that is built for the online environment.

What about “lock in?” they ask. There are two things to consider: #1 – Can you afford to spend thousands of extra dollars over some extended period of time before you put your service in the water, take on customers and begin making money?  For most of us the answer is no.  #2 – If your application is properly architected and you have developed a roadmap with proper risk avoidance, the services and platforms you use are tools you use to reach your maket sooner and with less up-front investment. Do you want to buy that store on the mall or rent it? If you rent – can buy or build when you have a proven market? In most cases – yes.

All this implies you or your team has technical background in online services. But if you are a entrepreneur or service company without a strong technical team – can you still survive in the SaaS world? Yes. There are companies with services that will fill that void – (shameless plug for the people who bring you this blog) Hello….

4. Customer and user collaboration tools embedded in the service and the business operations that surround it.

If you absorbed the last three points – you should have gotten one thing clearly: Release 1.0 day is not the end of the development cycle for online services. Because of Google, SalesForce, Amazon, and service portals like FedEx operates, we all expect, even require, online services to evolve. It should be no surprise that online services need to evolve dynamically to meet customer needs and stay ahead of the market. The question is how?

Just like nearly everything else in online services, the answer comes with some level of automation. Inside the application, monitoring must be embedded to help evaluate feature use in a user context. We need to know if user admins are able to use the tools they have effectively. We need to know what percent of their day our line of business users spend in the application and how often they use it to complete “high value tasks.” With that information as a baseline, we can evaluate the impact of new features, improved help, better support strategies. Without it – we’re clueless and we might as well be selling licensed software to silos behind firewalls.

To leverage our delivery platform even more we need to embed direct user engagement with blogs, forums and community tools like UserVoice and Get Satisfaction.  These are services you subscribe to (point #3) not build. These are not the endpoint for user engagement however, they are just the tools. As tools, they are used by product management, support, sales and marketing to help guide service development, to retain customers, up sell and grow best practice communities.  What you should be beginning to realize is this really means a successful online service needs to rethink the timeworn model of “key stakeholder engagement” and get directly to the end user. To do that the business organization behind the service needs to be aligned to leverage the tools and integrate what they yield into decisions. (Enter points #5 & 6).

5. Integrated business operations for the service itself embedded in the same delivery model used to deliver to end-users.

Once again – SaaS products are classic service automation. If you are going to sell a service – if you are going to build an application to deliver your services – shouldn’t you also automate the pricing, settlement, onboarding, user management and all the other operational aspects of your business directly in the application itself?

This is a point that seems to have eluded many service companies and ISVs with licensed products. You cannot scale to reach profit in online services with manual or loosely connected internal business processes. SaaS is all about making a profit from volume.  But, as point #2 cautions, you cannot build all the operational aspects of your service directly into the application without placing considerable risk on your costs, application complexity and time to market. If you have planned your product with the architecture discussed in point #3, you can leverage available services that will provide these critical aspects of business operations for you and embed them in the product platform itself. This gives you the best of both worlds – fully integrated business operations using the data and infrastructure you already have online and a cost that is applied incrementally based on use.

6. Agile business philosophy embodied in every aspect of product development, operations and services.

You nearly have it – successful SaaS is all about service automation and dynamic business. It delivers what we need, when we need it, at a cost that is measured by use on every side of the platform. That means you and your customer alike are benefiting from the investment in the application and involved in its continued success intimately.

To handle the continued development and change involved in SaaS, most technical teams use Agile methodologies. To feed development and manage the product roadmap then, we also need to consider an organizational alignment with agile philosophy. When we really consider the organizational impact of being an online service, we start to understand there is really no option. To be successful at SaaS, we need to be an agile business top to botttom.

This is a lot to absorb. It is a different way of doing business. I don’t want to underplay the significance of any one of these six points. We at Scio made a strategic decision last month – we’re alining our services to deliver best case SaaS to our product customers and nothing else.  To help people put this into their own context, we’re giving a workshop on January 28th in Dallas as part of SaaS University. I strongly encourage you to join us if you have any interest in developing an online service in the coming year.

So – what is your take? Did this list suprise you? I hope not – but I’d love to hear your point of view.

I’ve noticed there are broadly two camps when it comes to developing new services for the Internet: Those entrepreneurs that feel they must do everything themselves regardless of the hurdles they face and those that want to focus on their core expertise and leverage outside services where possible.

Of course, there are also those that sit on the fence and never make a clear decision either way, but since for the most part the fence-sitters haven’t and won’t develop a service anytime soon – they fall outside the scope of this discussion. And frankly – they are hard to address until they make a choice that works for them.

The DIY (Do-It-Yourself) mindset comes from a long tradition in software development. The idea of the lone visionary, working in a makeshift office in the garage late at night against all odds, is an iconic image for Silicon Valley entrepreneurs. The folks who took that route are the stuff of legends in the business – and rightfully so.

But today’s business is a lot different from the days when people like Bill Hewlett, Dave Packard, Steve Jobs and Bill Gates started. There are options, services and alternatives that can be strategically leveraged on the road to product release that didn’t exist just a few years ago. We’ve gone through many cycles of change and innovation that have both raised user expectations and created a number of issues that entrepreneurs are expected to understand and deal with at an early stage.

Since I focus on helping “as a Service” and cloud-based businesses – I also have to point out another interesting aspect of this strategic choice for entrepreneurs. If you are expecting to sell a service delivered on the Internet – are you taking your own medicine? Are you considering services you can leverage to help you deliver your service more efficiently, faster and with more options than you might otherwise be able to offer with a reasonable compromise between cost and effort? If you’re not – are you in a good position to advocate someone else should make a different decision when they look at your new service? It’s an interesting thought…

To add one more log to the fire – the first rule of Bessemer Venture Partners Top 10 Laws of Cloud Computing and SaaS is:

BESSEMER CLOUD COMPUTING LAW #1: Less is more!

Leverage the cloud everywhere you practically can, both for your internal systems as well as for your own product offering(s) and “just say no” to on-premises deployments! This will not only give you a direct understanding of the customer experience and best-of-breed strategies of Cloud Businesses, but it will free up your technical resources and balance sheet to focus on your core product and customers.

There is another side of the discussion too – There is a large segment of the SaaS market that is made up of service-based businesses that use custom applications to manage and extend their services to their clients. These companies often don’t see the applications they use as more than an aspect of their service. They do not see themselves as software developers but they do develop, integrate and leverage application-based services for their service offerings. In today’s environment, many of these companies are extending their services to the Internet in one way or another.

What are some of the options available as services to developers of “as a Service” products today?

• Infrastructure Virtualization – Whether you call them “cloud services” or Infrastructure as a Service (IaaS) or virtualization, there is a broad set of services available to eliminate the need to own, provision, maintain and scale the servers, CPU, memory, storage, networks, databases and operating systems required to offer a service on the internet. In the best case, these services are use-based and can scale up and down with demand. They can eliminate or lower the costs of buying and deploying infrastructure and the resources necessary to operate and maintain it. On the resource side, this may be a expensive skill set not present in the existing vendor team that could be less burdensome if many of the tasks are automated. That said, IaaS is an often abused term in my opinion. Just as everything on the Internet is being identified as a “cloud service” – infrastructure services come in many shapes and flavors and some deliver more promises than value. Knowing what is possible, what you are actually getting and what you need is key when you begin to engage with cloud providers.
• Operational Services – This is another broad class that covers what we often call the “plumbing” of an on-demand service. It includes areas like billing and settlement, pricing, client administration, reporting, integration, user community management, sales automation, product management, and content management. If developed from scratch, the combined effort to put these services into a product can easily reach 60% of the cost of a project. In fact, because of the cost and expertise required, these services often end up being very constrained or left to manual processes which greatly impede growth and reliability of the product.
• Platform Services – If IaaS is an often abused term, Platform as a Service (PaaS) is rarely ever described in terms that actually speak to their business value for as a Service companies. 90% of what is offered today as PaaS is either a development environment or a BPM (business process management or workflow) system. I don’t want to disparage the value of those two approaches to a software development effort – but - they need to be separated from the PaaS offerings that also address the operational needs of a service-based business as described above. A PaaS that addresses operational needs does several things for a new service – it lowers the effort and cost required for development and it lowers the time to market and risk associated with larger, more complex development efforts. In addition, most PaaS offerings include levels of infrastructure virtualization that lower the need to deploy and manage the servers and their associated hardware, software and networks.
• Resources – While outsourced development is a very obvious option for building the application (Scio is after all, a software development provider) , there are many types of resources available for specific tasks such as planning, marketing, sales, and support. It is critical that the selected service provider understands the issues that “as a service” businesses face, but when they do they can greatly reduce risk, false starts and strategic errors. In considering outsourced resources it is important to remember there will always be a “cheaper” resource somewhere. The provider you select needs to deliver value for cost and in SaaS and cloud-based businesses that comes from knowledge and practical field experience.

So, let’s say you’re one of the entrepreneurs that are either considering or actively leveraging services as a part of your product strategy. What do you need to understand to be successful at picking or using services?

1. Pick for Value, Not Cost – Value can be measured many ways but the key in services is not the cost, it is value delivered. In most cases this should be realized in lowered or offset development effort, risk, complexity, time to market, or increased expertise (or all of the above). Depending on the type of service, the offset could be in the form of on-going overhead – as it would be if you use a billing service for instance. In the best case, all overhead for service-based businesses should be tied to use. This means the overhead cost per period can be divided by the number clients or users so it can be understood and budgeted as an operational cost. In this scenario, the cost should also fall if the basis (users or amount of bandwidth or whatever the metric is) also goes down. A service cost that only rises in stair steps can quickly become a serious liability if there is a lot of subscription churn or usage variability in your product.
2. Build for Flexibility - Just as the features you offer in your product today will invariably need to change over time, so too will your service strategy. When you have reached a point in your growth curve that it makes sense to recapture the overhead devoted to a service, you may decide to build that function into your application directly. If you have built on a flexible architecture, this should be a choice that is available to you whenever you decide the time is right. This same line of thought addresses changes in service providers. Just as you might decide to change your bank to capture a better interest rate or more services, you should also be able to change your service provider if competition puts a better choice in front of you or your existing provider goes under. This is a risk in every aspect of business and part of the trade-offs you have to consider. Not planning for risks is wrong but expecting you have eliminated all risks by taking on the responsibility yourself is equally shortsighted. Properly balanced service usage and risk planning is a serious competitive advantage in the long run.
3. Pick Your Battles - Understanding service value means really knowing what your business needs. You will not have every use case for pricing in place the day you roll out your service. Building a pricing engine at that point means you may have to completely redesign your system while doing manual workarounds when it is realized you need a different pricing strategy. In this case, a feature-rich service could provide a window into many approaches you hadn’t considered. On the other hand, if your service requires a great deal of analytics, a library of analytic routines may be of value to lower development overhead, but if you do not completely understand how the library works and the results are obtained, it could be providing unreliable results. Just as in selecting features, you need to understand what your service needs to be effective and pick your battles carefully. Don’t build what you don’t have to but don’t accept black boxes that you don’t understand. Do proof of concept runs and don’t accept marketing at face value. What works for another provider may be entirely different in your context.
4. Focus on Delivering Your Expertise and Satisfying Your Customers – Really this is just part of picking your battles, but it is a core strategy just the same. The point of an effective services strategy is that it must free your team to focus on the value you provide to your customers . If managing a service is more work than doing it yourself, there is something wrong. Effective services clear out operational hurdles, provide market-led options, and grow with you. This also means understanding your core expertise and not extending yourself into areas where you don’t need to go to be successful. Service-based business is quite different than providing licensed software. Leverage service providers who have the field expertise you need while you continue to define and deliver the value your customers are paying for. Would you want your airline pilot to also be the maintenance team that keeps a modern passenger jet operational? It might sound good on the surface, but in reality, there is enough in each field that it just isn’t practical or safe. Focus on what you need to do to keep your customers and let qualified resources keep the engines running.

I would be remiss if I didn’t also say that we help our clients pick services everyday. There is no one size fits all and every choice has a trade-off. We spend a fair amount of time dissecting services and trying to understand the technical and business cases for their use. I can’t recommend a set of services that will work in every situation – but I hope these “pointers” will give you an idea of what is involved in the choices you have.

What have you found? What situations have you faced? Join the conversation and let me know.

Addendum -

I’m going to the Cloud Futures conference in San Jose, December 7-8, 2009. If you’re going to be there let me know on Twitter or by leaving me a comment here. I’d love to get a chance to meet with some of the community there and heaven knows, none of us have gotten out to many conferences in the last couple of years.

In our first two podcasts for Haut Tech Conversations we covered service and pricing. Both subjects are critical for SaaS businesses to consider and understand in the context of their product. In the podcast we did yesterday, we went into yet another critical area – Marketing!

To put us in the right frame of mind for this conversation, we brought the respected expert on SaaS Marketing, Peter Cohen of SaaS Marketing Strategy Partners together with our panel – Ron Arden, Vice President of Strategy and Marketing for eDocument Sciences and Justin Pirie, a SaaS and Cloud product manager and marketer who has been working in subscription software for over four years.

We covered a lot of ground in this podcast – it is a wide-ranging conversation that got into many of the unique aspects of marketing in an on-demand world. We also went into many of the areas that are closely linked to marketing – Product Management, Agile Development, Community Development, Ecosystem Management and Customer Relationship Management.

What questions does it answer? In consideration of the title of this podcast and the “Wheel of Death” as Peter calls it – we talked about the issues traditional vendors face when development teams work on SaaS products – especially with Agile methodologies. The Agile approach is a good match for SaaS products, but to take full advantage of it – the entire organization must be in alignment. If marketing is out of the loop, the steady flow of product enhancements and new features can make the marketing team feel like they are like a hamster in an exercise wheel – running forever and not getting anywhere. Getting above the traditional feature-based technology marketing syndrome is critical in SaaS.

From there we incorporated all the various points of view of our panel and as we always do – let the conversation flow into the many areas that overlap in a SaaS product organization.

If you have any interest at all in how to deal with the dynamics of marketing a SaaS product and an hour to spare – I suggest you download this podcast, listen and share it with your team. I am very pleased with the insight our guests brought to the discussion and we would all love to hear your thoughts in comments here or on your blog. Join the conversation!

Our special guest for this podcast was –

Peter Cohen: Peter is the founder and managing partner of
SaaS Marketing Strategy Advisors. His firm provides expert guidance to help companies effectively market and sell software-as-a-service (SaaS) solutions to enterprises. The firm’s clients includes several large, well-established clients, looking to enhance their SaaS marketing practices, as well as smaller companies that need guidance in launching a new SaaS solution to the market.

Peter has more than 25 years’ experience developing and implementing successful marketing strategies for technology companies, including Computervision, Lotus Development, IBM, and Authoria. Peter has spoken on the topic of SaaS Marketing for the Massachusetts Technology Leadership Council, and written for widely-distributed publications including MarketingProfs. He publishes a monthly newsletter and a blog, both entitled “Practical Advice on SaaS Marketing.”

Our panel included:

Justin Pirie: Justin is a SaaS and Cloud product manager and marketer who has been working in subscription software for over four years. He specializes in working closely with companies to create successful SaaS products using the latest techniques and industry best practice. He is based in the UK and has advised companies in Europe and the US. He has been on our show before and is now one of our Haut Tech Conversations “Irregulars.” You can follow him on Twitter here.

Ron Arden: Ron is the Vice President of Strategy & Marketing for eDocument Sciences. He on focuses on SaaS computing and using social media tools to drive business for eDocument Sciences, and recently became an Inbound Marketing Certified Professional. He has over 25 years of strategic planning, marketing, sales, business development, consulting and technical experience in the information technology industry. Prior to eDocument Sciences, Ron was Director of National Solutions Support for IKON Office Solutions developing and driving strategy, policy, tools and the product & services portfolio for IKON’s Professional Services group. This included developing and managing vendor relations for all Professional Services partners. Prior to IKON, Ron held executive, management and technical positions at numerous Fortune 500 organizations, including DEC and Wang. You will find Ron on Twitter as @RonArden, on LinkedIn, and his profile on Google.

You can download the mp3 here or listen directly or on iTunes from the widget below:

SaaS is not a “one-size-fits-all” business. There are many options now for platforms and services you can use and the number is increasing every day. A lot of the information available is laden with marketing hype. How do you make the right decisions?

We’ve been helping companies transition to SaaS as startups and from traditional licensed software for several years and we’ve build up a practice we use repeatedly to navigate the choices. We’re bringing our practice to the Dallas SaaS University event as a workshop to help SaaS executives and entrepreneurs make the right choices for their business. We’re passionate about helping companies succeed in SaaS and we’d like to pass some of our knowledge on to you.

You can take this workshop combined with your signup to the University event or separately, but I encourage you to take advantage of the combined pricing that is available. This is not a “technical” workshop – we will be covering how the technical and business decisions SaaS requires impact your business and product strategy. We’ll be using interactive exercises to help you put the concepts into your context and build something you can take back to your team. It is a full day with a catered lunch and will be a limited group so you will have plenty of opportunity to ask questions and be involved.

UpDate! – Use Discount Code: SCIO100

Here’s the outline:

Charting Your Course to SaaS

Making the Right Decisions for Your SaaS Product

Overview – How is a SaaS Product and Business “Different”?

• Leaving 30 years of industry history behind
• Transitioning to a service-led model
• 10 ways to fail

Your Service is Different

• What does making the right choices mean?
• Understanding your market, product strategy, roadmap, supporting technologies, and skills needed.
• Knowing flexibility is key in SaaS

Sell the Right Product

• Map your core product and customer assumptions
• Consider test marketing plans
• Developing a go-to-market feature set

Make Strategic Development Choices

• Selecting services and platforms
• Selecting a technical architecture
• Making development and deployment choices

Operating a SaaS Business

• Understanding service-led business requirements
• Leveraging operational metrics
• Understanding end-user interaction in SaaS and product management

Who Should Attend?

This workshop and seminar is important for anyone considering a SaaS product, in the process of developing a product or offering a product that hasn’t reached its potential, including: Entrepreneurs, CXO’s, product managers and key executives in startups, vendors moving to SaaS or existing SaaS companies.

About Your “Professors”
Luis Aburto, CEO of Scio Consulting, is a veteran of international technology and engineering consulting for corporate and government clients in the U.S. and Latin America. Mr. Aburto is the founder of Scio Consulting, and in 2006 was responsible for focusing the direction of the company on SaaS enablement services. Luis has worked with a multitude of software companies of all sizes and across many industries, helping them make the transition to SaaS.

Mike Dunham, Principal Consultant of Scio Consulting, has over 25 years background in the development and introduction of new technology working with startups, government and the largest enterprise software companies. He has worked with Scio for five years, regularly authors articles on SaaS and the software industry and hosts a series of podcasts on SaaS best practices. Mike leads Scio’s professional services helping companies develop and bring to market new SaaS offerings.

As I mentioned – there are several ways you can join us in this workshop and I very happy we have the opportunity to bring it to SaaS University. I’m looking forward to meeting many of my friends at SaaS University for the event. If you would like to know more about what we’re going to be doing or some help building the case so you can get company support to go, just let me know. See you there!

As anyone who follows me knows – I use Twitter and TweetDeck to watch the “virtual conversations” about SaaS happening around the ‘net when I can. Today some time was freed-up by a conference call that was delayed so I fired up TweetDeck and took a look around. Imagine my surprise when I read a meme had started around a blog post touting single-tenancy for enterprise SaaS applications.

I’m not going to link to the original post – the writer has his reasons for pushing the idea – they are not entirely wrong, his context is different than mine and most readers of this blog. But I strongly felt the “take away” that might be given to people considering developing a SaaS application was shortsighted to say the least. Without getting into “religious wars” over a complex subject – let me first say that single tenancy does serve as a reasonable tactic for ISVs in some situations:

• Limited instances for a group of large clients that require hosting and will pay the cost differential for an application that really has no direct future as a fully developed SaaS app.
• As a short term response to market pressure and provide an alternative to a competitor’s offering.
• As a beta of a future SaaS application to “get a feel for the market” in a specific vertical where the ISV has not had an offering before.
• …and similar short term, limited implementations with narrow specific goals
• Or when you are using a PaaS like Apprenda’s SaaSGrid that actually leverages a single tenant .Net application and provides hooks to services that can enable the application to operate as multitenant and scale properly.

Let me also say that as Bob Warfield of SmoothSpan pointed out recently – multitenancy in itself is not a solution to all architectural problems for SaaS applications or a guarantee the application can be maintained and operated efficiently. Or – as a friend at OpSource recently pointed out, “A single instance of a multitenant application that just keeps growing forever without the ability to spread across infrastructure intelligently is actually less reliable than a single tenant architecture.” You will know this is happening when you and everyone else using an On-Demand application is suddenly caught dead in the water without a lifeboat by a system upgrade. Even a multitenant application needs to be able to seamlessly operate across several instances to be scaleable, maintainable and reliable.

So to address the most common FUD (Fear, Uncertainty and Doubt) thrown at multitenant SaaS architecture:

• Cloud Computing has solved the problems SaaS application developers need to think about by making it a simple job to put a new instance online as needed and abstracting the “servers” under the application.

Cloud hosting options are in themselves good alternatives for deploying SaaS applications. There is a lot to like about an abstracted infrastructure. Cloud hosting is mature enough for enterprise IT to consider as an alternative to deploying on their own internal infrastructure just as they consider outsourcing other aspects of maintenance and support. But – as an alternative to a multitenant architecture it doesn’t solve the major operational problems posed by individual implementations for each client. For a version upgrade – how long will it take to bring each individual instance through testing and QA up to the current version? Will you be able to move all client instances to the new version in a coordinated way or will the fact that each client has a separate instance lead to a number of “orphans” that fear change and lag by one or more major versions? Will the overhead you face actually prevent you from applying necessary patches and bug fixes until the next “major upgrade?” And what about subscriptions, implementation of instances, payment settlement, self-service, and monitoring of usage? Most cloud-based infrastructure doesn’t address these operational issues and they will all cost you money in terms of overhead as a SaaS ISV even if they don’t cause any support issues and subsequent subscription losses.

• Most multitenant applications use individual database instances for every client so the idea of a truly multitenant application is a myth. Enterprise clients want data isolation and abhor the very idea of “blended data.”

It is certainly true that many SaaS applications have been developed with an architecture that provides an individual database implementation for each client. Whether it is is “most” or not is an unknown – SaaS vendors seldom actually disclose their underlying architecture. However, to extrapolate from the fact that many services are implemented that way because it is what “clients want” is simply silly. First – the idea that single implementations for each client are inherently “more secure” is an answer from a marketing team that has nothing else to say. If there are security risks in the environment surrounding the databases or the way the databases are implemented – single implementations will not lower them unless you believe that by being just “one tree in a forest” you have somehow “spread the risk.” Second – single implementations are inherently less maintainable (see above), have higher overhead costs and are more likely to have delayed implementations of necessary database tuning, patches and upgrades. Delayed implementations mean less security and lower reliability. Third, application upgrades almost invariably require some changes to the database or at least a cycle of testing and QA. Individual implementations mean every instance needs to be updated, tested, and perhaps rolled back if there is an error. It also means a loss of transparency and that some clients may resist upgrades if they are aware of the isolation as a “strategy” (again see above). If this results in database inconsistencies between versions you can end up with application “orphans” again and no easy way to isolate the clients involved without forking your development (and if you don’t know what that means in terms of headaches you’re in over your head).

• Big clients are very concerned about upgrades and want strong control over version migration, especially for applications that are used broadly across the enterprise.

This is certainly true when clients have the primary responsibility for end-user support and system maintenance because the application is locally installed. It is very short-sighted however to believe that a client organization won’t expect the SaaS vendor to accept responsibility for a large part or all of the end-user support and provide embedded training and self-help. This is service offering after all. Would your HR department expect IT to solve problems if Expedia didn’t place a travel reservation for a company executive? SaaS is a form of outsourcing and should be sold as such. If your business model is based on the belief that you can somehow just host the application and leave the support and change control to your customers you should take a moment and read Ben Kepes recent article on the idea that SaaS is just an extension of the old ASP model.

• A SaaS application cannot match the look and feel of their client’s environments or provide ways to be easily customized to fit client operations.

The idea that SaaS applications are somehow required to be “cookie-cutter” with little flexibility is based on a very limited knowledge of current development patterns (or just plain lazy development). Yes, a single code base is a key to maintainability, testing, QA and reliability in a SaaS application. But that doesn’t mean that flexibility cannot be built in from the ground up. It does require understanding what clients might want. It requires allowing a certain amount of “self-service” or at least apparent application “hooks” that services can exploit. On the flip side – if you customize individual instances the risk that a customization will cause incompatibilities rises exponentially in relationship to the number of different customizations. So, as an ISV you have enabled professional services and disabled your operations and reliability.

Finally – the idea that a SaaS application and a premise-based are the “same” should raise flags if you have followed some of the marketing ideas we have written about in the past. Being on the Internet gives applications an entirely different context – if they are not exploiting that idea I would question how much value the SaaS implementation is really giving customers or the vendor.

So – in the end the old adage is true – beware of advisors only carrying hammers to fix problems. They are very likely to believe every problem is a nail…

Addendum –

• The “single-tenancy meme” spread across blogs recently too – read more about the subject in Bob Warfield’s article on the SmoothSpan Blog. It is a well-written response to the misconceptions that have been springing up.
• Bob Warfield of the SmoothSpan blog and I will be talking with Jon Hansen on his PI Window on Business broadcast April 30th about SaaS and cloud-computing and you’re welcome to join us. You can read more from Jon on his blog too!
• The replay of the broadcast is now available on Jon’s site.

Our words from 2008 in a word cloud from Wordle.net

It doesn’t take a lot to see what we’ve been writing about in the month and a half Haut Tec has been around. So, just because it is the time of year when everyone is putting together predictions for the new year and hanging them out to view, I’ll make a bold prediction for our future – more cloud computing, SaaS, Agile, RIA and the business of On-Demand services. We’ll find other subjects I’m sure, but these subjects are core of our work and in fact – the issues that lead on most lists of computing technology for the near term.

From my recent experience, I can also say we’ll be discussing social media and (glup!) Social Marketing in 2009. I’ve started leveraging this area just recently and I can say without a doubt, if you are on the web and you are not leveraging the new forms of social media like Twitter, Facebook and LinkedIn (which isn’t all that new really, but many people are still discovering it) to find potential customers and partners, you’re going to be left at the dock next year and in years to come. Come to think of it – blogs are a form of social media so we’re there too – but the point is a lot of people have not figured out that if you are going to be centered on the Internet you need to fully leverage all of the tools available. In fact, just to follow that thought, here’s my contact list for those who have already figured these things out:

• Scio’s Facebook Page
• LinkedIn Public Profile
  
• Twitter
• Facebook

And yes, I am an open networker, a member of a lot of LinkedIn groups, I “follow back” on Twitter and accept friends on Facebook. I’m sure there will be others too – I’ve been networking on Twitter this week – like a lot of people – and it is exploding with new users.

We’ll also be continuing our series about The Long Tail and many more areas – I also hope to hear from you if there are subjects we’re working on that you would like to hear more about. I expect us to plunge into Agile Product Management soon – Luis Aburto’s Agile post was our most popular subject so far. We’re also continuing to expand the ISV Resources listing so if you’re interested, there is new information there for you.

Addendum – We’ve just been added to the cloud-computing feed on Alltop as you can see from our new badge on the sidebar. Thanks to Guy and his team at Alltop!

So, here’s is looking forward to a bigger and better year in 2009 for everyone!

Próspero Año Nuevo! from your Friends at Scio!

Recently I read a discussion highlighted by Herb Sutter on his weblog, Sutter’s Mill. Herb is a well-known and respected leader in development and C++. In his article, he covered many of the misconceptions that seem to exist around user interfaces for Internet-based applications. The question is: Are developers and product managers thinking too rigidly when they approach a SaaS application? Do “Web 2.0″ and Rich Internet Applications (RIA) have value in SaaS and On-Demand applications?

To answer this question, you need a sense of the context. There is a school of thought that basically says user expectations and learned usage patters should dictate the approach. For designers with this basic belief, a desktop application has a particular “look and feel” and users have set of learned behaviors that should be exploited. More than that, a Mac application should adhere strongly to Mac interface standards and a Windows application should adhere to Windows standards. The same school of thinking recognizes HTML, CSS and REST as the classic approach to web-based applications and the browser as the common user agent. For this school of thinking, developing applications that do not respect these built-in user expectations as de facto standards is at least risking user confusion and probably creating something that will lower acceptance and raise the time it takes users to achieve full productivity.

There is a second school of thought however, that comes from using languages and technologies that are not bound by the classic paradigm of “the page” as classic HTML approaches it. These same approaches tend to flatten platform issues by existing outside of the strict interpretation of a browser interface or a vendor-led interface standard. This school generally includes developers using JAVA, Flash, Flex, Silverlight, Python, AJAX and similar interpreted languages and environments. These technologies can live in a browser-based paradigm very well, but the point is – they don’t have to. They can exist on the web or off. They can provide a local client interface for a remote data source and/or a local one. They can be the whole application with parts local and remote. They can develop their own user experience and keep it across versions implemented in many different configuration.

For members of the first school – a web-based application that is not bound by a page-based interpretation is wrong. If it is based in Flash or Silverlight and does not have ways for users to share views of information contextually (the URL links we pass back and forth on the Web), ways to highlight, copy and paste information in the page context into other applications without resorting to workarounds, it is crippled. If it cannot resize text and adapt to different platforms (like a desktop and a mobile device) without multiple code bases – it is wasting resources and probably risking code forks that will create user islands.

For the second school, the page-based paradigm simply doesn’t need to exist in every application. What’s more – they question why the entire data view shown to the user should have to be updated to represent the change of only a few items in the user’s view? And, who should decide when the data is updated? If the application has an updated bit of data, why should it wait until a page is requested or refreshed to show it? We’ve seen more of this philosophy since the advent of AJAX, but in the JAVA and Flash worlds, data concurrency has never been bound by a page-based representation – inside or out of a browser. While to some this seems more like desktop application behavior – it is in truth available to any application with the right tools.

In many ways – SaaS applications represent the “third school.” The technology is new – or at least considered to be new by most people. There is no “established user paradigm” and I don’t believe we should be in a rush to build one. By its nature, a SaaS application is not bound by desktop or the Internet. The user experience needs to be completely contextual and it can be. Where it misses the mark – when workarounds and new interaction patterns are required – innovation is needed and developers either need to step up and make it happen or advocate for others to take on the challenge. There are SaaS apps which are not intended to be used much of a users day or even every day. Those are probably better left to more classic web methods where possible. There are others that users will be on for most of the day or will greatly enhance user productivity. For those there are strong opportunities for new thinking and re-engineering.

Consider: Real time updates (push instead of the classic user pull of page refresh) are more efficient when they leverage an interface that doesn’t require a full page refresh. If the user can depend on the application to update the data view when it is relevant they are freed from the impatient – “is it done yet?” – syndrome or worse – a double submit during a transaction.

If it makes sense to build a client outside of the browser (again, how much time will the user spend with the application?) there are some additional bonuses. The application is freed from the browser update cycle and needing to render correctly in several browsers on multiple platforms. Updates to the client can happen transparently – if planned correctly. The client can be locally resident in a way that allows it to integrate with local and network applications inside the firewall. In some cases, it may be necessary to use the client when network connectivity is non-existent or slow. The client can be designed to work with the remote data set in a loosely-coupled way that allows updates when the network is available.

Finally – Designers should be challenged to re-engineer the user experience and process without considering the constraints of the browser or if a browser is the best choice, to blend the page-bound paradigm with useful tools from their tool kit. And there are cases, such as when the SaaS application is an online presence of a regular desktop application like Microsoft Outlook for instance, that you don’t want to change the desktop process and learned behaviors with the web version if users will continue to use both. In this case, current technologies and user skills can be leveraged to duplicate the desktop application and user experience very closely. It is important in these situations to develop the application for browsers agnostically. Saying “we support browser XYZ and so should you” – is just short sighted. The development time saved will never pay for the lost users in a SaaS application – where customer retention really counts. For SaaS ISVs, developing the “target user experience” up front should be as much a part of the design process as deciding on the stack – and in fact must proceed the stack in importance if the application is to realize its potential.

Useful? Copy, paste and Tweet it!

RIA and SaaS – Opportunity or Hype? http://bit.ly/10Cdy

This is the first article in a four part series I’ve planned about “The Long Tail” and services (SaaS, On-Demand, etc) on the Internet.

If you have read anything at all about marketing for the web in the last few years, it is hard to imagine you might not have also heard the term, “The Long Tail.” The idea has a long history with statisticians, but the term we use dates back to 2004 when Chris Anderson wrote a magazine article in Wired describing the concepts. He also wrote a best selling book on concept, which has been recently updated. But, judging from many of the articles which use the term, I don’t blame you if you’re not sure what it is all about.

For entrepreneurs considering development of new Internet-based services, it is a critical concept. Going back to the well-written and much reviewed piece by Joel York – “Software-as-Service Success, The Top Ten Do’s and Don’t of SaaS” – Let’s assume for a minute you have read the piece (please!) and list the do’s and don’t in summary:

The Top Ten Dos of SaaS Success

1. Choose a Large Market
2. Create a Hub on the Web
3. Accelerate Organic Growth
4. Craft a Compelling Story
5. Build the Business into the Product
6. Reach across the Firewall
7. Monetize Creatively
8. Enable Mass Customization
9. Open Up to the Cloud
10. Leverage Your Community

The Don’ts: Ten Surefire Ways to Fail at SaaS

1. Chase Elephants
2. Waste Money Marketing Offline
3. Launch without Online Trial
4. Cover up Shortcomings with People
5. Invest in Channel Partners too Early
6. Bleed Cash Indefinitely
7. Ignore the Long Tail
8. Think You Can Control It
9. Fail to be Creative
10. Depend on Network Effects

So, if you think you understand SaaS and The Long Tail – How many of those points could be said to have at least something with do with it?

Now before we give an answer, consider these scenarios:

• A bookseller in Grand Central Station, NY – that only offers books (no gum, no sodas, etc.) from the New York Times’ Best Sellers List.
• His friend has an antiquarian bookstore, hidden away in a back alley in San Francisco – offering only a very select group of special books.

Which seller is likely to have a higher cash income before costs? Which seller is likely to make the most profit per sale? Which bookseller would be likely to see the best result from listing their offerings with Amazon? If they did list with Amazon, which bookseller is more likely to win in the long run?

The fellow with his stand in Grand Central has access to a huge pool walking by but his offering is basically a commodity. His customers have only a short period of time to consider what they will buy. He is likely to have a higher gross than his friend in San Francisco, but make very little per sale. He needs very high volume to make a go of it. He is competing with every drug store, supermarket checkout, mega-chain, – you name it. His costs are high because the spot where his stall sits is considered a prime opportunity. He has to keep an eye on the stock as long as his stall is open to keep it from walking away. His profit per book is relatively low because his purchasing power is relatively low and his competition can both buy and sell at lower price points. If he tried to sell on Amazon, he would have access to many more customers, but he would not be alone. He would be selling against many other outlets and Amazon itself – selling the same commodity. Although he would really only pay for the service if a book sold, his return for maintaining his offerings is likely to be low to zero. He might do better to invest in some crawling signs listing his best sellers in large letters.

The antiquarian on the other hand, probably pays very little for his out of the way storefront. He may not even be open on a daily or regular basis – preferring to meet his customer primarily “by appointment.’ Since his volumes are by their nature rare, there is very little competition and the price can be relatively high. But his market is also quite limited. Although his stock acquisition costs are likely to be relatively high, his return is good, when he makes sales. If he put his offerings on Amazon he would gain from access to the same size audience as his friend in New York, but his results are likely to be much better. Suddenly his rarities are exposed to a much larger pool, out of which some sales are likely to flow if he knows the antiquarian book market. People who would never have found him on the back streets of San Francisco or by word of mouth, can now find his books by searching Amazon. When they do, they are likely to find very few, if any, competitors.

Now considering that scenario – who is the big winner? Amazon, of course. Amazon has enabled customers to buy not only the best selling books at good prices but also some very rare and out of print books too if they are interested – by aggregating the market. Amazon serves The Long Tail for both buyers and sellers by being the head of the tail(s) – in this case. By bringing in sellers of products to both compete with Amazon’s own stock and extend their offerings, Amazon has created a market it wins from whether it sells directly or simply offers its technology as a tool to enable other sellers.

But – as Chris Anderson himself has written:

“Invoking the Long Tail is not a magic wand to explain away the apparent lack of demand for what you’ve got. The Long Tail is not a get-out-of-jail-free card for poor-selling product. Or weak sectors. Or bad ideas.”

A tail without a head, like our antiquarian, is simply a niche. The chance of finding his shop, while you’re in the mood to consider a shelf of old books, and on a day when he happens to have the one you are interested in – are slight. It would be much better if he knew of you and your interests, which is why most antiquarians cultivate buyer lists at fairs where the avid buyers congregate. The book fair is usually the “head” of his tail.

So, to borrow from Chris one more time – The Long Tail is not about:

• Commodification – Our bookseller at Grand Central is in a commodity business and it is easy to see why Amazon offers little of value to him. He doesn’t have the ability to scale his volume enough to overcome the advantage of much larger sellers in the Amazon marketplace including Amazon itself.
• The case for an all amateur, self-published future – While our antiquarian is selling rare books, there has to be a story, a market for what he is offering somewhere. If he was writing them but no one had heard of his books or him, Amazon is unlikely to be of much help.
• The actual end of hits – Amazon needs the big selling items to get buyers, but it also needs the niche sellers to broaden the variety and continue to attract buyers or it drifts entirely into commodity sales. The market Amazon makes needs to feed the commodity sales and the niche sales equally even though the better known items will continue to outsell the niche items. The balance benefits Amazon and the niche sellers like our antiquarian, but makes it tougher for his friend in NY because he is competing directly with Amazon.
• A focus on small markets at the exclusion of large ones – Without the top selling items, total traffic for Amazon will be low and the random chance of the seller in The Long Tail actually finding his buyers will decrease drastically.
• Just any power law - If you read much about The Long Tail you are likely to run up against the term “power law.” Without getting into the math, the point of understanding The Long Tail is to know when power laws can be leveraged and how – The Long Tail requires “massive variety and a wide range between the hits (incoming prospects) and niches (opportunities for satisfying specific needs).” There are a lot of ways to make it work – but satisfying those two qualifications remains key.

So what is the answer? Which of the 10 does and 10 don’ts have something to do with The Long Tail? Hmmmm – join us for the next article in this series and I’ll tell you.

Yes, I will – now go save the RSS feed for this blog and read the linked articles. You should have the answer already!

Helpful? Copy, Paste, then Tweet it!

The Long Tail – What It Is and Isn’t http://bit.ly/kHbJ

With so much uncertainty and emphasis on the economy at this time, it is no surprise that most of the “On-Demand” articles I’m seeing right now are about either the reaction of customers – SaaS adopters – or SaaS startups and vendors to the market. Jeff Kaplan wrote about it from an industry perspective this morning on Seeking Alpha. One of his key conclusions was:

“…many of the SaaS, cloud computing and managed service companies who were hoping to capitalize on the current crisis by increasing their sales and marketing efforts to promote their business benefits in a down economy are being forced to go slow or even cut back their spending instead. Many of these on-demand service companies are also facing longer sales cycles as customers delay their purchase decisions and demand more information about the providers’ operations and financial status as a part of their due diligence process.”

The simple fact is prospective clients are holding back on making decisions during this uncertain period. That in turn is putting plans on hold for many On-Demand vendors. Since that is a big part of our market – we’re seeing it too. However, there is another side to all of this – I’ve seen many write-ups recommending that millions of dollars in marketing are required for a new SaaS product. in point of fact, we have customers and friends that are succeeding for far less. How? Their apps are built on a flexible platform to a specific vertical market and they know the addressable portion of that market very well. When the economy turns, they will be well positioned to expand horizontally. As Joel York of Chaotic Flow wrote in his guest post on SaaSBlogs, “SaaS Business Profitability – Build for the long tail and get the rest for free (almost)” This paragraph says it well:

“Build for the long tail first.

If you create your business around the product vision of profitably servicing the lowest revenue customer, then you will have no problem servicing higher revenue customers. Once you have your basic cost structure in line, it is easy to add advanced product capabilities and services to move upstream profitably. However, it is virtually impossible to move downstream once are locked into a high-touch, high-cost operational model.”

Trying to build either a “Swiss Army Knife” that is full of features so it will solve every problem or the solution that the largest five players in the market need is likely to be an exercise in failure from the start. Either the number of features will dictate that the development cost and therefore the subscription cost will be high or the solution will be so specific that very few prospects will find the product appealing. And – while we’re at it – the features that are eventually built into the product for the higher value customers don’t have to be available to everyone or even available as part of a subscription. They could be transaction-based or just available to subscribers in a certain class (and different subscription structure).

So – there are two ways to survive as a SaaS ISV:

• Build to the long tail, serve the lowest revenue customer first. Build lean on a flexible platform that allows you to add features and new subscription models as you grow.
• Know your market (long tail again). Know the addressable portion and market to them effectively. Don’t try to “take over the world” from the start.

But, here is perhaps the most important issue – SERVICE. In SaaS and the on-demand model, customer retention is the key to survival. Gaining new customers has a cost no matter how automated your “onramp” may be. Retaining existing customers means understanding their needs, their processes and most of all being there (reliability) when needed both as an application and a customer support group. As easy as it is to adopt an on-demand application – it is even easier to drop. There is no software to uninstall, no hardware to dispose of, no resources to lay off, and no license to renegotiate. Just hang up. This article on ZDNet by Archie Black of SPS Commerce says it well.

When we’re all back counting our opportunities and smiling, the companies who have survived this downturn will have mastered customer service and the art of the long tail in ways startups can’t imagine. On the flip side, consider enterprise software vendors who have stalled and are trying to catch up in this market like SAP. They are seeing their market erode on two fronts – adoptions are slowing and existing customers are leaking away or reconsidering their expensive licensed software. Not Pretty.

We’ve felt it – everybody has. The “credit-crunch,” the “downturn,” or whatever you want to call it. The impact of this latest wave of economic news is being felt globally. A lot of companies, small and large, have put their plans “on hold” indefinitely.

So we’ve wondered – what is the outlook for SaaS development in this market? What do new ventures have to look forward to? Well, there are several thoughts on that. Amy Wohl, the author of Succeeding at SaaS, wrote in her recent blog entry:

I’ve been stating strongly that this is the best of times for SaaS. In an economic downturn, companies should — and do — find a solution that requires no capital investment and little or no labor very appealing. When you add the fact that it can often get projects started more quickly, it’s easy to see why it’s so popular.

So buyers need SaaS even more in this time than ever – but that still doesn’t make it easy for ISVs and startups to consider, much less lay out the cash for new products. Many just see SaaS as just more industry hype of an idea with a long history. Certainly SaaS is a different business model for those with traditional, licensed products. Is it profitable? Yes – with a great product (of course), but it is true the cash flow in a On-Demand model takes a different approach. The typical startup advice is to have four years of “runway cash” on hand for a SaaS business. I’d say that’s true – but not always. The customers we generally work with are serving a vertical niche that they understand well. They know the “tipping point” for features their market requires and are willing to build to it and leverage the Agile product management approach to continuously improve. They know how to get to their customer base because it is well-defined. They can continue to build their product to serve markets horizontally over time. They aren’t trying to replace a general purpose, desktop application. From what we’ve seen, these are key points in successful SaaS products right now.

SaaS industry pundit Jeff Kaplan wrote an article for Seeking Alpha that’s worth a read. I like this quote from his article:

The truth is that there are many successful (i.e., profitable) SaaS companies. Salesforce.com (CRM) is experiencing exponential growth, achieving unprecedented customer satisfaction ratings and reports limited profits only because it is seeking to win market share and could easily generate greater profits if it wanted to accept slower growth.

That is the point after all – the roadmap, the market, and the opportunity define the need for cash – not SaaS or On-Demand business models themselves. There are lots of strategies, but those are the choices everyone has to make in every business. The opportunity in this market – it seems to me – is to fill a growing need.