They say everybody likes lists. Miles of virtual paper have been inked in pursuit of the “best recipes for chocolate chip cookies,” the “worst airline food,” and to complete the theme – the best diet plans. Ok then- we’ve got a list:

Ten Ways to Fail as a SaaS Company

Introduction

This little list comes from reading some recent blog entries like the post our friend Abe Sultan of Apprenda wrote for Datamation – How to Fail Miserably as a SaaS Company and my own conversations with software company executives. Before anybody says it – it is not every way there is to fail at SaaS. And like any limited list covering a big subject – the items are over broad and not necessarily indicative of the most common ways to fail.

But that said, these are the things that really irritate me and I’m sure irritate those who have lived these errors – as happens in the life of an entrepreneur. So, if you are or are considering offering a product with the SaaS business and delivery model, you might want to think about these common trip points:

1. Provide your licensed software in a hosted delivery model

I put this one first because it is probably one of the most common errors I see and one that we and a lot of other consultants in the field have, in one way or another, suggested at one time. I don’t suggest it anymore because I have seen what happens all to often when what started out as a simple little test exercise becomes a raging white elephant. What’s wrong with this idea?

• Your licensed product is very unlikely to be a good candidate for a SaaS product. This is a “test” of something you can never sell, maintain, operate or scale to reach a decent market. So – what are you testing? This is what is known as SoSaaS. Vendors of licensed products, especially high-value, line of business applications, typically aim their product at the top of their vertical market. It’s just more cost efficient for sales and marketing. The product is loaded with features that satisfy that end of the market and tuned for skilled install by client IT personnel. If it penetrates the 100 top accounts – it’s golden. SaaS products are built to sell and scale to a much wider market. If you can’t do that you are very unlikely to recover your hosting and maintenance costs – much less further development costs in a SaaS model.
• If your experiment is successful at even a minimum level, it will eat your licensed sales. This is equivalent to killing your milk cow for food right after the new calf is born. Best case is to design your initial SaaS offering to reach the needs of the “second tier” and maybe a larger section of the market. This is where the general rule of thumb “80% of value is derived from 20% of the features” comes into play. Leave the rest of the features, that continue to be of value to the top end of the market, off the list. Those customers with the licensed product won’t abandon ship overnight for the more focused SaaS product.
• And the biggest reason – these initiatives tend to color thoughts about moving to a full SaaS offering. The longer they go on, the more you focus on making the failed ASP model of service work. Don’t be Sisyphus. There is nothing to be learned here that you can’t figure out on a spreadsheet with a few links to articles. Costs won’t work out, maintainability won’t emerge and if customers do sign up in droves it will kill you. …And no, ASP in the Clouds is not a magic pill. You just automated part of a bad choice. Chutes and ladders only make the process of rolling the rock up the hill slightly less onerous.

2. Don’t test your market.

I love this one. It is so simple but somehow so counterintuitive to the culture of innovation that has built up over the years. We’ve all seen it. We’re invited to talk about a product from a new startup and the first thing we’re asked to do is sign an NDA. The office is dark and there are gatekeepers to insure competitors can’t get in. There is a sense that we have a new truth hidden in our product and when we release it to the world customers will smile and run to our door. We just don’t want someone to steal it before we finish it and release before we do!

This is an old technical/patent-pending/hardware product approach. 99% of SaaS does not and never will bring forth new technology, software process patents not withstanding. SaaS is expertise wrapped in an on-demand delivery system. It is a service and should be sold as such.

As Steve Blank as so elegantly put it – there are no truths inside your office. Get out and meet the target market before you spend on developing the product whether it is entirely new or a 2nd tier offering of an existing product. Talk to end-users. Show them demos, ask them if they see the value of what you are offering. What would they pay? What doesn’t it do that would make it more valuable? Listen. Take notes, make changes, recycle. After the process reaches a logical conclusion you will have something you can specify and sell. In fact you will already have your beta test pool.

Yes, maybe your competitors will get wind of what you are considering. I hope they do. I hope they short cut the process and spend thousands on bringing out a product without a verified market. Tell them they can’t wait. Go into that dark room and scope that product right now…

3. Ignore business operations.

