People say that marketing for “cloud services” are really over the top right now – selling a lot more promise than can be delivered. If that’s true, social media is somewhere out in the stratosphere of hype – pushed into orbit by leaders like Twitter and Facebook - I’ve heard many people say if they were trying to avoid reading yet another article on the wonders of connecting to “communities” on the web.

If that’s the case for you – I hope you’ll set your prejudice aside and listen to our podcast this month on Haut Tech Conversations. You can download the show and listen to it at your leisure. Our guest was Jonathan Hyland, the Client Relationship Director for iCIMS, a leading SaaS provider of “Talent Management Systems.” Jonathan is deep in the trenches of the user community at iCIMS because he is responsible for managing the client renewal pipeline, user satisfaction, user advocacy, and maintaining visibility of the value proposition their services deliver.

I enjoyed this conversation because social media is still a widely misunderstood subject among SaaS and Cloud Service providers. Many see everything social as an unnecessary and noisy “distraction” that is a waste of resources and time. I understand their point of view because if they come from traditional software marketing, support, and sales environment,  they are part of a legacy that rarely focused on end-users or tried to foster communications among them. And if you’ve ever tried to sip from the Twitter fire hose, you can probably understand their discomfort with jumping on the band wagon.

We covered the many sides of communities in SaaS including:

• Inbound Marketing – Getting found by vertical and best practice communities while building up a presence for your brand and the services it provides.
• Marketing to the Converted – Retaining subscription renewals, up-selling, and evangelizing your existing end-users and the key stakeholders that drive client adoption.
• Product Management – The balancing act that comes from involving end-users in driving product development without crossing into crowd-sourcing and losing your strategic direction.
• Support - Leveraging the community to provide best practices and support while continuing to be strongly involved in providing assistance and guidance.

And finally – how a community relations director can keep from looking like a product shill, serve user needs, retain subscriptions keep the sales funnel full and have time to take off for vacation in a 24/7 product world.

I think the take away from this conversation was very interesting and I don’t want to spoil it for you – but we found that “being social” is a lot more hands-on and face-to-face than you might think. It really is still true you need to be balanced between social tools and more traditional face to face approaches than you might think.

Joining Jonathan on our panel was Jessie Kliza, the Business Development Director for Apprenda and Peter Cohen of SaaS Marketing Strategy Advisors, who also happens to be one of our fraternity of Haut Tech Irregulars.

Our Special Guest -

Jonathan Hyland, M.A., PHR – Client Relationship Director at iCIMS. Jonathan has a background in Industrial and Organizational Psychology, graduated with honors from Monmouth and finished his graduate work at Hofstra University. He started as an intern at Questus but moved up quickly when he came to iCIMS. He now carries responsibility for managing the client renewal pipeline and upsell opportunities, ensuring client satisfaction with internal advocacy, and the development of marketing materials covering the value proposition of the  iCIMS platform.  In that role, he works with user communities at all levels for iCIMS. You can find Jonathan most days on Twitter and read some of his thoughts on his jaHRd blog.

Our Panel –

Jesse Kliza – Director of Marketing at Apprenda, the creators of SaaSGrid, a distributed SaaS platform that eliminates the difficulties of building and delivering Software as a Service.  Prior to joining Apprenda, Jesse was Community Evangelist and Product Manager at SaaS ISV, Autotask.  Among Jesse’s many contributions while at Autotask, he was responsible for the creation and oversight of the Autotask Community  – which won a coveted ITSMA Marketing Excellence award in 2008. Jessie can be found on SaaSBlogs, Appenda’s best practice blog for the SaaS community and his Twitter feed.

For those who are not aware of SaaSGrid, it is a service that greatly reduces the barrier to entry for SaaS by overcoming significant technical hurdles like multi-tenancy and grid scalability, while at the same time providing “out of the box” application services like metering and monetization, billing and subscriber management, and much more. Scio is a Premier Development and Implementation Partner for SaaSGrid.

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.”

So – you can download the show,  you can subscribe to our feed on iTunes or use the widget below. And if you would like to comment here or catch me on Twitter – we’re always interested in extending the conversation.

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!

In Part 1 of this list we covered the first five points – so if you haven’t read that already, I encourage you to go and read that first. For everyone else – here’s the remaining five points in my hit parade:

