On Wednesday, the Internet was buzzing with the news that Steve Ballmer of Microsoft, and Rupert Murdoch or News Corp, were discussing an agreement that would allow Microsoft exclusive access to News Corp content. Here is the transcript from the Ballmer / Murdoch conversation that led to this announcement.
Ballmer: "Rupert, we both have a problem and I think we can help each other. Google is leaching your revenues away by indexing your content for free. If you let it go on much longer, your Media Empire will be as profitable as a bunch of high-school newspapers. Google is a thorn in our side as well. I am okay with giving them search advertising, but they are using those revenues to compete with Office, Outlook, Windows Mobile, IE and everything else we do. So here's my idea - let's cut the legs out from under Google. I will buy the exclusive rights to index your News Corp content, and then show it as online search results. It reduces the value of Google's results, you make money, and we benefit. Frankly, were making no money on search advertising now and can only improve by having better content."
Murdoch: "I like the idea. We will charge search engine providers to index our content. No pay - no content. Hey, I spend a fortune on all those Wall Street Journal people and Google simply goes ahead and indexes the content, and then charges for ads on the search results pages. This way, I make money and you reduce Google's value and associated revenues. If Microsoft gets my Wall Street Journal content and maybe a couple of other Financial site's content, why would anybody with interest in financial information, every use Google? Brilliant."
Ballmer: "So Rupert, here is where we get a bit of revenge as well. Google and the other search engines will be forced to pay for premium content, and then either pass the costs on to their advertisers, or they will need to take a hit in their margins. If this idea reduces the market value of all search providers, too bad. Either way, I don't care. Advertising in over 90% of their revenues and under 10% of ours. Let's see them try come into our business sectors without their big advertising revenue stream."
Okay - so the transcript is not the official one from the Ballmer and Murdoch meetings, but you have got to admit, it does make business sense for both of them. It will be interesting to see how the discussions continue, and how Google counters.
Showing posts with label business strategy. Show all posts
Showing posts with label business strategy. Show all posts
Friday, November 27, 2009
Saturday, May 10, 2008
A SaaS Go-To-Market Segmentation Framework
While SaaS is a relatively new deployment option (since ~1998), it is still governed by the fundamental rules of B2B marketing: understand your customer (research), make sure that you connect with them (lead gen), and then provide them with a value proposition that they can't refuse (product positioning). Sort of like the Godfather movie but without the terminal consequences. It's a terribly summarized overview of B2B marketing, and one that my old marketing professors Kottler and Sawhney would probably raise their eyebrows at, but fundamentally it's true There are however a number of twists in marketing SaaS that distinguish it from traditional SW sales.
To start with, SaaS is just like installed SW in that there is no one-size-fits-all solution. Different SaaS applications will appeal to different customer demographics. The functional and technical requirements of a 5 person consulting organization are vastly different from those of a $5B bank. For example, the consulting organization probably does not need LDAP integration while the bank will need LDAP (or equivalent) integration into its security infrastructure. The bank will most likely also willing to pay for process refinements and user training as part of a standardized rollout methodology. The Net Net is that any SaaS go-to-market offering needs to be designed for the specific segments that are being targeted.

(3) Using the Technical Impact / Organizational Impact structure, here is how some existing SaaS players stackup:

(4) Breaking the segmentation up a bit further, you get Three Tiers of SaaS Go-To-Market Options:
(5) SaaS Go To Market Actions By Tier:

*When it comes to compensation, SaaS sales introduce complexity. How do you compensate the salesperson? On the total contact value? On a per sale value? What if you are in Tier 1 and offer a 30 day free trial? Or Tier 2, a 90 day paid pilot? Or Tier 3, a 1 year subscription with a service based cancellation clause? Lot’s of interesting topics for another post.
So, this post has been a bit more extensive than most, but it does give a good idea of the structure that I have defined and implemented at IQ as part of our segmentation and go to market strategy. This structure works for us and there is a good chance that it is flexible enough to work for you. At the very least, it is a starting point for how to do your own segmentation and frame your own strategy.
To start with, SaaS is just like installed SW in that there is no one-size-fits-all solution. Different SaaS applications will appeal to different customer demographics. The functional and technical requirements of a 5 person consulting organization are vastly different from those of a $5B bank. For example, the consulting organization probably does not need LDAP integration while the bank will need LDAP (or equivalent) integration into its security infrastructure. The bank will most likely also willing to pay for process refinements and user training as part of a standardized rollout methodology. The Net Net is that any SaaS go-to-market offering needs to be designed for the specific segments that are being targeted.
I have developed the following segmentation framework to analyze and plan a SaaS go-to-market program. Specifically, it is focused on strategic product positioning based on the deployment of the SaaS solution - it does not address any of the tactical marketing / lead generation programs. Also, I am making an assumption that the solution itself is solving a material business problem -- if you are not solving a problem and meeting a need, all the positioning in the world is not going to make a difference.
The following images provide a fairly self explanatory overview of the framework.
(1) Defining the Organizational Impact of the SaaS solution:


(2) Defining the Technical Impactof the SaaS solution:

(3) Using the Technical Impact / Organizational Impact structure, here is how some existing SaaS players stackup:

(4) Breaking the segmentation up a bit further, you get Three Tiers of SaaS Go-To-Market Options:
(5) SaaS Go To Market Actions By Tier: 
*When it comes to compensation, SaaS sales introduce complexity. How do you compensate the salesperson? On the total contact value? On a per sale value? What if you are in Tier 1 and offer a 30 day free trial? Or Tier 2, a 90 day paid pilot? Or Tier 3, a 1 year subscription with a service based cancellation clause? Lot’s of interesting topics for another post.
So, this post has been a bit more extensive than most, but it does give a good idea of the structure that I have defined and implemented at IQ as part of our segmentation and go to market strategy. This structure works for us and there is a good chance that it is flexible enough to work for you. At the very least, it is a starting point for how to do your own segmentation and frame your own strategy.
Labels:
business strategy,
framework,
market segmentation,
SaaS
Friday, April 4, 2008
Nucleus Research misses the mark on Saas vs ASP
I have been an interested reader of the Nucleus Research's studies since they launched. For the most part their analysis is insightful and balanced but they really missed the mark in their "Hosted versus on-demand" study.
http://nucleusresearch.com/research/notes-and-reports/hosted-versus-on-demand/
If you have ready any of my other posts on Software as a Service (SaaS), you will realize that I consider SaaS to be a strong business model and a great deployment option, but I do not consider it to be the best model or the death of SW as we know it. It will be a delivery model, but not the only delivery model available. Yes, this runs contrary to a lot of pundits (like Nucleus Research), but let's face it - there are a variety of attributes that make a product successful in a SaaS model, while there are other attributes that would make it less successful. For example, highly integrate applications are not well suited to SaaS given volumes, latency, etc. On the other hand, services with additional value-add components like GSX / Celarix or Constant Contact are perfectly suited. Also, hell will freeze over before government entities and a lot of large organizations use SaaS as the only delivery model for their applications. There are just too many compliance, legal and security issues that they would have to overlook or ignore to make it feasible. For many organizations, economics is also not a good reason - the US Government and Fortune 100 companies each have significant enough data center expertise and economies of scale that very few, if any, SaaS providers can compare to.
Most importantly, just providing a solution in a "multi-tenant architecture" is not enough justification for a SaaS model. Multi-tenant architectures work well, that is how we deployed Celarix, but they also have downsides (which Nucleus forgot to mention). Everybody has to get upgraded at the same time, regardless of organizational change management impacts or interfacing issues. If the application is down or performing slowly, everybody is impacted. I have experienced these issues at Celarix (fortunately very seldom). At IQ, our applications are provided either on-site or on-demand (ASP / SaaS). Each customer gets their own virtual instance of their application run from a cluster of blade servers. The cost economics work well AND the customers can define their own backup, interfacing and security requirements. The choice of deployment option is up to our customers (which is where it should be).
At IQ we use a variety of SaaS solutions such as ADP, ConstantContact and GoToMeeting amongst others. Each of these solutions deliver financial value - I don't need to get servers, communication lines setup or IT resources involved. Each of these solutions also deliver unique business value (e.g. ConstantContact takes care of message delivery and SPAM compliance), but that doesn't mean all applications deliver additional benefit from a SaaS model. That I believe is the fundamental issue I have with Nucleus' report - software that delivers unique value as a SaaS solution should be delivered as one. Otherwise give the customer a choice.
http://nucleusresearch.com/research/notes-and-reports/hosted-versus-on-demand/
If you have ready any of my other posts on Software as a Service (SaaS), you will realize that I consider SaaS to be a strong business model and a great deployment option, but I do not consider it to be the best model or the death of SW as we know it. It will be a delivery model, but not the only delivery model available. Yes, this runs contrary to a lot of pundits (like Nucleus Research), but let's face it - there are a variety of attributes that make a product successful in a SaaS model, while there are other attributes that would make it less successful. For example, highly integrate applications are not well suited to SaaS given volumes, latency, etc. On the other hand, services with additional value-add components like GSX / Celarix or Constant Contact are perfectly suited. Also, hell will freeze over before government entities and a lot of large organizations use SaaS as the only delivery model for their applications. There are just too many compliance, legal and security issues that they would have to overlook or ignore to make it feasible. For many organizations, economics is also not a good reason - the US Government and Fortune 100 companies each have significant enough data center expertise and economies of scale that very few, if any, SaaS providers can compare to.
Most importantly, just providing a solution in a "multi-tenant architecture" is not enough justification for a SaaS model. Multi-tenant architectures work well, that is how we deployed Celarix, but they also have downsides (which Nucleus forgot to mention). Everybody has to get upgraded at the same time, regardless of organizational change management impacts or interfacing issues. If the application is down or performing slowly, everybody is impacted. I have experienced these issues at Celarix (fortunately very seldom). At IQ, our applications are provided either on-site or on-demand (ASP / SaaS). Each customer gets their own virtual instance of their application run from a cluster of blade servers. The cost economics work well AND the customers can define their own backup, interfacing and security requirements. The choice of deployment option is up to our customers (which is where it should be).
At IQ we use a variety of SaaS solutions such as ADP, ConstantContact and GoToMeeting amongst others. Each of these solutions deliver financial value - I don't need to get servers, communication lines setup or IT resources involved. Each of these solutions also deliver unique business value (e.g. ConstantContact takes care of message delivery and SPAM compliance), but that doesn't mean all applications deliver additional benefit from a SaaS model. That I believe is the fundamental issue I have with Nucleus' report - software that delivers unique value as a SaaS solution should be delivered as one. Otherwise give the customer a choice.
Labels:
business model,
business strategy,
Marketing,
SaaS
Thursday, December 20, 2007
SaaS - One Size Does Not Fit All
While getting my MBA from Kellogg, I co-founded a supply-chain and logistics software company (Celarix) that delivered the "software" as a web-based service. We launch the company in 1998, and we were one of the first in our space to offer a solution as a hosted application. When setting the strategy and defining the delivery model, I didn't realize the buzz around SaaS that would come a decade later. At the time, the unique approach made strategic sense, provided a compelling model to customers and resulted in the company being acquired around four years later.
For Celarix, SaaS was the best and only viable delivery model. In a nutshell, the service provided visibility to global supply-chain activities by integrating with hundreds of the world's leading logistics providers. Given the effort required for each integration, it would have been very difficult for any customer to replicate the network that we could develop. By offering the solution via SaaS, we were able to provide software + valuable logistics data.
Today, I see a lot of hype around SaaS but not a lot of business models that provide value beyond just the backend IT blocking and tackling. While there are benefits to SaaS, there are also issues and it is not as a one-size-fits-all option however.
SaaS Benefits
1. Somebody else takes care of the technical "plumbing"
2. Barriers to switching are low
3. Costs can be spread over a longer period of time
4. Time to value can be accelerated
Saas Issues
1. Everybody is up or everybody is down
2. Everybody must run the same software version
3. All change management is on the vendor's schedule
4. SLA's are still scarce - (even Salesforce.com, the poster child for SaaS doesn't offer them)
5. More expensive over the long-term
6. Corporate governance takes a back-seat [i.e. backup, disaster recovery, archiving, SOX compliance, etc.] are mostly outside your control
7. Capabilities for integration into legacy systems is still not widespread
8. Vendor "sustainability" and access to the application is not guaranteed (i.e. with installed SW, if the vendor goes out of business, you still have the SW to run. With SaaS, you have limited recourse)
For some, SaaS is a great options, while for others, on-site deployment is a better alternative. The dogmatic industry drum-beat that SaaS is the best solution for everybody is downright wrong.
For Celarix, SaaS was the best and only viable delivery model. In a nutshell, the service provided visibility to global supply-chain activities by integrating with hundreds of the world's leading logistics providers. Given the effort required for each integration, it would have been very difficult for any customer to replicate the network that we could develop. By offering the solution via SaaS, we were able to provide software + valuable logistics data.
Today, I see a lot of hype around SaaS but not a lot of business models that provide value beyond just the backend IT blocking and tackling. While there are benefits to SaaS, there are also issues and it is not as a one-size-fits-all option however.
SaaS Benefits
1. Somebody else takes care of the technical "plumbing"
2. Barriers to switching are low
3. Costs can be spread over a longer period of time
4. Time to value can be accelerated
Saas Issues
1. Everybody is up or everybody is down
2. Everybody must run the same software version
3. All change management is on the vendor's schedule
4. SLA's are still scarce - (even Salesforce.com, the poster child for SaaS doesn't offer them)
5. More expensive over the long-term
6. Corporate governance takes a back-seat [i.e. backup, disaster recovery, archiving, SOX compliance, etc.] are mostly outside your control
7. Capabilities for integration into legacy systems is still not widespread
8. Vendor "sustainability" and access to the application is not guaranteed (i.e. with installed SW, if the vendor goes out of business, you still have the SW to run. With SaaS, you have limited recourse)
For some, SaaS is a great options, while for others, on-site deployment is a better alternative. The dogmatic industry drum-beat that SaaS is the best solution for everybody is downright wrong.
Thursday, March 22, 2007
Online Marketplaces ...Back To The Future
InformationWeek has a very interesting article on Red Hat's move to having an online marketplace. This is consistent with the IQ strategy and certainly highlights that our approach and positioning are on the leading edge of the market. Other notable early movers include SugarCRM (SugarExchange), Joomla (Joomla Exchange) and Salesforce.com (AppExchange). Each of these companies have identified the value of leveraging their brands and user communities for growth - sort of like judo for nenw technology companies. I expect that we will see a lot more companies launching these types of initiatives. Having an Exchange is almost a requirement for Open Source companies but I also expect others such as Quickbase, Basecamp and even heavyweights like SAP to enter the fray.
Red Hat Talks Up Online Open Source Marketplace
Linux leader looks to certify the growing number of open source programs for its operating system and middleware platform. http://www.informationweek.com/story/showArticle.jhtml?articleID=198001606
Developing an Exchange / Marketplace strategy is one thing, being able to fund, execute and deliver on that strategy is quite another (sounds very late 90s .bomb) . So, what are the critical success factors? I believe that there are at least 5 :
Red Hat Talks Up Online Open Source Marketplace
Linux leader looks to certify the growing number of open source programs for its operating system and middleware platform. http://www.informationweek.com/story/showArticle.jhtml?articleID=198001606
Developing an Exchange / Marketplace strategy is one thing, being able to fund, execute and deliver on that strategy is quite another (sounds very late 90s .bomb) . So, what are the critical success factors? I believe that there are at least 5 :
- Strategic Positioning - how does the marketplace contribute to making customer's existing investments even more valuable? how will the "owner" company benefit from the Exchange? Salesforce, SugarCRM and F5 have all done great jobs of launching Exchanges that are complementary to their core products. From what I have seen of the Red Hat Marketplace, they are missing the mark. Their marketplace is a venue to purchase a limited number of products that you can purchase directly or download for free with an extra click or two. Without value to the end customer, I don't forsee much traction.
- User Base -the larger the user and partner base, the higher the probability of success. It stands to reason that the more consumers there are, the more developers are inclined to spend time building solutions that they can profit from.
- Community - I draw a distinction between User Base and Community since one does not imply the other. To be successful there needs to be a vibrant Community which can add new applications (free and for a fee), post answers to user questions and most importantly refer others to the product / service / marketplace.
- Ease of Engagement - ease of engagement is probably the most important aspect of building a dynamic community and network. If it is difficult to "engage" - customers and partners won't. In a world of distractions and countless alternatives, engaging and captivating customers and partners is critical. From sign-up through documentation to online chat and user forums, engaging customers and partners is the critical challenge.
Will there be a first mover advantage? Will established players such as Microsoft, SAP and Google enter the market and provide superior alternatives? We are in the early stages of an exciting time - traditional software, open source software and SaaS business models are colliding, business models are evolving and revolutionary new players are entering the marketplace (lousy pun...couldn't be avoided). I look forward to seeing how the first crop of Exchanges 2.0 take-off and evovle.
Subscribe to:
Posts (Atom)
