Lustratus REPAMA

Value Proposition Categories – MITICOR

Danny Goodall — Sun, 15 Nov 2009 14:57:52 +0000

I’ve been working on a way of categorising value propositions for some time. I’ve arrived at something I refer to as MITICOR which I believe represents the atomic value proposition elements.

By this I mean that all business to business value propositions can be broken down into these 7 base elements. I’m sure I will refine this over time but for our purposes these elements allow us to analyse and categorise the different value propositions that vendors use in their go-to-market efforts.

So what do these categories refer to?

Market

Elements categorised as “Market” include value propositions that relate to the organisation’s market or competitive situation, new product or service introduction as well as the organisation’s marketing efforts such as awareness, public relations or image.

Income

“Income” includes any offer that proposes to increase or sustain existing revenue. In addition new revenue streams fall into this category.

Time

“Time” relates to any value proposition that reduces the time it takes to achieve some organisational objective. Importantly this does not refer to reducing the time to achieve a tactical objective as this would likely be categorised under Operational below.

Institutional

Institutional value propositions relate to the organisation as an entity. Chief amongst these are value propositions that deliver value to shareholders. Taxational or political issues such as “green” policies also come under this heading.

Cost

Reduction in costs, offsetting costs and cost restructuring all fit under this value proposition category.

Operational

Propositions that deliver positive changes to the operational efficiency of the organisation come under this classification. Included in here would be propositions that provide visibility into the current operational effectiveness of the organisation.

Risk

The removal or mitigation of risk at a corporate, personal or project level falls under this value proposition classification.

Multiple Categories

Specific value propositions that vendors create will break down into one or more MITICOR category. It may be that a value proposition from a vendor relates to only one MITICOR category but it is likely that it will break down into more than one MITICOR category.

Examples

I’ve listed below some examples of vendor value propositions and the MITICOR categories that they break down into.

Value Proposition	Potential MITICOR Categories
Reduces development time	Operational, Cost
Reduces development time allowing products to be brought to market quicker	Operational, Cost, Market, Time
Reduce corporate carbon footprint	Institutional
Reduces power consumption and corporate carbon footprint	Institutional, Cost
Provides insight into current financial position	Operational, Risk
Opens up new market opportunities	Market, Income
Allows enterprises to differentiate themselves	Market, Income
Increases service provider sales	Income
Organisations no longer need to purchase expensive dedicated hardware but can instead rent space in our data centres	Cost

I wanted to document this classification in this blog because I will refer to them in future REPAMA research. I’ve also noticed during the course of my research that there are some very predictable value propositions/MITICOR element combinations. In a later blog I will try to document these MITICOR “chains” and specifically how they relate to the members of the decision making unit (DMU).

Danny Goodall.

Competitive Differentiation in Cloud Computing – “The horse-less carriage and typing pools”

Danny Goodall — Thu, 22 Oct 2009 12:09:30 +0000

I had a meeting with a prospective client earlier in the week and we were chatting about how differentiation and positioning in Cloud Computing has to mature.

The contention was that cloud computing vendors and service providers today are too inwardly-focussed and that they should look at the external market to determine their competitive marketing strategies. Cloud Computing differentiation bears all the hallmarks of early market strategy and is very limited. It got me thinking. Imagine if competitive differentiation was carried out in other walks of life the way it is currently carried out by most Cloud Computing vendors and service providers.

Imagine if Porsche for example had spent 7 years perfecting its new sports car, a car that was specifically engineered to be better than the comparable Ferrari in many very specific ways, a car that can do many things for its prospective owner. Imagine then if at the car’s launch it’s main differentiation was:

The Porsche 912 – you no longer need a horse to pull it along the road

Imagine if Xerox copiers, in an attempt to differentiate itself within the highly competitive markets in which it is present made the bold claim that:

The Xerox X987 – eliminates the need for corporations to maintain a typing pool full of typists to make copies of documents.

When the car was a disruptive new technology it was important to explain to its potential users how it was different from the paradigm it was replacing – the horse and cart. Likewise this was true with the discontinuous innovation introduced with the photocopier / photostat / copier. But once these technologies matured to the point where the paradigm was accepted and there was a genuine choice of suppliers to source it from, vendors then had to focus on their real competition and their real differentiation.