6. Plan a yearly release cycle in conjunction with industry trade shows.

For marketing, product managers and developers with any experience in the software industry – this is a natural tendency. For the past 30 years, release schedules have rode the waves of industry events like clockwork. Because of the close association with end-users, a subscription renewal cycle which is frequently 30 days, and the “standards” set by industry leaders like Salesforce, Amazon, and Google – SaaS users expect a steady drip of improvements that have no set schedule. Waiting for some arbitrary “release date” is unnecessary and counterproductive. If the application is properly maintained and architected, the update will take place without any disruption to service.

Unlike upgrades to locally maintained applications – where IT departments had to schedule and plan for application upgrades and possible failures – those issues are now considered to be the domain of the service vendor. It has been outsourced – this is a core part of the service clients are paying for. Frankly – end users don’t care how it is done as long as there is no significant business disruption. Instead they are delighted to find a new feature that solves one of their problems – assuming all parts of the SaaS operation are meshed and working properly. The steady drip of improvement builds user loyalty and increases application “stickiness.”

7. Provide customized versions and features for specific customers.

In software development, this is known as “forking” your development or branching to produce a different, but concurrent, version of an application. Developers try to avoid it like the plague because it greatly increases risk – later changes may not be compatible with the customization done for a specific instance. In traditional installed software, with long release cycles, it was often done by system integrators or vendor professional services. It is an expensive practice that necessarily limits the ability of the customer installation to take the next version. So – they “sandbox” new versions and thoroughly test them before deployment. This may put them several months behind the release schedule of new versions, but it has always been considered a necessary evil in enterprise software deployment.

In SaaS, the tactical reasons for allowing individual instances and customer specific customization become operational nightmares. Now the steady flow of upgrades (point 6) becomes a significant cost issue for service maintenance. It requires more resources, planning, and risk. With the narrow margin of most SaaS operations, it can quickly become an issue that impacts reliability and profitability.

Proper SaaS product management provides two ways to get around this potential bump in the road:

• SaaS applications are architected to be configurable (rather than one-off customizations) to meet the demands of their market. Available configurations are consistent across the application and limited (if at all) only by feature bundling and pricing. Configurations are tested as a part of the normal development cycle without any special conditions. If a new customer requires a new element in configuration, product development evaluates the market and development effort required and makes a decision at the strategic level as to when and if the new configuration might be available. When it is completed – it is available to all clients and part of the standard application.
• If the customization would be to enable integration with other applications in the client portfolio – this is handled at the API level and possibly by external services (like Boomi) that can transform data for specific purposes. This separates the client side needs from the application and allows them to be “loosely coupled” instead of tightly integrated. Product development has to insure that the API remains consistent or at least clients with API integration are notified before critical changes – but beyond that – the service is available to all users consistently – not a limited few who have special needs that have to be evaluated individually.

8. Start with a free version to test the market.

This has been a common mistake by SaaS vendors – led by the many general consumer services available from companies like Google. Few vendors have the income of a Google and advertising-led income is really only possible for the most successful consumer applications.

Let’s say it clearly - The initial assumption of worth is equal to what you charge. If you charge nothing, you will get a lot of drive-by users who have no interest beyond trying to see what the service is all about. Taking input from free “hanger-ons” that have no intention of becoming paid subscribers is very dangerous. Where they want to lead you has nothing to do with profit and user retention at the subscribed end of the market.

That doesn’t mean a 30 day free trial is not a great way to onboard users initially. But – there still has to be a limitation and a stated worth. Users may decide it isn’t worth the price after trying for a few days. They will allow their test subscription to lapse and they will drop off. The rate of conversion from trial to subscribed becomes a clear indicator of the effectiveness of marketing (funnel formation) and product development (trial conversion and subscriber retention). It also doesn’t mean that “Freemium” packages can’t work – where the basic application is free but key services have a cost.

Pricing is a delicate dance between value received and money paid. In service offerings, the best case is always to provide more perceived value than the service costs. At worst, they can be roughly equal – but if they are out of balance to the cost side, subscriber retention will suffer greatly.

9. Build the richest, most complex offering for day one.

This approach is symptomatic of technical marketing and traditional software sales. For years, applications have been sold as technology with comparisons of feature lists. So, the natural tendency is to say – “We do it all! We’ve got all the bases covered!”

