Category Archives: Business Model

A Case Study – Creating a VAR Development Program

This blog entry continues on my first blog entry where I concluded that the channel does not work for the ISV, it is the ISV that has to ensure that the channel has the tools to become successful with the solution itself.

In my second blog entry I highlighted a case study of a successful ISV that was able to grow its business by doing the channel development by identifying an impactful approach where the VAR channel felt that it was a win-win situation for both sides.

In this blog entry I am high lightening the VAR development program (Phase 1) that SolidWorks created for its channel and as I stated in my previous blog, this program was almost like a mini-MBA where the ISV wanted to facilitate and help its VAR channel to run its business more effectively. The program that David Skok highlights in his blog entry as phase 1 of the development program is divided into two main areas: Business Management and Sales Management.

VAR Channel Program-001

From the picture above, the channel assessment was reviewed from these two perspectives and each of these perspectives are divided into smaller components that have relevance specifically when running a VAR business.

Cash is king as they say and I have also experienced this as an entrepreneur. What ISVs tend to forget is that somebody has to fund the activity to build the funnel of the solution that the ISV wants to sell. So lets review the typical steps that we expect to happen when an ISV signs up new channel partner:

  • The ISV wants to ramp up the activities immediately once the deal is signed, which means that VAR technical and sales team needs to be trained and educated of the intransiences of the product and learn how to take objections from the target prospect market segment.
  • The ISV expect the VAR channel marketing team to dedicate resources to start building the funnel and sometimes forgetting that there are other products that they might have in their portfolio.
  • The ISV Channel Account Manager puts effort in getting things going as he/she is the one that will have the pressure of getting first deals going and to ensure that he/she meets the budget.

With all of the effort that has been put into the joint effort, the VAR finally signs its first deal and now everybody can be happy. On top of this, the deal is very sizable and this makes the VAR a bit nervous as there are some financial risks that it now has to carry as it carries the paper with the end user organization.

The project starts, everybody is working hard on getting the client happy but sudden and unexpected issues comes up in the implementation. The customer tells the VAR that it is unacceptable and they will not pay until the software has been fixed. The VAR tells the customer that they do not have the means to fix it as it is the ISV that carries that responsibility. The customer tells the VAR that that is not their problem, the responsibility is with the VAR as that is whom they bought the solution from.

As the invoicing relationship of the solution delivery is between the VAR and the end user organization, the VAR runs into issues as an invoice has already been issued from the ISV and they want to get paid.  This puts the VAR management to sweat and now they really understand the consequences of this and need to do something about it.  The ISV wants to get paid, but the channel partner has not got paid yet. Worse than this, the software included bugs that the VAR can’t do anything about and has to wait for a fix. The ISV still wants to get paid, no matter what as its view is that this issue has nothing to do with them. I am sure you get the scoop of the vicious circle.

If the ISV is reasonable, they will work with the VAR and the end user customer to get it right, but unfortunately I have seen cases where the VAR has really run into a wall. I can’t imagine how that feels as I run my own business every day and have to consider risks and rewards when conducting the business. In large organizations with huge cash piles, this might not be a problem, but for the majority of ISVs, SIs and MSPs, this could be a huge issue.

The scenario above describes some of the areas where the VAR has to pay special attention when running its business. The number one in business management side is cash flow and how to manage it when dealing with ISVs and purchase management overall. I have run companies with high growth and one of the most pressing issue seems always be cash flow. People want growth, but with growth you need cash flow. Sales in your books does not mean that you have money in your bank account. Having lots of receivables might feel good, but you can’t feed your family with receivables.

The second area is “Sales Capacity” where typically small VARs become the victims of their own success. Skok concludes that a typical successful VAR is where the business owner is number one in sales, but one person does not scale up to grow the company. There needs to be more than one to scale the business. If the owner becomes the gatekeeper, then that becomes the bottleneck for the growth for both the VAR and the ISV.  What a VAR needs is a strong sales manager that can scale the sales, follow and create processes and the owners should keep away from that (my observation).

Also, what is typically undervalued among VARs and ISVs is market research and what sales people tend to use as an excuse for poor sales is that the “market segment is saturated’. Good research includes information about market size, market share, historic customer growth rates and sales coverage etc..

According to Skok, one of the most difficult task that VARs are struggling with is the requitement. I can really believe this. The key for success is to build an interview process to identify the right candidates and even if you become good at this, you will still fail. I have.

What an ISV might see with its channel is that VARs are hiring new employees, but there are more leaving the company that coming in. So what will happen is that the VAR has new people that are learning “the ropes” and then the ones that have learned are leaving for different reasons. The VAR ends up having a situation where the skills don’t meet the demand of the market.

One key thing that is often ignored is to ensure that the employees have a good view of their professional development,  like sales people having strong  product training, presentation training, and  sales management training.

And finally, and probably one of the most difficult tasks: how to manage and review the pipeline that everybody presents to the management. How should the VAR and ISV ensure consistency in the pipeline? One of the key things for both ISV and VAR is to create a standardized view on the pipeline, not based on each and every sales persons personal definition which is typically biased to his/her own preferences.

The question is what kind of deliverables can an ISV and VAR expect from both Business and Sales Management exercise? The way Skok defines them is in following way:

VAR Channel Program-002