But today this is exactly how much of the differentiation in the various segments of the Cloud Computing market is currently carried out. Vendors and service providers have not yet made the leap that Cloud Computing is “an idea whose time has come”. So instead of aiming their fire at other cloud computing vendors, their differentiation strategies focus on the thing that they are replacing – the corporate data centre, on-premise hardware, non-virtualised operating systems, non-scalable web applicatons, etc.

Don’t get me wrong, it is absolutely essential that the prospect knows how cloud technologies differ from traditional technologies, but Cloud Computing vendors must also realise that they are in real competition for this business and lead with clearly drawn lines of differentiation between themselves and their actual, cloud-shaped competition.

The good news is that there are many “positions” still available to cloud computing vendors. And once these positions are established in the minds of prospects, it will be doubly difficult for their competitors to change these perceptions.

Taking such a position now will give some vendors a great advantage in the nascent Cloud Computing market but others will just feed the horse and call “walk on”.

Danny Goodall

The Decision Making Unit for Cloud Computing

Danny Goodall — Thu, 15 Oct 2009 15:04:09 +0000

I’m kicking off some research into the Decision Making Unit (DMU) for Cloud Computing services and software.

I’m interested to see how much, if at all, the cloud computing decision making unit differs from that of tradition data centre or infrastructure software sales. And if it does differ (as I suspect it does) then what is the impact on traditional marketing elements like audience, message, value propositions, supporting materials, etc.

I want to examine the decision making units for each of the different high-level segments in the Lustratus REPAMA market landscape / taxonomy / segmentation model for cloud computing.

For each of these segments, the basic question I want to answer is:

Within a B2B Cloud Computing transaction, what job roles are involved in the decision making process, what do these individuals need in order to arrive at a decision and how does this differ from traditional enterprise software sales?

It’s important to first stress that “marketing”, in the sense of the departmental responsibilities of the marketing team within a vendor or service provider, can only achieve certain things with respect of the decision making unit. Much of the responsibility for managing the technical and commercial sale obviously lies with the “sales” team. So in my analysis I will limit myself at the moment to exploring the influence that the marketing discipline can bring on the decision making unit.

First some terminology. We think about the roles of the DMU in the decision making process in the following way and refer to it using the acronym – IGIDBU (because the world needed another acronym).

IGIDBU – Initiator, Gatekeeper, Influencer, Decider, Buyer, User. I recognise that it isn’t the most simple or memorable acronym or mnemonic to remember, but saying it that way preserves some of the implied “chronology of contact” in the sales process. First we meet the initiator, then we deal with gatekeepers, etc. until the user “uses” the software or services.

This categorisation of the roles in the decision making process is quite common and is documented in many places – a good piece of background can be found in Strategic Marketing Planning and Control -Drummond, Ensor, Ashford published by Butterworth-Heinmann. I have seen some models that add another entity that owns the budget – “budget holder” or “Financier” but for our purposes we’ll wrap that role up in the Decision Maker because in my experience in infrastructure software sales the decision typically comes from where the budget is.

As I mentioned above, for each cloud computing market segment I’m going to identify the most likely job roles that fall into the IGIDBU categories above. Alongside them I want to map their needs and the likely marketing materials and messaging that is needed to help them arrive at the “right” decision.

The Change in Perceived Risk

Of particular interest to me is the change in the perceived risk of the ‘purchase’ with Cloud Computing. With an enterprise software licence, the degree of perceived risk in purchasing comes from a number of key areas including:

Will the product meet the functional needs of the users?
Will the performance of the product match the requirements?
Is the vendor stable/credible/’suable’?
How large is the capital outlay – and can we afford to write it off if the project fails?
etc.

Cloud computing adds or at least adjusts a number of these categories of risk:

Will the committed service level meet our needs?
Will the service level delivered match what was committed to?
etc.

With an on-premise purchase of licensed software, hardware, etc. the onus for ensuring performance and functional fit after the sale is with the company making the purchase. However, in a cloud situation where performance and more than likely functional capabilities will be documented within a service level agreement, the risk is mitigated to a degree. As long as the SLA is specified correctly, the onus for ensuring that the service level is met now lies with the service provider.