This approach leads to several issues in SaaS:

• Long, costly development cycles that produce a large feature set with no user-driven demand. How do we know the features we’re building are critical? What tells us the money and time spent will be returned in subscriptions? Go back to point 2 in this article. 80% of value is derived from 20% of features. There are always features that are necessary regardless of value, but as they rise, they increase cost and complexity for end-users.
• Developing new features into a very complex application becomes increasingly difficult over time. A smart SaaS vendor will generally break out potentially complex new capabilities into additional but separate services as Salesforce has done with Force.com. This keeps the core application focused and allows the new offering to “stand on its” own and seek its own audience.
• Complex applications require more time for users to become productive, training, and support. These are all costs, whether they are borne by the vendor or the client. They reduce adoption and put retention at risk. If the complexity is truly necessary it needs to be compartmentalized so that users can either take it on gradually or upgrade to “professional” versions when they are comfortable with basic functionality. Time to initial productivity with a service needs to be as near zero as possible.
• Complexity doesn’t sell itself. In fact – it drives people away. Think “Evolution – Not Revolution.”

10. Ignore change and agility.

Taking the sum of all the previous points, you should be able to see one thing stand out – A SaaS business is not your father’s software business. It is driven by change and renewal. It responds organically to market and user demands. It grows based on successful market adaption. I call this an agile business and so do many others. It is nothing less than a complete rethinking of how a business organization “works” at every level. It is both cultural and process-led.

This is not the Agile Manifesto – while still acknowledging it comes out of the same guiding principles. Putting a homily up in reception will not make it happen. Ignoring the issue will not make it go away. You can let the issue grind you down over time or you can accept it, plan for it and execute strategically.

So – that’s my list. What’s yours? What’s tops on your agenda?

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…

I really enjoy working with entrepreneurs – helping them flesh out their ideas and making them successful. But too often I have to ask them – “What is going to make someone look at your product? How will they find it?”

My theory: For SaaS products, marketing should not be an afterthought. Marketing is not a bolt-on for successful companies – it is part of their DNA.

Recently I’ve been working to enhance Scio’s assessment consulting for SaaS products. I’ve been going over past work with clients, proposals, document templates – all the chaff that builds up when you have a consulting practice. We’ve been gradually moving agile concepts deeper into our business practices and it was high time our consulting practice caught up. Sooner or later the shoemaker’s children should get shoes.

One of the great things about agile is it forces you to rethink your documentation and planning to make it more flexible, central, open and – just enough to meet the need. For consulting, it raises collaboration, customer ownership and lowers the image of the “pontificating consultant. ” And in that process of “rethinking” I realized we really hadn’t integrated marketing assessments into the process in the way we should. We certainly included assessments of marketing plans – but we didn’t clearly point out that marketing needs to be integrated into the product from the start.

For SaaS products there are several major market decisions that need to be made during the design process. They related to the product’s position in the market and how the product will be sold. Think of it this way – we say in journalism a good article needs to identify the “Who, What, When, Why and How.” The same is true in marketing. We need to identify:

• Who is going to buy and/or want (they are not always the same individual) the product? There is likely to be more than one “who” involved. In agile terms we call this the “persona.”
• What are they doing? When? Why? These are the contextual stories that tell us what is driving a prospective buyer or user to the product. For agilists – these are the epics – the larger stories that give context and meaning to the product and tell us what is happening around the user that makes them want to use it.
• How is a bit more complicated – it can be considered in terms of “how” a buyer or user finds the service or the product itself can be the enabling agent that provides the “how” a user does what they are trying to accomplish. In agile terms this is realized in user stories but for our purposes that is going deeper than we need. We can stop at the product or intermediary that gets us to the product being the answer to the how question.

That last point begins to bring up the main issue behind this discussion. SaaS applications are not in corporate data center silos. They are on the network we call the Internet. There are three primary things we do on the web: Communicate, seek information, and use services. A premise-based application can provide a limited amount of information from what is available to it within the boundaries of the premise. It can allow communication locally. It can provide services based on its logic and the resources available locally. Getting outside the boundaries means negotiating permissions and controls that are usually outside the application domain – so they don’t exist unless they are very specially configured.