It is obvious that each one of these need to be worked on and each ISV will have to estimate how much to put effort into this exercise. Also, what something might work for one organization, could be very different for another.

The next phase of this case study I will discuss about the way that the case study ISV segmented and categorized its VARs and their ability to grow. Stay tuned for more.

How to become successful with your Channel–a case study to learn from?

In my yesterday’s blog entry, I gave a few hints of channel development and what kind of things the software vendors should avoid.

Today, I thought to share some perspectives on a case study that David Skok gives in his excellent blog entry.  Like in my previous blog entry, I will give my perspective on the findings of this case study.

The case study software company is SolidWorks and this company is specifically known within modeling for mechanical design. This company grew rapidly and one of the key reasons was an effective and well-managed VAR channel. According to the blog, the success of the channel was based on three distinctive phases:

  1. Hiring an executive that had been part of the channel in the past, so this person really understood the channel and how a VAR business works.
  2. Understanding that the success of SolidWorks
  3. Realizing that the VAR channel as an un-optimized  resource and how decide that it was worthwhile for SolidWorks to educate its channel on business skills. This meant every aspect of the business, almost like a mini-MBA

During the spring/summer 2012 I did some research in the VAR/MSP channel and one of the findings was that a key obstacle for many VARs and MSPs specifically in moving the cloud business is lack of expertise and the business model was seen to be unclear like can be seen in following picture (Source: CTTA 2012):

Obstacles in moving to cloud-2012

The latter is specifically relevant to the discussion of SolidWorks and what they did to make the channel successful. What happened in the case of SolidWorks was that the channel account teams became business mentors for the VARs and educating them to run a better business. In retrospect, I think this is exactly what ConnectWise CEO Arnie Bellini is trying to do with its resellers in its annual User Group Meeting IT Nation in the beautiful Orlando, Florida in November 2012.

He even brought in my favorite author Jim Collins that has written many bestselling business books and the latest book “Great by Choice: Uncertainty, Chaos, and Luck—Why Some Thrive Despite Them All” was given to all conference attendees.

I had the opportunity to hear Jim Collins keynote and I think it was one of the best speeches I have heard in my life. He brought up things in an interesting way and without every loosing the audience in the session.

In the next few blog entries, I will review what a good VAR channel program should look like and what kind of VAR development program did SolidWorks have to run its VAR business. I will also give my own add to this by looking it from a Business Model Canvas perspective which we use every day for everything we analyze in respect to Business Models. Stay tuned for more!

The Channel does not work for you, you work for the Channel

pentagons and negative stars - CPBuilding a channel is not an easy task and there are many things what one has to think about when building one. I have had the pleasure to building channels for more than 20 years in enterprise software space, specifically in business intelligence,  collaboration, document management and integration software.

Today, when doing some preparation work for a channel related gig, I found an amazing link of a case that describes a successful channel development initiative and also some of the common mistakes that software vendors do.  The author of this article (David Skok from Matrix Partners) is definitely an authority in many areas (specifically SaaS related things). He lists a few very important points for software vendors to remember and I am now listing them here with some additional comments based on my own experience:

  • You (ISV) have to figure out the sales model first and then using this to teach your channel. I have heard many naïve comments from ISVs where the management explain that “we don’t have to do anything, the channel will take care of that…” Well.. I have not experienced this in my 20 years…..
  • Building a channel takes long time and ISVs forget that the channel has different priorities to what the ISVs have. The channel is focusing on products that are paying the bills and if you have not been able to demonstrate your capabilities to sell, why would they want to take the risk with you? I will never forget when a good friend of mine in California asked me once when I had become a CEO for a software company in the US and recently emigrated from Europe (from from a technology role). He asked me: “ How many have you Petri sold yet…. Call me when you have some stories to tell…”. I closed a few deals, called him and he was a man of his word. We closed large deals together during our collaboration. I had to show my friend that I could sell myself and show by example how enterprises would buy my BI solution.
  • Resellers need ongoing education on your solution, how to handle objections and how to differentiate your solution from the fifty-nine others on the market. You will have to provide marketing material, PowerPoint decks, PDF White Papers etc. And please do not say that there is no competition for your product. Give me 2 minutes and I will list 20 for you….
  • Do not expect your resellers to do lots of marketing, because they expect you to participate and expect you to pass some leads as well. You are expected to help in the channel demand generation efforts by working together with your channel partners.
  • Try to identify a pre-existing channel that supports your solution or your solution can be sold as an add-on. Business Intelligence is a good example where you can sell a collaboration solution as part of the value-added delivery. When you do this, you have to customize your messaging in a way where the channel partner realizes that that your solution together with the other solution is more than 1+1, it is in fact 1+1=3.
  • When ISVs build a channel and have an existing direct sales model as well, there will always be conflicts between the channel and the direct sales force. This can’t be avoided and if the ISV is committed to the channel, the channel will always come first. It is not easy and there are some rules that the software vendor has to apply. These rules will have to be emphasized from the top management of the company. Skok also states that one should expect the direct sales execs have an issue in moving to the channel sales model. Channel people know that with good channel management and right type of partners, the channel will give much higher leverage than trying to grow with direct sales.

These are some of the statements flavored by my own experience and I could not agree more with Skok on these. The good news according to Skok is that with the “right channel, the right people, good product/market fit and with lots of patience, the channel sales model can be one of the most profitable business models.” I echo with this!