This source of common failure is so broad it can cover a many articles. And it has. A SaaS operation is different at every level – marketing, sales, implementation, support, maintenance, development – and much of the operations side is expressed as part of the application itself. The online marketing site needs to hook directly to payment, provisioning, implementation and client admin so the new user can get authenticated and in front of the application right after paying. Subscription renewals are automated. Feature bundling and pricing is updated once and is expressed through out operations immediately. Community feedback is integrated into support and product development. None of these operations exist in a traditional software business.

Metrics can guide operations, but the organization itself needs to be aligned with new practices to take advantage of what the metrics tell you. “We have many users dropping off their company accounts before they have recovered the cost of acquisition.” Ok. This is not a bullet point in a slide – it is a question: Why? Someone has to track down the reason and fix it before we burn through a lot of cash. A successful SaaS business is about being proactive. If you wait to feel the pain, it is already too late.

4. Ignore architecture, services, environments and/or reliability

This is another point that is frankly too broad. Such is the nature of lists. This breaks down to a few points:

• SaaS products need to be brought to market economically. See point 2. Your product is going to have to change after release. There is no ultimate truth or one size fits all development solution for SaaS products. Operations (point 3) typically take as much as 60% of development effort if they are developed as part of the product from the beginning. If you can take advantage of a service or platform or tool or outsourcing to lower your risk, development cost and time to market – do it. If your product is properly architected, you can add critical services when you have a proven market and it makes sense to offset income temporarily to capture an ongoing service cost.
• SaaS products need to be architected to be maintainable, tunable, configurable, and stable across the growth pattern expected of a successful product. We change the tires on properly architected SaaS products going down the freeway at 70 miles an hour all the time. We don’t change the framework and drive train without serious consideration. It means pulling over and stopping and that is a hit against reliability.
• SaaS product planning is not software development as usual. You need to know the pitfalls and getting it wrong can be very costly. Get help. Do proof of concept runs. Don’t stumble about in the dark trying to deliver a product. You will find out too late if you are wrong and need to re-architect the product.

5. Ignore end users.

This is the one that broadsides traditional software vendors. Vendors of locally-installed, licensed business products sell to purchasing and key executives. Traditional product users receive what they are given. It is already paid for. Unless it is tragically flawed, they will be trained to use it productively . If they fail training they are moved to other work or let go as “untrainable.” Conversations with end-users are limited to a few words at trade shows and association meetings.

SaaS may be purchased in much the same way, although increasingly line of business users are tasked to do the research and build the internal business case themselves. But, once the subscription is purchased, the clock starts ticking. This subscription is an ongoing part of overhead. What is it contributing to productivity? Is everyone using it? End-user feedback is now front and center. There is seldom any training. A SaaS product is expected to be intuitive and the uptake is expected to be measured in hours if not minutes. If it takes days or weeks to bring new users online, it is a failed experiment from the beginning.

SaaS product management is also tightly linked to end-users. There is a lot to consider in the delicate dance of product strategy and user-led response and we will cover those issues in coming podcasts and articles – the point for now is that SaaS vendors are directly responsible to end-users for their experience. There is no IT department operating as the go-between while fielding first level support questions. If end-users are not satisfied, they will do one of two things – invent their own workarounds or return to their previous tools. Either way they will cease to advocate the service and in many cases will actively lobby to have it shut off. In the case of an on-going overhead cost – they will be successful.That means ultimately the SaaS vendor will lose revenue and may not cover costs. When cost of customer acquisition exceeds lifetime value or end-user loss exceeds new customer uptake – the cost of operation will start exceeding profit very quickly.

Sadly, we’ve reached the logical limit for number of words in an article that people can digest in a reasonable period of time. So, there will be a part two of this article where we will cover the other five points of the ten. Can you already guess what they are? Join us in part two.

In this article we’re picking up where we left off in Part 1 on our expansion of the podcast we did with Steve Plunkett, CTO of Servitizer and our panel of industry experts – Luis Aburto, CEO of Scio Consulting, Mikael Blaisdell of MBlaisdell & Associates and Lincoln Murphy of Sixteen Ventures. If you haven’t read the first part of our series already – please start there – because the background for the conversation is there.

Going back then to where we left the conversation – Mikael Blaisdell weighed in saying that although he believes the industry is strongly moving towards servitization, vendors still see themselves as selling a technical product. From a business perspective, because of the license-forward sales model of traditional licensed software, vendors realized all their profit “up front” in a sale (although it has to be said, post development and marketing). All following costs, which might be services, were avoided as much as possible. ISVs build a lot of expertise in building software and internal operations to fit that model – expertise in managing the development, marketing and sales processes to match the cyclical nature of licensed software sales. Moving to an incremental revenue model is one aspect of SaaS and many ISVs have made the transition – however difficult that might be. But when it came to marketing the product – they are still selling it as a technology – even if they see it as embodying special expertise for their market and not as a service.