Moving to SaaS suddenly opens up a wealth of opportunities. I came across an article about the basic hub and spoke decision just the other day from Geva Perry. He covers it in a lot more depth than I want to give it here – so I recommend you take a minute and read it if you are considering a SaaS product (or maybe wondering why yours isn’t bringing in the money you expected). The basic gist of it is this – you don’t want your application to be an island in the Internet. It should be a hub, a spoke or both but designing it as an island – as though it was still in that corporate data center – means leaving a lot of potential on the table.

Take Sales: Enabling the channel to add value to your offering is something we have always considered a standard approach in premise-based products. How often is it leveraged in SaaS applications? The leaders – Salesforce, Amazon, Google, Zoho, LinkedIn – have all added some sort of partner program that allows other companies to build applications that add value to their products. The channel could also be an information resource that is focused on your market or a business consultancy or ….But frankly, it isn’t considered enough.

In the case of a product like Salesforce – companies can build their applications using Force.com and sell them through the AppExchange. They can also use the Salesforce API and develop their application externally. They can build their application to expand Salesforce functionality – or not. Each one of these opportunities represents a different potential revenue stream to Salesforce that their sales team isn’t selling directly, that brings in money, and possibly brings more subscribers to their core application.

I’ve worked on a career application that used a strategy of leveraging university job counseling and alumni members as the starting point for new subscribers. They received a subscription as a part of the service or their alumni membership which could be converted to a personal subscription at any time. What better time to target prospects for career management than in their last years in college or when the are just joining the workforce? All that was necessary for the schools was to provide customization tools to allow university administrators to embed the service in their websites.

Each one of these cases exposes a basic idea – that the marketing of these products does not have to rely entirely on external media. It can leverage communities, value chains, social networking, marketplaces – a wealth of opportunities by building them in and integrating them into the core application.

Of course, the reality is everyone has limitations. You can’t build everything you would like to have in your service on day one. Time and cost are the limiting factors in most cases. But even with unlimited amounts of each – a successful launch means limiting your application to the amount of complexity you can reasonably test before you let the product “go into the wild” – the final test of customer-facing performance. Taking this into account, you will need to prioritize and set some parts of the application for a later version. If you develop using modern patterns, automated testing and agile techniques – your development team will be coding knowing what is “yet to come” and where the hooks need to be available to make it easier when that time comes.

But it can be done. Don’t make your marketing plan an afterthought or, come to think of it, your product may end up that way itself…

Late last week there was a lot of buzz around the announcement that the president and chief executive at Salesforce, Steve Cakebread, and two of his top sales executives had left the company. The news has generated blog entries with provocative titles (Is the Bloom Off the SaaS Rose? by Jeff Kaplan) and several sober assessments about the general effect the down economy is having on IT spending.

It is interesting to me that what didn’t lead the articles was a clear assessment of the metrics of a Software as a Service business and how that might be impacting Salesforce and other SaaS-based companies going after the enterprise market in this economy. The metrics of any business model are arguably “entertaining reading” for only a very limited number of people to be sure. But it is a critical subject for companies with new SaaS products or ISVs moving to SaaS to understand and be ready to measure from day one of operations.

First, let’s talk a little about marketing SaaS products. Outside of the enterprise market, SaaS products are – and should be – sold across the Internet for the most part. If your users are going to access your product across the Internet, if they don’t have large investments in existing products and infrastructure – it makes sense to leverage the network “where they are” to make sales. Of course, just like any other software company, SaaS ISV’s demonstrate at trade shows, use targeted email, and ads in magazines tied to their verticals. But with the increase in social media outlets and related marketing, there are many new doors opening to reach prospective customers in the virtual world of the Internet.

Early in its growth pattern, Salesforce used these channels quite well as it matured its product. With increasing success, more investment came and along with it – the desire to “dominate” the market. To do this, a great deal more money was spent on marketing and on bringing in a sales team that could drive “enterprise sales.” In a licensed model, the “traditional” model for enterprise software, the license fee is a large capital expenditure the customer sees as providing “future benefits.” Enterprise software sales executives are used to dealing with the objections to the high price and use various strategies to bring down the initial “bite” and trade it against maintenance fees, services and add-ons that would otherwise raise the price.