Stay tuned for more in this topic and love to talk about it as I happen to have million different scenarios that I have been exposed to.

photo by: origami joel

The App Economy – How should we view app monetization?

The blogosphere is all about apps and how different ecosystems compete for the eyeballs of these and the money of course. You might still remember the the news when a far app pulled as much as $10,000/day in revenue but since then there is tens of similar applications on the marketplace. This started a trend where people left their well-paid jobs to chase their dream of creating apps and living a life without pressures. The growth of app economy is one of the most promising trends, but people/organizations that want to make real money of it, need to include some risk management into it as well. The app industry has become similar to film industry where relatively few people make money and the ones that make, are hugely successful like Angry Birds phenomenon from Finland.

One might of course ask oneself is whether this is a shift in our society and how work is performed. according to Erik Brynjolfsson (director of the M.I.T. Center of digital business), “technology is always destroying jobs and always creating jobs, but in recent years the destruction has been happening faster than the creation”. There is no question that technology is creating new jobs and apps can be part of this opportunity as can be seen in many of the reports that have studied this trend towards “app economy”.

What I have not seen many discussions around is how the app economy is linked with the enterprise software business. I have researched around this and identified the “dimensions” that are typically linked to the app business, but not that much is said how established software vendors should view this space and how these vendors can make a entry to the app space in a way that makes sense and where there is also a sustainable economical model.

So, the question that we should ask ourselves is how much of the app business is truly geared towards the consumer business and how much of this will gradually move into enterprise business? Should software vendors keep the app business in their plans when building enterprise solutions specifically using the cloud? If they should keep this in mind, what kind of pricing should the ISV use? Maybe free as the real money comes from the enterprise solution and not the app that accesses it? As you can see, it is not that clear and my own experience when working with both small and large enterprises, the app business hardly ever comes up in discussions. I am convinced that this will change and it will change very quickly. One of the drivers will be Windows 8 and Windows Phone 8 developers that will create solutions that will be based on app technology and not on traditional desktop app architectural model even if these will be able to run in Windows 8 Pro environment.

Another valid question that we need to ask ourselves is whether app economy should be see purely from mobile app development perspective or should we view it from a perspective where the device is just the means to get to what you want and the backend (typically the cloud) is the one that provides the services and brokers the interaction between different services. Shouldn’t we in fact be talking about services economy instead where organizations build apps to consume and combine information from different sources using different SOA interfaces that organizations/developers have exposed to the world. Isn’t this what we have always dreamt about?

NokiaExpressI downloaded today a Windows Phone 8 app (Nokia Xpress) to my shiny Nokia Lumia 920 and this app really demonstrates where things are going. After having installed the app, it asked me whether it can use location information (which most apps want to use), but what really made me to think about the future of apps is that developers really have to think “outside the box” on when developing apps. The thing with this Nokia Xpress app is that it enables users to store and read articles on your phone (locally) so when you travel, you do not have to use expensive data roaming. I know.. there are many of these apps from before, but what this app has specifically thought of is to really monitory and minimize data usage and provide a combination of technology such as Microsoft SkyDrive technology to store videos and images without having to use the data plan. Why is this relevant to me? Just this week, my son’s data plan was going over the limit and I found out that it was all about video streaming and 2 gig data plan does not cope well with this.