As Mikael pointed out – a true SaaS product needs to embody the relationship between the vendor and the end-user community they are serving. But – unfortunately – very few vendors have figured out how to market that service-based relationship successfully. Not just because it is hard for established vendors to do – primarily because it is just not a part of their strategic view of their product. They still see themselves as technology vendors, not as service providers.

Further, the standard model conveniently supported a split set of payments to the vendor. The vendor set license fees for the product and a separate set of support and maintenance fees to provide ongoing services. In other words, the support services were almost an “optional add-on.” Those same vendors, moving to a “as a Service” model, have to rethink their cash flow and put services in all its various aspects up front while still maintaining enough bandwidth to support ongoing development.

Even more important, transitioning to an “as a Service” model requires a deep reconfiguring of the basic understanding of the product within the vendor organization. This is why it is often (rightfully) said it is easier to start from scratch than “turn a corner” and move from a traditional licensed model to a incremental sales model like SaaS. In the “as a Service” model, focus of the customer relationship shifts to the end-user experience, the expertise embodied in the application, the productivity it enables and the value it delivers. If any one of these areas slips in relationship to either market competition or the experience of users without the product – subscription renewals will decrease and the vendor will feel it immediately. For the vendor organization, their window of reaction time to address customer needs has decreased dramatically and the need to communicate with end-users has increased many times over. A traditional ISV’s expertise and business organization is simply not set up for this transition. As Mikael pointed out – SaaS vendors have to understand this from the core of the organization outward if they are going to succeed. This is a process that is in many ways just beginning in the industry.

In the same way – the industry still uses a “feature-led” technical product approach when selling as a Service offerings. Using a feature list is still considered to be the key way to compare SaaS applications. Do people use all of those features? Are they implemented in a way that users find productive? The industry is not at the stage where this kind of detail can easily be communicated.

Luis Aburto summarized the approach of many vendors when he said that often the first thought is “We just need to get a web version of our application set up and let people subscribe – that’s it.” But after a while they start start to realize the business implications of putting an application on the web:

• Users expect 100% uptime – no “maintenance windows,” no upgrade weekend, no outages
• Users expect consistent performance in the browser and in the back end processing of their data. Having a “end of the day” slowdown is just not acceptable.
• Users expect the vendor to take responsibility for their data security and be able to articulate how they provide security.
• Users expect all aspects of the application stack to “just work” – integration, payment processing, database updates – all working seamlessly and without interruption of the business cycle.
• Users expect the vendor to have plans and tested procedures for disaster recovery and operational contingencies. If there is something the end-user organization needs to do, they expect the tools and processes to be available upfront.

When you consider all the issues this includes, it can become a little scary for existing ISVs coming into the as a Service field. None of these services are part of the expertise they carry in house. There are aspects of these services that can only be handled effectively if the application and its delivery is properly architected from the beginning. Yes, you can get up and “operating” without addressing all of these issues, but in the end, customers will demand full transparency or they will leave.

Of course, as the old ASP model showed, these services cannot be addressed in one off implementations for each customer organization. The delivery model must address customers in a way that allows economies of scale to be passed through. Using multi-tenant architecture and cloud technologies, it is possible for vendors to be more efficient at addressing these issues than the internal IT resources of their customers would be. With scale, the vendor can afford to have more professional expertise at their command than their customers can carry individually.

Addressing these issues effectively also translates into the struggles of sales and marketing in SaaS. Feature-led, version dependent marketing and sales cycles will only work for a short window of time for a service-based product. When the cost of acquisition and operation exceeds the lifetime value of an average subscription – the burn rate will quickly overcome the vendor’s ability to cover losses. And why? Because after a short period of time, the “new car smell” wears off and the end-users start questioning what the value the service is providing. If it isn’t enough – they leave.