When a company like Salesforce first approaches the enterprise market, the need to “horse trade” is low. The success they find is based on prospects that may be reaching the “sunset” for their current license investment, need to increase their license commitment because of deployment increases in seats or servers or to reach newly acquired offices in other locations. These prospects are facing capital outlays for new licenses, hardware and support, against which the flexible model of a SaaS product can be persuasive. When that “low hanging fruit” is exhausted however, the cost of customer acquisition begins to rise steeply. Prospects with two to three years left on their license, a relatively new infrastructure and stable staff have relatively little impetus to “drop” their investments for a new product and perhaps risky technology and in this economy even less interest in pushing a new initiative through finance. They take more time to make a decision (lengthening the sales cycle), require more “due diligence” (raising the sales, sales support and marketing costs), and will likely counter offer with a smaller commitment for seats or subscription term to “test the waters” (lowering committed revenue). If you are a sales team engaged in a strategy of market domination, waiting until the prospect’s pain becomes more pressing may not be an option.

Because of the way a SaaS company receives its income, an expensive market domination play can be a risky strategy. To understand that – we need to dive into SaaS metrics. There are several accepted operational measures that a SaaS ISV should be aware of:

• Committed Monthly Recurring Revenue (CMRR) – Also referred to as the Monthly Committed Recurring Revenue (MCRR). The total of committed subscriptions for the period.
• Retention Rate (RR) – Also known as Churn. The percent of customers that renew their subscription at the end of the term. This includes “automatic” renewals, even though they may be a separate class in some implementations because they can always “opt-out” – although the tendency is less than in manual renewal systems.
• In Trial - The number of prospects (not users in a company or organization subscription model) subscribed in a trial period. SaaS ISVs offering trial subscriptions should also track Average Users per Customer during trial (to answer: how large are the trial prospects? Do they cover a full Line of Business? Might they need a Sales Engineer to help them evaluate?). The Average Trial Period is also of interest and depending on the sales model can be different from Time to Close.
• Average Deal Size (ADS) or the Average Revenue Per Client (ARPC)- the average Committed Monthly Recurring Revenue (CMRR) from a customer.
• Average Revenue Per User (ARPU)- Like the ARPC but broken down per user instead of per client. When the size of client implementations vary broadly across your customer base, this helps to establish your average user load and revenue. The impact of this metric depends on the subscription or revenue model of the application.
• Time to Close – The time it takes for an identified prospect to become a subscribing customer. This can be easily monitored for trial customers but requires CRM to monitor for a sales team.
• Close Rate – The percentage of In Trial customers that convert to subscribers. This can be aggregated with sales team prospects from CRM but it wise to also follow it separately to gauge pure web-based marketing and sales.
• Cost to Maintain (CtM) – The cost of services required to maintain customer instances. This should include hosting charges, hardware and software renewal, support, staff operations and outside services required to maintain customer instances outside of sales, marketing, R&D, and product development. This is an important metric because it also provides a window into Contingency Costs.
• Cost to Acquire (CtA) – The average of the cost of sales and marketing activities in a period divided by the number of customers acquired in the following period. The period is usually adapted from the Time to Close so that costs and the customer acquisition relationships are realistic.
• Customer Acquisition Cost Ratio (CAC) – A key indicator of how long it will take a customer to “payback” their Cost to Acquire. The ratio is developed by dividing the Annualized Net Gross Margin added during a quarter by sales and marketing costs of the previous quarter. Example: CAC Ratio (Q408) = [GM(Q408)-GM(Q308)]*4 Sales & Marketing Costs (Q308).
• Customer Lifetime Value Ratio (CLV) – The net present value of Annual Recurring Revenue from a customer less the Cost to Maintain and Cost to Acquire. A lifetime “horizon” needs to be assumed – usually a 3-5 year window is used unless the company has been in business long enough to make assumptions based on Churn.
• Software to Services Ratio – In a subscription only model, professional services may supplement income. In a mixed model, subscriptions can be supplemented with “value-add” services that can be transaction or on-demand based and professional services. In either case, this is a ratio of subscription revenue to services and is important when there is a low margin remaining after Cost to Maintain and Cost to Acquire are taken out. A high services ratio can compensate for the low margin if the services are considered to be high value by your customers and in high demand.
• Largest Customer % – Knowing the percentage of gross income your largest customer provides helps to assess risk. In a new company or a vertically-based SaaS, it might be also wise to assess the percentage of gross income provided by your top ten (largest) customers. The point is to assess your risk if they drop their subscription and leave you in a position of supporting sales, marketing and operations with too low a margin.