The topic of “app economy” is very interesting to me as researcher, but also as practitioner. A recent paper written by Dr. Michael Mandel and Judith Scherer (commission by CTIA (The Wireless Association) and Application Developers Alliance provides an interesting view on the app economy. According to Mandel, the entire “App Economy” was coming to use in early 2009 and was popularized by a cover story run by BusinessWeek in November 2009.

The way that Dr. Michael Mandel describes App Economy in his February 2012 report resonates well with what I have educated my customers in respect to ecosystems:

“ App Economy is a collection of interlocking innovative ecosystems”. Each ecosystem consists of a core company, which creates and maintains a platform and an app marketplace, plus a small and large companies that produce apps and/or mobile devices  for that platform. Businesses can belong to multiple ecosystems and usually do”.

There is no question in my mind that this topic is relevant to anybody that works in the software industry and it is fascinating to see how this evolves with time and what kind of new companies will rise to take advantage of this.

If you work in the Microsoft ecosystem, I highly encourage you to read the article “Microsoft’s cloud vision: Why Azure is the linchpin of the firm’s new devices and services strategy”. Another great article from Information-Management.com that predicts Enterprise Apps to go mobile big time and that money apps will move to the cloud. The article lists quite a few things that are very interesting and I encourage you to read that article as well.

Stay tuned for more, there will be more to come on my research on different topics and this app economy being one of them!

Why software is still relevant and even more so going forward

When I reflect my past more than 20 years, I have been fortunate enough to be part of the software industry on a global level. First 10 years I spent in Europe working for software companies and the past 15 years I have lived and worked in the US as entrepreneur helping out software companies both domestically and internationally to expand their business.

I happened to run into a blog entry from TechCrunch by Jon Evans where he reflects on Journalism and how everything has become tech. The reference he makes is to a blog entry with the topic Software is eating the world  and is written by  Marc Andreessen whom most of us know already from the Netscape time. Marc Andreesseen is co-founder and general partner in a very well known venture capital company Andreeseen Horowitz with investments in many well known companies such as Facebook, Groupon, Twitter and many more

When you read the article from Andreessen, there are a few things that confirms some of the things that I have pondering on and also telling my software vendor clients in discussions. Software has not only become a necessity, it has become a must even for traditional hardware companies that one would not think that they need to ponder about software. This trend has been going on for a few years and we see this happening in the for example auto industry and what makes things even more exciting is that cloud technology is now part of this formula of success. Some mature industries are using new cloud technologies to achieve competitive edge towards the rest of the industry.

There are software companies such as MetaCase that will benefit of this trend. This software development tools company is the leading domain-specific modeling software company in the world that has very impressive clients working on embedded software solutions in different industries, including mobility and auto industry. The development environment MetaEdit+ enables organizations to create software product lines more effectively and also with higher quality.

Andreessen claims that we are in the midst of a huge and dramatic technological and economic shift where software companies are poised to take over a large part of the economy. It is easy to see this happening for real. Just think about how insurance companies and financial industry are able to use the cloud to execute heavy-duty risk calculations by submitting the request to the cloud and the only question that the cloud will ask is how much time it can take. Following picture shows pretty nicely how a company with pre-existing infrastructure investment (Datacenter) should view when considering a PaaS environment (Platform-as-a-Service) and in the figure we are referring to Windows Azure.

Azure vs. datacenter

The more capacity is allocated for the calculation, the more it will cost but this cost could easily be justified by opportunities to make more money due to time savings. In the picture above, it is easy to see that there will be a point in time when your own datacenter just does not scale where it needs to scale and that is why solutions/platforms such as Windows Azure will come to the play. This is also why we have to understand that new technologies such as cloud will bring new innovations to the market and this will definitely reflect on the valuations of these companies.

Andreessen gives lots of software related examples from different industries and I have had the luxury to work with many new an innovative (small and large) software companies that are now making this change in a very rapid pace. There will be lots of losers in this game as well. These will be the ones that feel that they already “own” the market and suddenly realize that smaller and more nimble players suddenly take the market and run with it.

The message that I want to send with this blog entry is to really emphasize that ignoring the change that is happening due to multiple factors such as mobility and cloud is probably one of the biggest mistakes that one can make as software leader. I encourage each one of you to do some due diligence in your own operations and answer to this simple question: “ will I still be relevant in 5 years”. If the answer is no, then you might have bigger issues on your hands than just the cloud transformation.

A tale of “me too” kind of innovation: RIM to launch music service for BlackBerry

It is sad to read about Research in Motion (RIM) attempt to become hip again. I have been a client for RIM for the past few years for one reason: AT&T provides me with an unlimited data plan (worldwide) and that is hard to beat. I have not been able to switch to any other phones as I really need my phone when globetrotting and I am reluctant to spend hundreds of dollars each month for roaming.

As a Blackberry user, I would have appreciated RIM to focus on getting a real phone on the market that is competitive and I can still keep my unlimited data plan but I guess nothing lasts forever and I need to move on and change to a new operating system and vendor and deal with the roaming. I can’t be left behind in innovation and usability and when you look at the current smart phone market, it is growing and advancing with huge steps every month. My current phone (BlackBerry Torch) has a lackluster touch screen that does not react to my fingers the way one would expect. I have also had to rebuild the phone at least 10 times from scratch due to applications that have broken the phone. One would think that cannot be possible, but it is and I have seen it many times. I even had to buy a software tool to “self-manage” the rebuilding as AT&T refuses to rebuild the phone and forces you to buy the phone again if the warranty is over. Not something I enjoy doing. Once returning from Europe I put my phone on and it went dead and by discussing with AT&T service they said to buy it again.

The latest attempt from RIM was to publish BBM Music store that enables BlackBerry users to stream 50 songs using BlackBerry Messenger. Why on earth would I want to do that and wasn’t this something that Nokia already failed in and decided to kill? If I were RIM, I would focus purely on getting new phones on the market and focusing on the youth as they are the ones that either make the platform or break it. Another group are the developers that now are at crossroads as they have to decide what to do to a dying operating system as RIM is moving to the new QNX operating system that they acquired by RIM.

My personal opinion is that RIM needs to focus on having applications that support music services such as Spotify, Rhapsody etc. and forget about things that are outside their own core competence areas. This tale is also something that the software/IT industry keeps seeing all over again: once you are the top dog, you will eventually come down due to many reasons. We have seen this happen with IBM, Nokia and many other players. We need to remember to reinvent ourselves on regular basis and keep working in a humble way. Becoming arrogant and believing in something that is not true anymore can be lethal in the long run. When somebody becomes market leader, it always causes people/employees to think that this stays status quo even in the future. This never happens.

Where does this leave me as a smart phone user? In my mind there are only three players left in the smart phone field: Windows Phone 7 from Microsoft, Android from Google and iPhone from Apple. With these three choices the follow-up decision is to select the hardware manufacturer and that is where the race is going on with Nokia, HTC, Samsung, Dell etc. on the WP7 field and obviously the same thing with Google Android devices but with iPhone with only one manufacturer being Apple.

Cloud ISV: make sure you understand your ecosystem play – example of Intuit and Microsoft collaboration on software platforms to create a foundation for solution developers

I have written several times in my blogs about ecosystems and the role that ecosystems play. I recently run into an interesting article in the Redmond ChannelPartner with the header “Intuit Extends Cloud Pact with Microsoft”. As I am working with Microsoft ecosystem every single working day, I became interested what the article was all about. Intuit has been building a Partner Platform (IPP) that was reported by Mary-Jo Foley already back in January 2010. I am a longtime QuickBooks Online user so I have a pretty good picture of Intuit’s SaaS delivery model at least from 2003. I believe Intuit was one of the first software companies to introduce a full-blown accounting solution for the SMB market and my company still uses it every single day.

In January 2010 Jeffrey Schwartz reported that Microsoft and Intuit stroke a cloud pact for small business where Windows Azure would be the preferred PaaS platform for Intuit and Intuit App Center.  This value proposition is obviously good for ISVs that can build solutions to the waste QuickBooks ecosystem with integration not only to QuickBooks data but also between QuickBook applications.

The idea behind this Intuit Partner Platform (IPP) is to help developers to build and deploy SaaS applications that are integrated with QuickBooks data and also to give huge exposure for the ISV on the marketplace that Intuit provides for its partners. This marketplace (Intuit App Center) has thousands of applications that can be used with QuickBooks and other QuickBooks third-party solutions.

Let’s look closer to why Intuit and Microsoft need each other. I read an interesting blog entry from Phil Wainewright that includes very interesting remarks about software platform that happens to be the topic of my Ph.D. dissertation (Evaluation of a Product Platform Strategy for Analytical Application Software). The blog entry from Wainewright includes following picture:

 

You can read more about this topic and download Wainewright’s report “Redefining Software Platforms – How PaaS changes the game for ISVs) for Intuit” and this can be found by following this link.