Steve Plunkett said it well when he added that vendors today need to be able to articulate the value of the responsibility they are taking on – in addition to actually being able to perform in this environment. Of course, if a vendor hasn’t really considered all the costs of all their new responsibilities they are taking on – it is hard to express the value to their customers and harder still to manage them as effectively as they need to. Going to another aspect, sales teams now need to go from being “hunters” to working hand in hand with product management and becoming farmers – growing their garden of customers and maintaining the relationship with them over the life of their subscription. While many focus on the straight-forward change in their compensation model, this change in the sales relationship may in fact be much harder for sales teams to negotiate.

Even if vendors realize the responsibilities they are taking on – they should be careful as they decide to take them on directly. SaaS vendors, new SaaS vendors particularly, should consider taking some of their own medicine by deciding what parts of their service are core and must be handled internally and what parts can be outsourced to other service providers with appropriate service agreements. This means a big change in the industry. The SaaS vendor is now orchestrating the outsourcing relationships on behalf of his customers. The whole industry ecosystem is turned on its head. Instead of pursing enterprise IT departments – in a “as a Service” model, ecosystem venors are responsible to the service provider that is linked directly to the end user. This should result in better service to the end user and frankly SMBs have the most to gain. The service provider has much more leverage and efficiency than a customer with 100 seats or a line of business group with ten seats.

With all that said, the investment and expertise needed to develop and field a successful service in this market is significant. As Mikael Blaisdell added, it becomes even more important in areas where competition exists. While a vendor might get by with a mediocre user experience or shaky infrastructure by serving the “under served” SMB market – once a competitor appears, all bets are off. Integration and customer assurance demands that user data be addressable and extensible in modern services. Customers can and will “jump ship” and can do so with increasing facility. Leveraging the ability to tap into user experience at this point is critical. If the cost of operations and acquisition is equivalent to the subscription for an average size implementation at ten months and the customer leaves at the end of 12 months – there are only two months profit “in the bank.” That is a recipe for failure. When vendors assess their subscription losses, if the answer that appears is the users’ business needs changed or their assessment of those needs altered – a red flag should fly up in front of them. Why didn’t we know? What can we do to be more “intimate” with our customer’s operations? What do we need to do to be able to adapt our application smoothly to meet the expectations of our users?

So – we come full circle. XaaS is not a technology. It is a business model delivered and enabled by carefully planned technology. The successful vendor needs to manage technology and technical services to deliver their service to their end-users. The extent to which they can do that and continue express the lifetime value they provide in a user experience will equal their success in the market.

Planning the technology to allow the kind of change and growth needed is key. The application has to be properly architected to allow the mining of necessary metadata. The customer support and feedback mechanisms need to be integrated fully both in the application and in the product management function itself.

It is the orchestration of all these aspects of business and technology on behalf of the end user relationship that finally changes every part of the service vendor’s organization. Traditional product management approaches are woefully out of step in this environment. Sales and marketing are poorly equipped at best. Technical services don’t exist. Finance has to rethink every aspect of cash flow and when profit is “realized.”

And as more services come online and reach acceptance – integration of data and the services themselves will be even more critical. Some vendors will become the “system of record” and handle several services on behalf of their customers, while others will remain part of a larger ecosystem used by those “master services.” No customer is going to want to try to manage a mash-up of many services for long if a vendor appears that will manage the relationships for them.

It was here our guest and panel reached an interesting conclusion. The term “Independent Software Vendor” in this market is no longer useful. No vendor is likely to exist in a vacuum and the customer doesn’t care. Users just want the service to work. As a group we toyed with various permutations of the ISV term but I think we finally arrived at “Interdependent Services Vendor” as the more logical evolution. It describes a new relationship between the vendor, the end-user and the larger ecosystem which ultimately must be in place if the industry is to be successful in the long run.

Just remember folks – you heard it first on Haut Tech Conversations

That sums up our first podcast. Once again I want to deeply thank our panel – Luis Aburto of Scio Consulting, Mikael Blaisdell of The HotLine and MBlaisdell & Associates, and Lincoln Murphy of Sixteen Ventures – and of course our guest, Steve Plunkett of Servitizer. I think this podcast did a lot to better describe what becoming a service provider means and where the industry is going – in fact has to go – in the coming years.

If you would like to download the podcast – it is available here and if you would like to subscribe to the podcast feed – it is available here. We’re already planning a very interesting show for next month – so please watch this blog for more information next week when we announce our guests. The conversation continues here, on the blogs of Lincoln Murphy, Steve Plunkett, Mikael Blaisdell and I’m sure others. You can also join our LinkedIn group and continue the conversation there as well.