If reviewing that list made you feel like your head is about to explode – don’t worry – the next article in this series will be SaaSoNomics 102 and I’ll cover some practical examples of these metrics.

But let’s go back to Salesforce – why is it I don’t feel like the departure of their top executives is a clear indication the sky is failing on the SaaS business model? Because they have been pursing enterprise sales. The easy sales have been made, the length of time to acquire new customers and the cost of sales is rising. This means that assessing their Customer Acquisition Cost (CAC) and Customer Lifetime Value Ratios (CLV) against their Retention Ratio is likely to show their new customers will not generate a profit in a reasonable timeframe. That means a change in strategy is required to maintain profitability. Knowing that, knowing how to assess your business metrics and change direction in response is key to running a SaaS business and something we will explore with some practical examples in our next article in this series. Stay Tuned!

The number of negative predictions for the future of SaaS and Cloud Computing have reached a crescendo in recent weeks. There has also been a significant push back from both pundits and bloggers “in the field.” Is SaaS and cloud computing just more hype? Has it reached the level of being a “must consider” alternative?

Phil Wainwright summed up my reaction to the many statements, articles and blog posts that have greeted 2009 with negative reviews of SaaS and Cloud Computing:

“…being attacked is always better than being ignored. After years of indifference to SaaS, the conventional software world has suddenly woken up to the threat and started attacking it in the hope it will all go away.”

The most out spoken critics are among the leaders of the largest software companies. Bill McDermott, SAP America’s CEO, Larry Ellison, Oracle’s CEO and Lawson’s CEO Harry Debes have all made a point of giving some unusually negative assessments. The desperation driving them seemed to be particularly apparent in this statement from Harry Debes:

“Getting signed up as a SaaS customer is fast, but getting out is just as fast. Whereas traditional software is like cocaine–you’re hooked. It’s too difficult and expensive to switch providers once you’ve invested in one. If it were easier to jump ship, a lot of people would’ve hit the eject button on SAP a long time ago.”

I don’t know how Lawson markets to its enterprise customers, but I don’t think they would take the drug user analogy too well. It is true however. Investments in hardware, data center infrastructure, IT staff, process change, integration and software licenses are a barrier to exit for many enterprise customers. But in this economy – does that mean it won’t happen? I doubt it and that isn’t even the biggest objection to his statement. What about the millions of SMB (and Debes was quoted as saying for Lawson, anything under $50 million is SMB) companies that have no desire to invest in additional infrastructure or skilled IT staff? Will they pass up the benefits of a good product that doesn’t require the capital outlay? What about the “line of business” (LOB) units that have limited budgets and no desire to engage their corporate IT to install an application for 20 to 50 seats?

He had one other comment that bothered me greatly. He said Lawson had started a SaaS application some years ago and then “did the math” – finding it would “be 10 years before we made any money!” I have to ask – what were you building that would cost so much? Did you consider leveraging any tools or frameworks that might lower the development cost? I am sure if you were trying to reproduce all the functionality of SAP in one application as an example, it would be a huge undertaking. But if you were to go the route of NetSuite and modularize your approach, it should never reach a level that requires that much investment before you have a strong product for release. A poor choice for the initial feature set is not a case strong enough to proclaim all SaaS products are doomed to failure.

The recent system-wide failure at Salesforce has spawned many comments that it was the sign that SaaS and cloud-computing projects were about to sink. I enjoyed JP Seabury’s write-up on Force Monkey. His account of how he had built a simple application to access their local copy of their Salesforce data was a good example of exactly the sort of business contingency planning that needs to be done regardless of where an application is deployed. And his justification for depending on Salesforce rather than his own resources was spot on:

“When the Salesforce.com outage started, dozens of IT engineers jumped into action, working to first isolate the problem and correct it. In the aftermath, today and for the rest of the week, dozens of technical teams will be working to understand what went wrong, how it went wrong, and what they can do to prevent it from happening again.”

“The best part? None of those people are on my company’s payroll. It’s a good thing — I couldn’t afford that many IT and support staff. Yet I am very thankful that they’re on my “cloud”, helping me run my business. I wouldn’t be able to administer such an incredible CRM tool without their help.”