When you review the picture above in more detail, you will find interesting and relevant information how Windows Azure and Intuit IPP platform play together. According to Wainewright, the conventional software platform capabilities are all about functional scope of the development platform whereby cloud platforms add three additional distinct elements according to Wainewright: Multi-tenancy, Cloud Reach and Service delivery capabilities.  The service delivery capabilities have to do with provisioning, pay-as-you-go pricing and billing, service monitoring etc. The multi-tenancy is typically not something that the PaaS platform provides automatically without the application developer building the multi-tenancy logic to the application. I still hear people saying that a legacy application that is migrated to the PaaS platform will automatically become multi-tenant. This is not true as each application has to be re-architected to take advantage of things such as scalability (application increases compute instances based on load).

The idea behind Intuit IPP platform according to Wainewrite is that Intuit has built service delivery capabilities that can be abstracted from the functional platform that is on the left hand side of the picture. The idea that Intuit had initially was to be able to provide support for any PaaS platform to be integrated to the IPP platform which I think is a good idea by not practical considering how fast the PaaS platforms are evolving and the amount of investments that are put into them.

One thing to remember is that all cloud platforms such as Windows Azure has already moved on the horizontal axis whereby the situation and clear cut separation between functional platform and service delivery capabilities is no longer that obvious. This also means that any Microsoft ISV that builds additional infrastructure elements to Windows Azure has to be carefully aligned with Microsoft product teams as there might be a danger to be irrelevant as some third-party functionality will be covered with the functional platform itself (PaaS platform) like Windows Azure. I have seen the same situation with some ISVs working with BizTalk extensions that suddenly have become part of BizTalk itself. Microsoft is very clear with its ISV partners that they should focus on vertical functionality or features that are unlikely to be part of the Microsoft platform in the short-term.

A new post from Jeffrey Schwartz on August 11th, 2011 explains how Intuit IPP and Microsoft Azure will be even more integrated as Intuit will drop its native development stack and instead “focus on the top of the stack to make data and services for developers a top priority” according to Schwartz. In reality this means that Intuit will invest heavily in Windows Azure SDK for IPP and make developing an app on Azure and integrating it to QuickBooks data and IPP’s go-to-market services easy and effective. Microsoft released some more information about this partnership in the Windows Azure blog. The two companies have launched a program for this called “Front Runner for Intuit Partner Program” that explains what the developers get by participating in the program. The site portrays three steps: Develop, Test and Market and there is a video that explains what it means.

So what should we learn from this blog entry? First of all, every development platform (PaaS etc.) will evolve and my recommendation for the ISV is to focus and invest on one that you think is here in the long run. I think this example from Intuit is a great example of a company that was initially in the race of competing in the PaaS space to some extent to conclude that the investments to keep the competition going is just too huge and this led to the conclusion to select Microsoft Azure as the foundation for IPP. Intuit will be much better off by focusing on building logic on-top of Windows Azure by participating in SDK development an ensuring that any solution specific development can be easily integrated into Windows Azure platform. Intuit will therefore focus on providing data and services for developers to use with Windows Azure PaaS platform.

Microsoft has been in the development tools and platform development since its foundation so they are much better off to do those kinds of massive investments. I think this is very smart from Intuit and this enables Intuit to have a scalable solution that developers can rely on even if the decision was not easy according to Liz Ngo from Microsoft. Alex Chriss (Director, Intuit Partner Platform) from Intuit explains this in his blog why Windows Azure is a good foundation for Intuit development. Also, Intuit provides a tremendous opportunity for ISVs like CoreConnext and Propelware report based on the blog from Liz Ngo.