So the question is, will this perceived lower risk, speed-up or otherwise streamline the decision making process? And if so how will that change the way vendors/service providers market to the DMU?

The Change in Expense Accounting (Cap-ex to Op-ex)

Another significant change that Cloud Computing introduces is how the cost is accounted for. Instead of tying up significant capital expense and watching it depreciate on an on-premise solution involving physical hardware and software licences, a comparable cloud solution can be paid from operating expenses, based on actual usage over time.

As mentioned above in traditional sales, the size of capital outlay and the thought of having to write that off if the project fails is a key determinant of the level of perceived risk in arriving at a decision to ‘buy’. Again, the rhetorical question is whether this reduced capital commitment will change ‘purchasing’ behaviour and if so what impact that will have on vendors’ sales and marketing efforts.

I plan to publish the research later in the year. I am in the process of recruiting a number of vendors/services provider who are willing to provide input anonymously in return for access to the research. If you represent such an organisations, please contact me for more information.

As usual I will document the process in these pages.

Danny Goodall

Marketing spend is (again)…

Danny Goodall — Wed, 14 Oct 2009 11:12:20 +0000

...falling in 2009. No great surprise there then as marketing budgets have been used by many struggling organisations as a “profit shock absorber” .

But what is of interest is what that reduced budget has meant to the shape of marketing organisations and their priorities. How are they actually allocating remaining budget in these tough times? What has this meant to marketing headcount? etc.

That is the focus of IDC’s Michael Gerard in his annual analysis of marketing spend. Some snippets of the study have been released publicly and I’ve listed some of these below:

Large organisations’ marketing budgets have on average reduced by 8.3% and their headcount has reduced by 10%
6000 IT vendor marketing roles have been lost worldwide in 2009
Lack of budget has forced process improvements and in particualar has meant closer collaboration with sales
Broader, product portfolio marketing has been sacrificed to allow for more tactical themed campaigns.
Sales enablement has become a focus

Michael makes some other general observations and recommendations in his blog which is well worth a read.

Danny Goodall

A Refreshing call with GigaSpaces

Danny Goodall — Thu, 08 Oct 2009 08:53:03 +0000

Steve and I had an interesting and refreshingly different call this morning with GigaSpaces.

They had reached out to us to make sure we knew all about them so that they could be fully represented in each of the categories in our cloud computing market landscape / segmentation / taxonomy where they have a solution.

And after the call I can see that instead of just being in

Cloud Software / Compute

They also have a valid claim to

Cloud Software / Data

and may be even

Cloud Software / Cloud Management ( /Application Services Management )

This raised a bit of a dilemma for me. I certainly want to represent vendors and providers accurately in the segmentation model but I want to avoid vendors appearing in lots of different segments just because they believe that some esoteric feature or other qualifies them.

Instead I want the segmentation model to reflect where the vendor/provider specifically and actively addresses a market need with a specific capability and value proposition. So if I hear from a vendor/provider “yes we can do that too”, I’m reluctant to simply add them to a segment. After all the motivation behind producing the segmentation model was to remove some of the confusion present in the Cloud Computing not to perpetuate it.

So I think we’ll need to reflect on what we heard this morning from GigaSpaces and think how best to represent those vendors in our market segmentation document that have a single product with broad capabilities. Having said that I think there is enough about the XAP proposition that means I will be adding it to at least one more segment of the market landscape.

Anyway, the refreshing part of the call was that GigaSpaces’ marketing seems to focus on what they can do for organisations rather than simply placing the “Cloud Computing” term before, after and in the middle of their product name everywhere it appears. In fact you have to go digging on their web site to find references to the cloud-enablement features of their product line. I’m not sure whether they have taken this approach consciously or if it is that they’re not sure how best to position their offering in the cloud market. The risk I guess is that as they are not positioned specifically as a cloud computing vendor, they may not be placed on clients’ long lists. But it certainly differentiates them and different is usually good unless you’re selling 8-fingered gloves.