His account goes further to contrast that experience with their local problems during a four day ice storm on the East coast – during which their sales team continued to operate remotely because Salesforce was available regardless of their internal problems. For his company – the benefits of using a strong SaaS application have far outweighed their risks.

During the current recession, vendor viability has also been a concern. Regardless of the benefits of SaaS, if business spending is reduced, the uptake of new products will also be reduced. No ISV can guarantee they will always be in business, but Vinnie Mirchandani offered some best practices that should be adopted by vendors and required by customers regardless of the economic situation. With proper consideration and mitigation, there is no more risk in a SaaS company disappearing than a traditional ISV on a licensed model. In each case a failure will have consequences that need to have mitigations in place from the start. But as Frank Scavo points out - there are some sales teams for SaaS companies that are spreading their own form of FUD (fear, uncertainty and doubt) to retain customers. If you have strong agreements that make the mitigation measures clear up front – as features – both customers and vendors are on a better footing from the start.

So, in the long run – I’m with Jeff Kaplan – a lot of these idea are just silly – or perhaps intentionally misleading when they are voiced by CEOs of traditional vendors. There is no reason to believe that either the subscription model or Internet-based service delivery are going to go away. In fact, there is every reason to believe that they will only become a more important alternative as we go forward.

Useful? Copy, paste and Tweet It!

FUD Rains on SaaS http://bit.ly/x2aw

We don’t often “push” our own services here, we see our mission on Haut Tec to be a part of the conversation around Cloud Computing and software technologies in general. But, I’m excited to say – today’s announcement is one of the exceptions:

As a part of their continued efforts to bring value to their customers, Scio Consulting and Apprenda have announced a strategic partnership to offer enablement services for software companies looking to bring their products to the on-demand business model rapidly and efficiently by using Apprenda’s SaaSGrid™, a Software-as-a-Service (SaaS) delivery platform.

SaaSGrid drastically slashes time to market for independent software vendors (ISVs) by automatically weaving a SaaS architecture and business functionality into their non-SaaS web applications, while providing significant long-term value via web-based application management capabilities.

“Essentially, we’ve done for on-demand software development what the operating system did for desktop software development. We’ve created a cloud operating system for SaaS, which provides a new layer of abstraction that takes the burden of creating SaaS-specific technology, architecture and business components off of ISVs shoulders,” said Apprenda’s CEO, Sinclair Schuller.

ISVs that choose SaaSGrid as a foundation shave off massive amounts of development time and capital requirements that would have previously been allocated to SaaS delivery intricacies. This allows ISVs to bring their solutions to market faster than ever before, utilizing SaaSGrid’s out-of-the-box functionality.

SaaSGrid's zero effort multi-tenancy isolates your customers by handling data partitioning, request routing, and authorization security as part of the package.

“It is a pleasure to partner with Scio, a company that shares our enthusiasm and vision of an on-demand future,” said Sinclair Schuller. “Software companies that want to create new SaaS offerings often need assistance with their business and product strategies, with developing their SaaS applications, or with modifying the code of an existing on-premise application to move it to SaaS. Our relationship with Scio enables us to help customers more easily obtain such services and make a smooth transition to SaaS with SaaSGrid.”

SaaSGrid has been evaluated by Scio Consulting and found to be an excellent tool for reducing costs and time to market for their ISV customers.

“Scio has been developing custom SaaS applications for years utilizing .NET and open source technologies . Using Agile practices and our Nearshore Development Center in Morelia, Mexico, we are typically able to deliver new SaaS applications in 4-9 months. Now with SaaSGrid, we will be able to build SaaS applications for our clients faster and more economically than ever before,” states Luis Aburto, CEO of Scio Consulting.

Rather than requiring the use of a proprietary technology stack, SaaSGrid applications are built using the industry-hardened Microsoft .NET stack and the SaaSGrid SDK. The SDK hooks into Microsoft’s Visual Studio, and provides an integrated development environment that allows a software company to write business code, user interfaces, and databases locally by using popular .NET languages like C#.

Update:

If you would like to hear an in depth discussion of SaaSGrid – Listen to the podcast Paul Miller of Nodalities did with Apprenda CEO Sinclair Schuller.

Useful? Copy, paste and Tweet it!

Scio Consulting Partners with Apprenda for Rapid SaaS Product Enablement http://bit.ly/huw5