Software ecosystem will continue to evolve and EVERY ISV has to figure out how its solutions will meld to be part of different sub-ecosystems. This will also require efficient and well-defined Application Programming Interfaces (API) from all parties to be able to create an integrated solution based on service oriented architecture (SOA).

Let me known if you know other good examples where software ecosystems mesh nicely with each other.

What is needed for traditional Independent Software Vendors (ISVs) to move to the cloud?

If you have not heard enough of the cloud and its importance, you have probably been sleeping or being ignorant of what is happing in the IT industry. I have to say that I am unbelievably excited of having the opportunity to be part of this change and there are many reasons for this. The first and foremost is that the cloud has brought the software industry something new and exciting and a reason to re-learn a few things that keeps the innovation happening in our industry. I have lived three different IT industry eras: the minicomputer, client/server and dot.com era. The latest and very much transformational will create a new generation of solutions/applications that we all will somehow benefit from.

I still hear from many ISVs that “this is nothing new as we have had managed services for years” demonstrates that these naysayers do not really have the understanding what the cloud will bring to the table such as “pay as you use”, scalability etc. The cloud platform will give new opportunities for innovation, opportunities that traditional hosting can’t provide. If you are one of the naysayers, you can keep doing that but I will remind you in a year or two about this and let’s see where we are at that point in time.

If you are an ISV and have not looked at the cloud possibilities, you could be soon overtaken by a competitor that you would never have expected. There are hungry entrepreneurs that want to take over established vendors that might not be any longer as agile as a small startup can be. To become agile again, we have to think outside the box and forget about our old routines and thinking and accept that the change is here and that people will be consuming software in a different way that we are used to. I still think it will be a hybrid model where some of the apps will have to live on the device due to usability factors, but most of the data and logic will stay in the cloud. The cloud era has been here for a while and the early adoptors have accumulated experiences that the rest of the IT industry can benefit from. Some best practices can be found from CIO.com and an example of this is an article “Which Apps Should You Move to the Cloud? 5 Guidelines”. My recommendation is to do your homework (=planning) before you go to the execution phase. The cloud is different and requires different skillsets from people involved with it.

What if you are a traditional software vendor with a legacy application that relies heavily on a traditional business model? What are the actions that you need to take when taking the steps forward? I like the advice from Ben Kepes blog where he lists six different things that he feels that are important to understand. He also emphasizes that it is not that much of a technological change, but more of a cultural change that has to happen for Independent Software Vendors (ISVs). I fully agree what Ben is saying. My typical comment to ISVs is that it is a change in the DNA when an ISV moves to cloud architectures and some people will never get it and I expect there will be some turnover within the ISV community. A good example is the change in sales model where the commission structure has to change for the sales rep whereby the traditional commission plan with one-time deals is gone that made some successful sales reps to really make big money in short-term if successful in closing large deals during a financial year. Let’s view on what Ben Kepes views as the six culture changes are:

1)      Accept that disruption is going to occur and identify that it’s better to disrupt from within than without

2)      Accept that for disruption to occur, control needs to be given up.

3)      Dedicate resource – people, money and time – to building a development team charged solely with finding the “golden disrupter”

4)      Accept that disruption will hurt short and medium term revenues, but will ensure long term survival

5)      Once the product is there, don’t try and subvert it to suit the current status quo

6)   Don’t even think about having the same sales personnel or strategies selling the traditional and the disrupting offering – it won’t work

The first statement is what I always try to bring up in my workshops. You have to face the reality now and not delay the decision to innovate using the cloud. If you do not, you might have the same fate what Nokia had with Symbian platform.

The second statement is also important to understand. You cannot control the change, but you have to try to live with it and make the best out of it.

The third one is what ISVs usually fail with. If you try to push the “cloud transformation” to the same team that is taking care of your traditional software application/solution, you will not only burn these people; you will also fail in your cloud attempt. Software development using cloud architectures is not the same as developing for the traditional software architectures due to many reasons such as multi-tenancy, latency and also how the application is consumed using different mobile devices. Ensure that the people that are assigned to work on the cloud solution will have the means to do it including sufficient investment and realistic expectations.

The forth statement is in line what I have been blogging about for months, where the ISV has to plan how to manage the financial impact on the ISV business with a strong transitioning plan that takes into account the change from perpetual licensing model to subscription-based model where the payments are divided into the contract period. Based on our research and discussions with lots of different ISVs, three years or 36 months seems to be the magic number where the organization should start to see the real benefits of an ongoing subscription-based revenue model.

Statement five and six has to do with the change of ISV DNA that I explained earlier in this blog.

Remember also that traditional geographical boundaries that you thought kept you secure are also gone with the cloud. End users will test-and-try solutions regardless of location and there is nothing that the IT department can do about it. We have seen it so many times that it is not even funny anymore.

Is there a Magic Number for a SaaS business?

We have a tendency to find a magic formula for everything and this applies also to SaaS companies. In my research in this topic, I have found a few resources that give some direction of how to evaluate the healthiness of a SaaS business. It is easy to conclude that Monthly Recurring Revenue (MRR) or Average Recurring Revenue (ARR) is the driver for everything and this number is combined with Customer Acquisition Costs (CAC) we will eventually see whether the company will make money or not. If we add Average Recurring Cost per Customer (ACS) we have the main elements to figure out what the break-even point by using following formula:

BE=CAC/[ARR-ACS]

If we view the formula, it is easy for us to agree that if BE is greater or equal to 1; the company will never be profitable. In other words, Average Recurring Revenue (ARR) less Average Recurring Cost per Customer (ACS) will never be higher than Customer Aquistion Cost and that is not a good position to be in. Therefore, the ACC has to be able to cover the CAC for the company to be profitable. That is a very easy conclusion to come to. I demonstrated this in my previous blog entry where the sixth client finally was able to cover the overall CAC cost and the SaaS ISV started generating profit.

The fourth major driver is Customer Churn and this is specifically important with a SaaS business as nobody uses bad software and this will be very obvious when the customer does not want to sign up for a new contract term.  It was easier in the past when a perpetual software license was sold and the ISV got the money for it. The only thing that the ISV could lose is the annual maintenance and support fee of 15-25%. Today, an unsatisfied customer will never become profitable if walking away the first year (in typical scenarios).

A key number that seems to be a driving “Magic Number” and represent the health of a SaaS business is based on MRR growth when taking into consideration Sales and Marketing spend. The idea is that as long as the company is growing and the “Magic Number” is demonstrating that the sales and marketing spend is generating results, the company should continue on this path. The blogosphere includes a few sources in this topic and Lars Leckie was then one that came up with his blog entry that many others seem to be referring to. His Magic Formula is as follows:

QRev[X] = Quarterly Recurring Revenue for period X

QRev[X-1] = Quarterly Recurring Revenue for the period preceding X

ExpSM[X-1] = Total Sales and Marketing Expense for the period preceding X

The SaaS Magic Number = (QRev[X] – Qrev[X-1])*4/ExpSM[X-1]

Let view this formula with real numbers so we can get a feel what it means with some numbers:

 

Q1 Q2 Q3 Q4
Revenue $1.0M $1.2M $1.5M $1.6M
Sales and Marketing spend $800k $900k $1.2M
SaaS Magic Number 1.00 1.33 0.33

 

So what happens in the calculation is that the current quarter’s sales is subtracted from previous quarters sales and this is then multiplied with four (to annualize it) and then finally divided with previous months sales and marketing costs.

In the case above, the Magic Number seems to be going smoothly until Q4 when the number goes down dramatically with sales plummeting even with increased Sales and Marketing spend. According to Leckie, as long as the company maintains a ratio above 0.75 it should increase its sales and marketing spend, but if it is less than that, it should review its business as something might have changed the market condition.

Joel York takes this number a bit further by including Average Cost of Service (ACS) into the formula with the conclusion that the cost of service should be covered when calculating the Average Customer Rate of Return for the SaaS business. According to York, the Customer Rate of Return is the most powerful metric that a SaaS business can be measured on as it really shows whether the SaaS business will be a business or not. Therefore, York concludes this number (J) to be calculated in following way:

 

 

 

York also includes churn in his discussion where the growth added with churn should always be less than the average Customer Rate of Return (J). This is very logical if you think about it. The contribution from the client needs to recover the Customer Acquisition Costs, Average Cost of Service (ACS) and possible churn to achieve a situation where the customer becomes profitable for the ISV.

The common expectation is that CAC costs should be recovered in a year or so but York has put this additional requirement that the ACS costs have to be paid as well. I think this makes a lot of sense as the ACS could in some cases be considerable whereby the ISV should pay attention to them.

If we assume that the SaaS ISV has a contribution margin of 50% (Revenue less variable expenses), Joel’s Magic Number would be as follows:

When Contribution Margin = 50%

Joel’s SaaS Magic Number = The SaaS Magic Number /2

York takes a more conservative approach in his numbers where he concludes that The SaaS Magic Number of 0.75 just is not enough to “step on the gas” as the needed growth requires aggressive spending which then moves the SaaS ISV further down in time to profit scale. If we furthermore assume that the contribution margin (CM) is anything less than 50%, the time to profit is much longer specifically in start-up phases. York wants to see a Magic Number that is more or equal to 1 with the added requirement that ARR is > 2 x ACS whereby the ISV can quickly recover its acquisition costs.

We can conclude from this blog entry that the SaaS world does have some metrics to measure the health of the operation, and there are many perspectives how each analyst sees it: some view it from more conservative perspective and some have their venture capitalist perspective. The latter is very prevalent in the blogosphere and many of the SaaS authorities are from this domain. It is easy to say that they might not always represent the view of the entrepreneur, but more from an investor perspective and we all know what that means. It will be interesting to see if more entrepreneurs will provide guidance in this field like Josh James, CEO of Omniture gave at a conference and this generated the blog entries from both Leckie and York. Interestingly, Omniture was sold to Adobe and left the company soon thereafter.

Once we get enough people sharing their experiences in different aspects of the cloud business, we will eventually achieve a situation where we can provide guidance in metrics for different types of SaaS vendors.

ISV transitioning to the Cloud, Cloud Financials and Operational Metrics

I divided in my previous blog post how a cloud transition will impact an ISV. The first blog entry was about the change in business model and this blog entry is about the impact in financial model. However, it is important to recognize that the financial side has lots of different drivers and I will only portray a few of these in this entry, and deal with some others such as sales related metrics later.