These calls with vendors are useful for many reasons but mainly to test some of my assumptions. As with many of the products and companies I have looked at in compiling the segmentation model, I had “assumed” that I knew what the product was and what it did. It turns out there are many more strings to XAP’s bow than I had at first realised. I knew GigaSpaces as a purveyor of extremely scalable application servers but that, it turns out, is only half the picture.

One interesting feature of GigaSpaces’ XAP product is its application services management layer (my term not theirs – they use application management services!). This layer understands service level commitments for the infrastructure as well as the applications that are deployed to it. It’s common practice for the infrastructure to “understand” the service level that is expected from the infrastructure itself – usually measured in CPU percentages, data volumes or some such. However it’s not so common for the infrastructure to understand the commitment that the application developer has made about the service level that the application will deliver. These application layer service levels are usually described in some business metric and to then have the infrastructure react to automatically provision more infrastructure to meet the business’ requirements to ensure that application SLA commitments are met is a certainly an interesting claim. One that we will dig into a little further over time. GigaSpaces’ Jim Liddle explains a little more here – whist also picking a fight with TIBCO over whether its claim that “self-aware elasticity” is something unique to Silver.

Interestingly, it appears that with a number of GigaSpaces recent Cloud Computing customer wins (they claim to have 75+ “cloud” customers) they have in fact used this application management services layer to control and manage Amazon’s EC2 infrastructure. This ability to manage application services outside of its own compute infrastructure goes some way to answering my rhetorical question of whether any vendors were focussed on providing a pure play layer for application services management. It appears that there are.

So I’ll make some changes to the segmentation model in light of our conversation this morning and I’ll also keep an eye on how GigaSpaces’ cloud proposition develops – specifically following their Platform as a Service partnership with ServePath’s Go-Grid announced earlier today.

Danny Goodall

Reverse Engineering Force.com’s Approach to the Cloud Computing Market

Danny Goodall — Wed, 07 Oct 2009 00:00:46 +0000

I’ve been a bit busy recently and so instead of finishing off the complex REPAMA SAS into the “Cloud Computing / Cloud Software / Cloud Management / Application Services Management” study, I decided to produce a rough draft of the much simpler REPAMA into Force.com’s go-to-market strategy instead.

Whilst the segment analysis study only covers Force.com at the moment, I will add additional vendors/providers into the study over the coming weeks. If you have any suggestions who I should compare to/with Force.com, let me know.

I’m quite pleased with the result. Not because of any specific talent on my part but rather as I’ve already said here, Force.com’s marketing is a case study in how to take a new, disruptive technology to market. They understand their audience, they know what problems they solve and they know why they’re better/different. They communicate in clear language and they repeat their positioning strategy again and again and again consistently in all of their out-bound marketing communications. They’ve had successes and they’ve been able to document this and use it as proof of the claims they make. It’s been a joy to reverse-engineer it. That’s not to say that I think it’s perfect – they do tend to mix their audience and messages (audience strata mismatch) but it is very good indeed.

As I’m working through the cloud computing market and helping some vendors with their go-to-market strategies I’ve decided to share this and some future studies on here because as I said in my ironic blog mission statement all those months ago, I want to highlight best practice in marketing communications and product marketing through this blog. So I thought it would be useful to share what value propositions and messages a market leader is using to address their prospects.

Anyway, below is the positioning statement that I’ve reverse engineered for Force.com’s proposition to end-user organisations. (I don’t plan to tackle the ISV or SI propositions yet)

It’s a little woolly and raw at the moment but even in that state it’s clear that Force.com knows its market, its competition and its USPs. The REPAMA SAS containing just Force.com at the moment can be found online at Slideshare.net and is embedded below.

If you’d like a copy of the slides let me know. For details of how to interpret the results of the REPAMA study please review the Lustratus REPAMA Guide.

Danny Goodall

Cloud Computing Lock-in

Danny Goodall — Fri, 02 Oct 2009 06:30:50 +0000

My Lustratus Research colleague Steve Craggs ponders cloud lock-in…

…and asks the questions whether it is necessarily a bad thing here.

Force.com – Hat’s Off Time

Danny Goodall — Thu, 01 Oct 2009 16:22:56 +0000

Steve and I met with the good people at Force.com this morning to get an update on their approach to the Cloud Computing market and to hear their vision for the future.