The question I pose in the title of this article is the theme of the podcast we did this month for Haut Tech Conversations. It turned out to be quite a conversation and you can download it and listen to it in its entirety here. Our panel and guest brought up so many excellent points that I’m going to take the time to summarize and extend them in this “post interview” so they are not lost.

Giving credit where it is due: Our guest was Steve Plunkett, CTO of Servitizer. He has studied the concept of delivering services over the Internet and has a depth of understanding and experience few in the field can claim. I recommend his blog as a continuing series of insightful articles on the business of delivering services in an on-demand world.

Giving more depth and points of view, our panel was stellar. Luis Aburto, CEO of Scio Consulting provided a clear summary of the intersection of technology and business concerns that make up service offerings in this field. Mikael Blaisdell of MBaisdell & Associates brought up a range of issues that are rarely if ever considered in planning and developing a service. Lincoln Murphy of Sixteen Ventures broadened the business side of the discussion many times over.

The conversation exceeded my expectations and I encourage you to listen when you can. But I felt that the key points can be easily lost because an hour seems like a long time when you just think about it – when listening to the conversation there is a lot of information coming all at once. So – this series is an attempt to summarize and extend the wealth of insight and ideas we covered.

First – let me cover the title of this article with a few words. The subject of this article is service offerings on the Internet – broadly. This means not just Software as a Service (SaaS) or Platforms (PaaS) or Infrastructure (IaaS) – it includes all the various types of service products available now on a subscription or fee for use basis. This is often referred to as “X”aaS – whatever you might want to put in front of the words “as a Service” and includes the various cloud services and application services extensions for things like billing, metering, integration, etc.

The Gartner Group has recently said we’re at the peak of the hype cycle for these offerings. I agree and I also believe that many services today are “immature” at best as pointed out by a independent study mentioned in a recent article by Dave Rosenberg. That leads to the “trough of disillusionment” as Gartner calls it – when early adopters find the services are not yet where their marketing said they should be and they “push back” against the vendors to deliver at a level consistent with critical business needs.

It is the realization that much of the promise in the XaaS market is still to often just that – a vague promise – that I think united all our guests. The “Service” in many service offerings on the Internet is still poorly defined and poorly delivered, even by major players. And I think i can speak for everyone when I say we are not just standing on the sidelines booing when we say that – we’re all all personally and professionally committed to helping our clients and the industry get to the level of maturity that is necessary for long-term success.

Steve Plunkett kicked off the conversation with some background on “servitization” in industry and an example that struck me – Rolls Royce Aviation provides jet engines for much of the commercial aircraft fleet in service today. But they don’t do it by “selling” the engines – they provide them as a service-based on the number of miles flown, along with all the maintenance and support necessary to operate them, to their customers. When you take an example of a service like that you immediately see that there is more to it than just putting engines on planes – this is the entire operational assurance that goes with the operation of an aircraft and the critical service it is providing its customers. As Steve pointed out – our industry is still very naive when it comes to providing this level of direct services to customers. In the past, it was enough to provide a CD and an install script. It was someone else’s responsibility to properly size, secure, and provide access to the server where it was installed. Service was limited to second or third-level calls to the help desk. But as Phil Wainewright of ZDNet recently pointed out – this isn’t because a service-based approach is new to the industry. If nothing else, it could be said that licensed software started in earnest because of US anti-trust actions against IBM.

The core issue for the industry and SaaS vendors is there is a great lack of understanding when it comes to approaching the business of becoming a service provider, especially for companies that started out as straight-forward “product providers” – meaning those who provide software and a license but don’t provide any of the delivery and operational mechanisms that allow people or other systems to use the application. In fact, it could be said that it is much easier to be a XaaS startup than to transition from being a traditional ISV to SaaS. Going back to the quote from Gartner, if we don’t address this problem, it will greatly impede – if not sink – XaaS as an alternative in the market.

This leads to another point Steve made quite strongly. We are talking about the industry as a whole when we say this. There are a lot of vested interests, that as always in the face of disruptive change (like the current debate on healthcare), will advocate for the least amount of change if not avoid it altogether – the “do nothing option.” These objections come in a lot of forms:

• Product managers will say you can’t control a product development cycle driven by direct customer involvement – as customers expect on the Internet.
• Your Value-Added Reseller (VAR) will tell you there is no way you can sell direct in your market – and maybe they are right – but did you ask if they were ready to become Value-Added-Service Providers? What value will they add to a service-led offering to assure their place in the chain?
• Your IT department will tell you they are not ready to provide the level of service and reliability customers expect for critical line of business applications. But – have they identified the requirements so they can figure out what it takes and who can?
• Your sales group will say they cannot transition from large up front license sales to incremental subscriptions.
• Your marketing group will tell you they cannot imagine how they will operate without the “big bang” of a new feature list for their next trade show.
• Your outsourcing group will tell you they can help you get to where you need to go but they can’t offer a model of interaction and reliability that reflects a more service-led approach.

These same issues are echoed across the industry by naysayers who say security and reliability problems are too great, integration or customization is beyond SaaS, and the business model is too hard to make a profit with. The issue is getting them all to acknowledge that providing a service instead of a packaged application is yes, inherently different from the current “norm” but in many ways just part of the larger business push toward “servitization.” On balance, I think our answer is, “Get over it.” This is a business opportunity and you will either find ways to take advantage of it or get left by the wayside.

In the early days of the industry companies like IBM and HP provided much, if not all the IT services needed by major enterprises. The aforementioned anti-trust action along with the rise of commodity desktop computers and servers provided an alternative that allowed a lower point of entry brought a great deal of disruption that companies like Microsoft took full advantage of as they moved into a place of dominance. Just like today, there were many changes and many players who felt a sense of entitlement in their roles who were ultimately displaced when they couldn’t make the transition.

A big part the change is the place and role of the service provider (the former software vendor). Now end-users look to the service directly when they have questions about how the application is “supposed to function” and internal IT resources (rightfully) expect their direct support role to be measurably diminished. This is the service that is being paid for after all. Gone are the days when the IT service desk made the decision to push the call “up” to the second or third level support with the vendor. Now the IT department expects the calls to come from the vendor and then only when they cannot resolve a local communication or desktop configuration issue. In fact, increasingly the role of the IT department is to set the standards and expectations that fit the business case for a line of business service and then hold the vendor accountable.

Lincoln Murphy pointed out that within servitized products, it is the service that keeps commoditization at bay. A successful vendor becomes more directly involved and responsible to the end-user both as the service provider and the subject matter expert in the field they represent. As Lincoln pointed out – we can go to our personal computer and start “Word 2003″ and it will work just fine – just as it did in 2003. But if Word was online, we would expect it to seamlessly evolve and be something more that it was six years ago – just as iGoogle is a clear line of evolution from the iconic single search box we all came to love when it first began. In the same way, “Infrastructure as a Service” needs to be more than a commoditized server. If it is not – it isn’t going to displace local servers.

And to extend the concept – a service on the Internet has a “responsibility” to carry the model to include the level of communication the delivery medium allows. Is a platform or infrastructure service benefitting you enough if you can’t leverage the ecosystem or community that revolves around it? What is left “off the table” when the community around a line of business application cannot leverage a forum or even list server to communicate best practices, voice concerns and answer questions? These things certainly exist for premise-based products, but they aren’t baked into the business model and certainly not part of the application itself. The question should be – why aren’t they in a XaaS offering?

Moving yet deeper, Lincoln pointed out that XaaS offerings must leverage their ability to monitor their customer interactions with their product to ensure features are of value and meeting customer expectations. Security concerns aside, generalized usage metadata allows service providers a level of understanding of user interaction. Rather than shying away from monitoring customers, it is a responsibility to users to ensure the service will continue to deliver value and to the brand to ensure it stays ahead of competitive offerings.

This means an XaaS offering has to be much more than a new technology. In fact, I would have to say marketing any XaaS product as a technology alone is an error. Of course, the delivery system itself is technical. The expertise and services that are on top of the delivery are enabled by technology, but if they do not stand on their own, they cannot go beyond simply surviving and move to thriving. An excellent product without the technical underpinnings that provide reliability and scalability will fail to reach its potential. In the same way, the mediocre product with excellent technology will be replaced by competitors in no time, especially when that product is delivered on the Internet. There is simply no real barrier to prevent it.

With that we have set the stage to get deeper into the conversation with Mikael Blaisedell taking us into another aspect of the question – what does “as a Service” really mean? But, this article has reached as much length as I think readers can handle so you will have to join us in Part 2 of our series or – download and listen to the podcast. And – feel free to extend the conversation in your own way – here in comments or on your own blog. We’ll be listening…