Independent software vendors (ISVs) have the concern of profitability when running a cloud business. Mature software vendors with ongoing annual maintenance and support revenue are wondering how to make a transition to avoid future cash flow issues. The most typical question that I get from ISV management team members is: “how do we transition to the cloud without jeopardizing our current business?” Unfortunately there is not one and simple answer to this and what nobody wants to hear as an answer is: “it depends”. There are many different variables to consider and some of them are ISV specific and cannot be generalized. It is like comparing two different cars that have a different purpose: one that is used for racing and the other for transportation of heavy equipment. How does one compare these two and what is the comparison metrics?

I can still remember my early career when we did a bunch of comparisons between publicly traded companies in my business school using metrics that was regarded as “industry norm”. We had to learn in our accounting class each ratio that could be calculated concerning income statement and balance sheet. When we added cash flow statement to the equation, we were sometimes completely lost… me included. Once I understood the connection between income statement and balance sheet, life become so much easier. I would argue that ISV management has to do the same thing to really get to understand where a cloud business is taking them. I am sure that the ISV CFO and controller are on the right page, but I am not that convinced that the management team members all understand the impact of the change. That is just my observation from both research and talking to a bunch of entrepreneurs.

It is obvious that accounting metrics has not changed but was has changed is how we measure our operational activities that eventually leads into the financial accounting metrics that we track and our auditors are interested of.  If we change our model from classic perpetual software licensing model to subscription-based model and keep our operational metrics in the prior, I will guarantee that the company will run into a wall pretty soon and one of the things that would be recognizable is that there is no cash in the coffers.  Do we really know how to recognize revenue in a way that tax authorities are OK with it? Do we know how to recognize service revenue with a software sale from revenue recognition perspective? You do not want to find this out later on when an audit is taking place or when you are during due diligence when selling your company.

The ISV management has many questions to answer. Is your current business and software solution built in such way that it is easy for the current client to move to pure SaaS environment? What is the current complexity of your solution and does it require lots of human interaction to get delivered? Does your solution have lots of integration points to other operational applications? Does your current software solution support a migration to a pure SaaS environment? If it does not, what is the alternative? I am sure you are getting my point here. Running a solution from the cloud is not just to “port” the solution, but it is to have it run natively and I do recognize that this is not easy for many legacy ISVs.

What about the financials? The number one term that you need to familiarize yourself with is CMRR (Contracted or Committed Monthly Recurring Revenue), Churn and Cash. Other key metrics are Customer Acquisition Costs (CAC), Customer LifeTime Value (CLTV) and there is a bunch of others that are related to different operational functions such as sales, marketing etc.

Fortunately there are lots of good resources in the Internet that I have found very helpful in doing my own research. Many of these examples come with lots of use cases and practical advice so my recommendation to any ISV is not to try to figure these out on their own, but to really learn from what is already known.

Some of these resources such as David Skolp that maintains a blog for entrepreneurs with a specific focus on SaaS business as well as Joel York that brings lots of financial mathematics to the game. He also addresses something that I have not seen anybody else do which is the concept of Net Present Value (NPV) in the calculations.

What many ISVs forget is to keep their Customer Acquisition Costs (CAC) down as much as possible as many ISVs are still used to the old model where the prospect/lead needs lots of human interaction before the deal is closed. This is no longer possible in scenarios where the price is on a level that the ISV can never achieve break-even with providing too much support in the deal closing. If you look at the Customer LifeTime Value (LTV) and Customer Acquisition Cost (CAC) figure below, the trend needs to be according to the following picture.

LTV and CACIf the ISV did not control the CAC, it would very soon run into a situation where LTV and CAC are getting closer to each other and the ISV would be bleeding money.

Following picture from Joel York gives an even more interesting view how Customer Acquisition Costs (CAC) combined with Churn will impact an ISV and how each customer adds to the accumulated CMRR until it covers the accumulated CAC cost. In the picture the sixth client creates a situation where company becomes profitable. The picture also shows how churn will impact the overall MRR with time.

Churn and CMRRThe picture gives us an idea how CAC and Churn plays a central role in SaaS financials, but there are many other financial measures that an ISV should think of and also measure. Skok provides an interesting breakdown in how key SaaS goals can be divided into different components: Profitability, Cash, Growth, Other (like Market Share) and each one of these components can be divided into smaller components.

If we further divide the profitability into components, this is how it can be seen:

Profitablity in ComponentsWhen you view the picture in more detail, you can see how Customer Acquisition Costs (CAC) and LifeTime Value (LTV) drives the customer profitability, Monthly Recurring Revenue (MRR) and Services Revenue drives the overall revenue and when you add expenses and COGS to the formula, you will have the regular accounting related profitability. Measuring your employees can be done from many perspectives and I will address sales measurement separately in a later blog entry.

As we can see, there foundation for an ISV is still the same, to generate ROI for the investment and dividends for the shareholders. What has to change is how and ISV measures the operational activities when running a SaaS business. ISVs that have not made the move towards the Cloud might really have issues with their competitiveness going forward. My recommendation to mature ISVs is to start looking what can be done in the cloud world and get the development team focused on the changes that a pure Cloud solution will require to be truly multi-tenant so the ISV can achieve the scalability benefits of a PaaS platform such as Windows Azure. Stay tuned for more about metrics and changes in operational models for an ISV.