I’d already carried out some REPAMA analysis of Force’s marketing proposition and, just like I found when I looked at Oracle’s ESB proposition,I was very impressed. With some vendors’ marketing propositions I have to spend a long time inferring what their strategic marketing strategy is, for others the strategy is so well communicated to their prospects through their out-bound marketing communications that my job is made easy.

And so it was with Force.com…

Unlike complex on-premise .Net and Java development tools, Force.com is half the cost and five times as fast

I’m paraphrasing and simplifying of course but that is about the nub of the proposition. It’s repeated over and over again and as we found out this morning there appears to be some substance behind the claims. That said, neither benefit metric (cost nor time) can be impartially validated. But that doesn’t really matter. I know, I know, of course it ‘technically’ matters but this is about market perception where Force.com was first to grab a space in prospects’ minds and that will be tough if not impossible for other vendors/providers to wrestle back.

Force.com is signing up end user customers and ISVs in ever-increasing numbers and with their SFDC subscribers subsidising the provision of the infrastructure to their Force.com platform users they don’t have the set-up costs and growing pains of some of their potential rivals. It’s an impressive operation and one that I’m sure we’ll touch on in a bit more detail in the coming months. But taking off my marketing analyst hat and putting on my technology analyst hat for a moment, I have one concern about these off-premise platform as a service propositions. And the people we met from Force.com were, as yet (although I’m meeting with one of their techies who I know from a previous life for a coffee this evening) unable to answer satisfactorily, and that concerned workflow and process orchestration.

How does a process that is developed with/within Force.com play a role in an externally managed process/service orchestration or workflow? The answer for process orchestration appears to be that any fragment of a Force.com application can be exposed as a web service which means that you have enough granular control (and associated complexity by the way) to do anything you want. But what about an off-premise managed workflow that relies on providing UI from a number of different on-premise and off-premise systems to achieve the result? Can Force.com UI and logic integrate into that sort of external situation? We’ll see.

Anyway, as I said I was impressed as much by what I heard as what I had seen about the way the company executes. On top of it all they have taken cloud computing from the theory and made it real for many users. So, as I said, hats off to them.

Danny Goodall

Pure Play Application Services Management in Cloud Computing?

Danny Goodall — Tue, 29 Sep 2009 15:51:42 +0000

So Steve and I had a briefing call with Kaavo yesterday who have some interesting technology. And it set me thinking about whether there is a market for pure play application services management in the cloud.

Kaavo automates the job of application configuration and management in the cloud. The product – imod, is rules and workflow-based and manages the life-cycle of application provisioning, including deploying and configuring the software components or services required to create the environment in which applications execute.

I hope I’m not dumbing it down too much to say that I think of it as a data centre automation tool that understands how to manage virtual IaaS instead of physical infrastructure. Kaavo’s CEO and founder Jamal Mazhar would I’m sure also point out that Kaavo takes a top-down, application-centric approach when compared to other solutions in the space. The IaaS deployment environments that they currently support include Amazon, Rackspace and GoGrid amongst others with support for the Eucalytpus project coming soon.

The product naturally fits into at least two of the categories of the market landscape / taxonomy / market segmentation model that I’ve developed. They certainly appear in

Infrastructure Services/Services

But I could also make a case for them in

Cloud Software / Cloud Management

and even

Cloud Software / Cloud Management / Application Services Management

But whilst the business model of Kaavo remains service-based (they charge per CPU hour of managed application) then that pretty much excludes them from the last two software-based categories.

As I’ve been looking at the application services management category in some detail, one pattern that I’ve seem amongst vendors such as DataSynapse (TIBCO), Appistry, and 3Tera is that whilst they offer the management services to automate the deployment of applications, they appear to major on deploying those applications and application components to their own infrastructure as opposed to infrastructure provided as a service by a third party.

A number of these vendors have come to Cloud Computing via Grid Computing and as such it makes senses that the virtual infrastructure that they deploy to is their own grid. They would rightly point out that owning the management and the infrastructure leads to many benefits such as tighter control, better monitoring and better support for the scaling the infrastructure up and down to match demand. In fact some of these vendors do appear to provide the option for deploying to third-party infrastructure services such as Amazon’s EC2, so it suggests that this sort of hybrid infrastructure may be being endorsed.

But I guess I’m left wondering two things.

Firstly is there really a separate market for pure-play application services management where the infrastructure is always provided by a third party? Don’t get me wrong I can see the need and I can see the benefit but it looks a little too much like the existing discipline of application services management already present in today’s data centre automation tools. So if these existing tools add the capability to deploy to, monitor and manage virtual infrastructure as a service then they will be well placed to get the business. But then again perhaps adding this capability is not a trivial matter. Hmm. Not sure.

Secondly, assuming that there is a separate market – what is the route to market for this sort of pure-play, services-based ( as opposed to licensed software ) offer? Could it be taken to enterprises directly? Yes, but it would require significant resources. To me, it looks like a more natural proposition for aaS providers to help them manage the massive number of deployed applications that they will be looking after if the predictions for the impact of cloud are accurate.

Either way Kaavo has an interesting approach that I’m sure either Steve or I will revisit as they develop.

Danny Goodall

An Interesting Piece on Value Propositions from ITSMA

Danny Goodall — Fri, 25 Sep 2009 10:41:02 +0000

Whilst carrying out some research recently I realised that I need to arrive at a more granular categorisation of the types or categories of value propositions that vendors use.

And in attempting to do that I stumbled across an interesting read on the ITSMA site entitled Why You Need Three Different Types of Value Propositions. I hadn’t heard of ITSMA before but it appears that they focus on helping high-tech organisations to market solutions and services. I’ll certainly track them from here on in because I felt that I could have written the blog entry myself as it matches my own personal experience very accurately.

The three types of value proposition that the author refers to are in fact not the same as the categories of value proposition that I’m looking for but more of that in a future blog entry. But, I was also struck by the process that the author Julie Schwartz advocates for developing value propositions see below:

Step 1. Understand the market and clients.

Step 2. Determine your true differentiators.

Step 3. Articulate unique value based on customer need.

Step 4. Quantify value.

Step 5. Elicit internal and external feedback and revise.

Step 6. Collaborate with sales to communicate value propositions.

as again it is similar to our own advice on building propositions in my blog entry from last November here.

1. Understand what the competition is doing

2. Understand your own capabilities and how you are different from the competition (*and change your positioning and messaging if required)

3. Understand where your prospects are still willing to spend money – the funded initiatives

4. Understand what pain is causing the prospect to still spend money – what are they looking to achieve?

5. Create messaging by mapping your own capabilities and differentiation, to the prospect’s pains and their willingness to spend

6. Retrain the sales force with the new focus/messaging

7. Use the right medium to get your proposition in front of the right person in the right organisations

Having said all of that, I do feel that there is a terminological difference between Julie’s value proposition and my own. I think the use that Julie has settled on, and let’s be clear there are no hard and fast defitions for the stuff – it’s a matter of personal preference, is similar, but not identical to some of the elements of what I would refer to as the positioning statement.

Personally, I use the value proposition term in two ways. Firstly, and very generally, the statement of the type of benefit that will be enjoyed AFTER a prospect has become a client.

Examples:

It will reduce the risk of failure

It will deliver projects quicker

It will increase profit

Secondly, the internal strategic marketing deliverable that product marketing/communications individuals are responsible for crafting is a formal definition of a specific proposition to a specific audience.

For this I usually follow a format similar to the one below:

1. A statement of quanitifiable benefit that a specific audience will enjoy AFTER they do business with you

2. An interpretation of what that benefit will mean for the specific audience

3. Proof of where the company has previously delivered this value to a similar audience and what the result was

An example (numbers only to illustrate the sections above):

1) By utilising our technology, mobile telephone operators can roll out new services between 2 to 3 months earlier than traditional approaches. 2) In a very competitive market this provides significant competitive advantage and increased revenues as enjoyed by 3) XYZTelco who we helped to bring a location-based SMS service to market in under 3 months from project inception. This led to them gaining a market leadership position for this service.

Anyway, I’ll revisit the categories of benefit/value that I’m really interested in an an up-coming blog but I thought I’d share this interesting read with you.

Danny Goodall