lustratus REPAMA

Archive for the ‘go-to-market’ Category

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

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

I’ve completed the first draft of the cloud computing segmentation model upon which we will build our REPAMA studies.

As I’ve mentioned before along my journey to arrive at this model, I’ve found the cloud computing market to have quickly become crowded and confused. This is largely due to the ease at which “traditional” vendors have re-repositioned themselves to catch the cloud computing wave.

The other issue of course is that over time cloud computing will cease to be a new paradigm and will quickly become the way consumers and businesses avail themselves of computing services. So what I’m seeing here is a market in transition where just about every category in traditional software sales will have an offer in the cloud computing space until on-demand models becomes “the norm”.

So I guess it’s really not that surprising to see so many vendors present in the space. But at the same time it is very confusing for legitimate prospects to cut their way through the mass of terminology to then examine vendors and service providers who appear to have broadly identical capabilities and value propositions.  How do they decide the best way to take their first steps into cloud computing? It’ll be interesting to see what our REPAMA studies say about how each of the vendors/service providers’ takes their products to market.

Anyway, I’ve uploaded a set of slides to slideshare.net which I think is probably the best way to make the material available but if anyone wants a copy of the slides please let me know. The slides are embedded below.

As I’ve said before, this segmentation model will undoubtedly develop and change over time as I look in more detail at the marketing efforts of the various vendors involved. The definitions for each of the functional areas are a little woolly right now. But at least I now have a structure that allows me to decide which segments and vendors/service providers I will include in our studies moving forward.

I’d like to once again acknowledge the significant role that Brad Buck, Peter Laird and Christofer Hoff played in helping to form the ideas on market segmentation and the role NIST has played in crystallising definitions on cloud computing and software/platform/infrastructure as a service.

Danny Goodall

Products and vendors included in the segmentation model are shown below. If you represent a vendor below and I haven’t represented your organisation correctly, or if you represent a vendor that isn’t included but should be, please contact me and let me know a little bit about your company and your proposition and where you feel you fit in the segmentation model.

10Gen MongoDB, 3Tera App Logic, Aconex, Advologix, Altor Networks, Amazon EBS, Amazon EC2, Amazon S3, Amazon SimpleDB, Amazon SQS, Amitive, Apache CouchDB, Apache HBase, Appian Anywhere, Appistry, AppJet, AppNexus, AppZero, Aptana, Aria Systems, Aster DB, Beam4d, Beowulf, Blink Logic, Boomi, Box.net, Bungee Labs Connect, Caspio, Cassandra, Cast Iron, Clickability, Cloud42, Cloud9 Analytics, CloudFoundry, CloudStatus, ClusterSeven, CohesiveFT, CohesiveFT VPN Cubed, ColdLight Neuron, Collabnet, Concur, CrownPoint, CTERA, CTERA Portal, DataSynapse, Desktoptwo, DirectLaw, DocLanding, DropBox, Dynamsoft, Dynect, Elastichosts, Elastra, EMC Atmos, Engine Yard, Enomaly Enomalism, enStratus, Etelos, Eucalyptus, eVapt, FathomDB, Fios, Flexiscale, Force.com, Gemstore Gemfire, Gigaspaces, Globus Toolkit, gnip, Google App Engine, Google Apps, Google BigTable, GridLayer, Hadoop, Hosting.com CloudNine, HubSpan, Hyperic, Hypertable, IBM Lotus Live, iCIMS, InfoBright, Informatica iTRICITY, Joyent Accelerators, JungleDisk, K2 Analytics, Kaavo, Knowledge TreeLive, LayeredTech, LiveOps, LoadStorm, LogiXML, LongJump, LucidEra, memcached, Mercury, mezeo software, Microsoft BizTalk Services, Microsoft SDS, Mosso Cloud Files, Mosso Cloud Servers, Mosso Cloud Sites, Mozy, MS Azure Services Platform, MSDynamics, MuleSource Mule OnDemand, NetDocuments, NetSuite, NewRelic, Ning, Nirvanix, Oco, Open.ControlTier, OpenCloud, opencrowd, OpenNebula, OpenQRM, OpenRSM, OpSource, OpSource Connect, Oracle Coherence, Oracle On Demand, Panaroma, Parallels, ParaScale, Parature, PingIdentity, PivotLink, Platform, Qrimp, Quantivo, Questys, rackspacecloud, Redi2, Reductive Labs Puppet, Responsys, Rightnow, RightScale, Rollbase, rPath, Salesforce.com, Scalr, Sertifi, Serve Path GoGrid, SkyTap, SnapLogic, SnapLogic SaaS Solution Packs, SOASTA, SpringCM, Sterna, StreetSmarts, Success Metrics, Sun Grid Engine, Symplified, Syncplicity, Taleo, TerraCotta, Terremark, TIBCO Silver, Tokyo Cabinet, Trigence, Vertica, VMWare vSphere, Vordel, Workday, Workxpress, Xactly, Xero, Xeround, Xythos, Ylastic, Zembly, Zmanda, Zmanda Cloud Backup, Zoho, Zuora, Mezeo Software, Workxpress, Trigence, AppZero, Platform, OneNetwork, SpringSource, Vaultscape

Continuing my quest to segment the cloud computing market, I’m now looking at the role a channel might play in cloud computing…

…and I’m struggling a little to map the traditional channel role onto cloud. But here are my current thoughts.

There are some obvious areas in the cloud taxonomy/segmentation that look like a good old fashioned software sales model. So first let’s start with my draft / work in progress taxonomy/segmentation to help anchor the discussions in something solid. BTW draft/work in progress means that it will change.

Cloud Software

So the Cloud Software segment looks like a traditional software business. Using Brad Buck’s definition for this segment:

Cloud Software is off-the-shelf software that can be used to create an internal cloud or in some cases can be used to customise infrastructure services to mould a customer cloud solution.

Although Brad implies this, I’d extend that even further to say that cloud software will be the basis upon which infrastructure service providers build, host, manage, secure, monitor, etc. their own infrastructure services. So as this is real software being sold to real organisations the channel model I’ve come up with looks familar.

Software is sold to an organisation either directly or through some form of reseller/distribution channel. The end user IT organisation making the purchase either creates a cloud on their own premises for internal use (internal cloud) or a cloud service provider uses the cloud software to create a cloud service which is then made available to others.

Software Services

Looking at the software services segment, the definition here is

Software services are applications or components that can be used as an end application or used as part of a custom solution

So we have packaged applications or application components of varying degrees of complexity made available to application users directly by the software services provider. Application builders will incorporate some of these software services into their own applications which are tailored and then made available to application users – thus forming one channel to market.

The draft channel model I see there is as shown below:

Here we see that the application user is the ultimate consumer of the software service and that they are likely to consume that directly via the software service provider or via a third party application builder that modifies and extends the software service.

Platform Services

Broadly similar to the platform as a service definition, this segment is defined here specifically as:

Platform services offer a ready built infrastructure and application framework than can be used for building and running applications.

Platform services provide the frameworks in which applications can be built, tested and run. The application user is ultimately the end consumer of the service but some form of application builder will have used the platform service to make the application available to the user as shown below:

There is an argument here that the strict consumer of the platform service is the application builder who then makes the application available to the application user as a software service model. I need to think about this a little more before I cast this section in stone.

Infrastructure Services

Finally the infrastructure services segment is defined as:

Infrastructure services provide building blocks that can be moulded to run different application servers, packaged applications, grids, etc., which can be used to host applications.

These are basic data centre-like hardware, software and network elements that are provided as building blocks upon which software services and platform services can be deployed. In addition end user IT organisations also procure infrastructure services directly and then deploy their own software on to it, treating it as a virtual part of their own infrastructure.

This means that the channel model for infrastructure services looks like this:

Implied Channel Hierarchy

There is an implied channel hierarchy as shown in the diagram below but this is not always strictly followed. The diagram suggests that each level of service provider engages the services of the higher level service provider.

Whilst this certainly will be the deployment model for many cloud users it will not always be the the case. For example whilst it might make academic sense to assume that software services are built and made available using platform services which are then deployed in infrastructure services, in reality services at each level can be provisioned and delivered autonomously without the need for a relationship with providers at any of the other levels.

Conclusion

Well I can’t say that I’ve reached any sort of conclusion yet but I think getting these drafts down on paper has helped me think about the way that the IT industry’s traditional channel models will change over the coming years. I think it’s clear that we will either have less “middle-men” in our sales models or that the roles of these middle-men will change significantly as cloud computing becomes more prevalent.

OK, so back to the segmentation exercise. Next I need to decide on the candidate sub-segments within the major segments explored above. And then I need to decide on which vendors will appear in each of those sub-segments. Finally I need to decide which segments, sub-segments and vendors/providers will be the focus of our cloud computing REPAMA research. I’ll keep you posted on my progress.

The  DRAFT Channel Models for Cloud Computing presentation from which the diagrams above have been extracted is shown below.

I’d like to once again acknowledge the significant role that Brad Buck, Peter Laird and Christofer Hoff played in helping to form the ideas on market segmentation.

Danny Goodall

As mentioned earlier in these pages I’m documenting my quest to arrive at a market segmentation model of the cloud computing market. This will allow me to perform a series of REPAMA competitive marketing studies into various vendors in the cloud computing space. I’m uncovering more and more interesting research as I go and one such piece is described below.

The smart people at NIST (The US Governmental agency responsible for something or other – standards I think) have released some interesting work on cloud computing. Aimed at reaching a common set of definitions around cloud computing and its use cases, but recognising that these will change over time, their work can be found here.

I’ve reproduced some sections below because I think they add something to my quest to segment the cloud computing market. That said, I think they’ve omitted, perhaps consciously, an important characteristic and that is the commercial arrangements around cloud computing – namely its pay per use nature.

Anyway here goes:

A Definition of Cloud Computing:

Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability and is composed of five essential characteristics, three service models, and four deployment models.

Essential Characteristics of Cloud Computing

On-demand self-service. A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with each service’s provider.

Broad network access. Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

Resource pooling. The provider’s computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. There is a sense of location independence in that the customer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter). Examples of resources include storage, processing, memory, network bandwidth, and virtual machines.

Rapid elasticity. Capabilities can be rapidly and elastically provisioned, in some cases automatically, to quickly scale out and rapidly released to quickly scale in. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be purchased in any quantity at any time.

Measured Service. Cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported providing transparency for both the provider and consumer of the utilized service.

Service Models:

Cloud Software as a Service (SaaS). The capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure. The applications are accessible from various client devices through a thin client interface such as a web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

Cloud Platform as a Service (PaaS). The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly application hosting environment configurations.

Cloud Infrastructure as a Service (IaaS). The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, deployed applications, and possibly limited control of select networking components (e.g., host firewalls).

Deployment Models:

Private cloud. The cloud infrastructure is operated solely for an organization. It may be managed by the organization or a third party and may exist on premise or off premise.

Community cloud. The cloud infrastructure is shared by several organizations and supports a specific community that has shared concerns (e.g., mission, security requirements, policy, and compliance considerations). It may be managed by the organizations or a third party and may exist on premise or off premise.

Public cloud. The cloud infrastructure is made available to the general public or a large industry group and is owned by an organization selling cloud services.

Hybrid cloud. The cloud infrastructure is a composition of two or more clouds (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load-balancing between clouds).

I think this is a really nice and compact definition of cloud computing it characteristics and use cases. I particularly like the notes on deployment models which I certainly want to incorporate into my cloud computing market segmentation.

Kudos to Peter Mell and Tim Grance of NIST!

Danny Goodall

Just a quick note to say that I’ve updated the Lustratus REPAMA Guide to version 1.1. I’ve added three more studies that have been part of our analysis for some time but hadn’t quite found their way into the guide.

These are:

• Depositioning focus
• Differentiation strategy
• Perceived threat

All of these studies are concerned with interpreting how the vendors under scrutiny approach competitive differentiation in one way or another and are now explained in the guide.

The Lustratus REPAMA guide is available for download, and for the first time in HTML format. Click here for more information.

In putting together our REPAMA analysis into the go-to-market strategies of the vendors in the cloud computing space, we first must arrive at an agreed segmentation of the market. This blog documents that process.

OK so as I mentioned here, I am going to carry out a series of REPAMA Segment Analysis Studies into the cloud computing market. The desired end product is a series of reverse-engineered go-to-market strategies for a set of vendors in each of the categories within the cloud computing market. But first I need to decide on the segmentation of the various technical offers in the cloud computing space.  After that I need to decide which vendors fit into each of the different proposition segments. This series of blogs will capture my journey through this analysis.

Where to start? Well I thought that my colleagues Steve Craggs and Ronan Bradley at Lustratus Research (the market analyst part of Lustratus) would be able to give me a definitive answer on the segmentation of the cloud computing market but as Steve told me, right now there isn’t a universally agreed way of describing the various categories of propositions under the cloud computing banner. Whilst he feels their are some obvious high-level classifications, under there things are a bit grey.

The problem is two-fold. Firstly, it appears that as the cloud computing market is currently at an early stage (albeit using what now are some pretty mature technologies); the propositions have grown, merged, change direction and are only now starting to find live customers amongst enterprises; so categorisation has proved difficult.  Secondly, the analysts involved in this space each has a vested interest in classifying the market on their terms and importantly in a different way to their analyst competitors – a game they will play until the market matures.

So I decided that I would capture the opinion of the great and the good of analysts and vendors alike and come up with our own classification. And in doing this a number of existing works stood out.

1. Peter Lairds – On-Demand Blog Classification

Peter Laird’s “Laird On-Demand blog“, and in particular this post, documents his efforts to arrive at a market taxonomy for Cloud Computing together with a nascent list of the vendors that fit into each category. As you can see from the diagram on the right, Peter is a fellow fan of mind mapping (it’s how Lustratus collects, collates and generally makes sense of the raw data behind the REPAMA studies), his classification has a simplistic appeal that I like.

At the highest level Peter divides the cloud market into

• Infrastructure
• Platform
• Services
• Applications

I feel that this a good way of looking at the cloud market and one that works well for my purposes. I also like the way Peter has classified private and public cloud seperately.  From the perspective of the REPAMA analysis I will be conducting, this is an important distinction between the various vendors’ propositions. (This despite the fact that the same software and vendors may appear in both categories).

2. OpenCrowd Taxonomy

Another interesting approach is provided by OpenCrowd.  I don’t know OpenCrowd but they appear to be a RIA vendor but also deep thinkers who really understand the major trends in the markets in which they compete. They’ve looked at cloud computing and have come up with a very thorough classification as shown in the diagram on the right.

They see the market also categorised into 4 high-level categories:

• Infrastructure Services
• Cloud Software
• Platform Services
• Software Services

OpenCrowd has also gone to considerable effort to sub-categorise these high-level categories and also to identify specific vendors associated with those sub-categories. Again I like this approach for its thoroughness although having looked at some of the vendors in each of the categories, its clear that they have been placed there/asked to be placed there simply because they want to bask in the reflected glory of the cloud computing market, as opposed to having a dedicated or specific cloud focus.

3. Christofer Hoff’s Cloud Model

Finally, a more technical classification comes from Christofer Hoff in his highly entertaining and incredibly well thought out security-focused blog – Rational Survivability. In this entry Hoff publishes his architectural model which appears to be largely aimed at understanding the interaction, dependencies and relationships between the architectural components in a cloud architecture from a security perspective.

It’s useful to have an architectural model to work with as this helps to validate that the vendor-led offers into the cloud market as described above, have some basis in fact. Whilst it won’t figure in my market-led classifications I have added it here for completeness.

So I’m still in the process of collecting my ideas and I’d like to take bit of 1. and 2. above and merge them into something that better reflects the vendors’ perspectives of how they take their products to market. I also need to first ensure that both Peter and OpenCrowd are comfortable with me doing that. The model I arrive at will necessarily be far simplified too as for the purposes of my vendor to vendor comparisons, I need to ensure that I group vendors together that compete even if they don’t intellectually appear to fit into the same market categorisation.  Watch this space.

Danny Goodall.

• Infrastructure
  Public
  Private
  Infrastructure
  Platform
  Biz Users Platforms
  Dev Platforms
  Services
  Storage
  Integrate
  Enablers
  Applications

I have decided that the time is now right to take a detailed look at the marketing strategies and tactics adopted by the various vendors in the different market segments that make up the cloud computing market. This means that we’ll be carrying out a series of REPAMA Segment Analysis Studies to nail down how some of the vendors are taking their products to market. We’ve already looked at high-performance messaging, ESBs, BPM, Mainframe SOA and SOA adoption generally so now it’s the turn of cloud computing.

Lustratus has helped a number of cloud vendors with their go-to-market strategies and tactics over the last couple of years and one thing has been clear.  It has been a classic early market in that the protagonists were “selling” a technical proposition to technologists and not a great deal of actual business was being conducted. The market hadn’t fully formed and “sales” were not being made in a traditional way.

By that I mean that sales were being “bought” by vendors looking to gain early market share and the justification for most of these early market customer projects was typically R&D. But now the market seems to have found a bit of structure and organisations are starting to look seriously at cloud computing as a way of delivering on business imperatives, so now I feel the time is right to look at how vendors are lining up to address the market.  What are their value propositions, how are they positioned, why do they think they are unique and what features do they lead with?

All good questions, but where to start?

There are many different categories of offers and propositions all falling broadly under the banner of cloud computing and hundreds of different vendors that have aligned themselves with cloud computing.  Some of these vendors are using cloud as a cynical proposition slip-streaming exercise which I can’t blame them for:

Cloud is hot so let’s ensure we appear to have a proposition for cloud.

I would, and  indeed have done the same myself, but for the purposes of my analysis I’ll have to sort the wheat from the chaff. So first I need to do some preparatory work on proposition segmentation and the market taxonomy. In upcoming blogs I’ll share my thoughts on how that is shaping up and I’ll also start to share some of the early REPAMA findings as I go.

Danny Goodall

I hope you like the alliterative heading for the blog which was born from some work I’ve been doing recently for a client.  I’m not sure that diffident is exactly the right word but there was no way that I was going to ditch it when it looks so beautiful set against all those “diff” words.

Anyway, I was struck recently by the reluctance of some people to fully embrace the concept and importance of aggressive differentiation.  Whilst I’ve long understood that different types of people reach decisions about products (and lots of other things too) in different ways based on our bias towards one of the following psychological functions (Intuition, thinking, feeling and sensing), I’ve seldom before encountered this on the vendor side of the marketing battle.

I’m certainly not sitting in judgement on this.  On the contrary it has made me look carefully at the way I work with my clients moving forward.  My client has a very strong business and is growing at an incredible rate but they are starting to encounter stiff competition hence my involvement.  I’ve been working on strategies to help to grab a position in the market for them that will undermine their competitors and am pretty pleased with the results.  It’s been a great project and I’ve really enjoyed working with them, they are top people and have great products.  The problem lies in their reluctance to stick out their chest, beat the drum and proclaim their greatness.  They are, I guess you would say, corporately shy.

It made me dust off my copy of Differentiate or Die by Jack Trout to review the psychology of differentiation but this time from the perspective of the vendor.  It set me thinking there is no “one” way to build differentiation strategy.  Whilst it’s important to be able understand the behaviour of your target audience, it’s also important to ensure that you are happy with the chosen strategy and that it sits well with the philosophy and perhaps even the ideology of the company itself.

For example could Company A, staffed and populated by conservative and modest management feel comfortable going to market with a message of “We’re different from Company B because we do X better than them”?  It’s not an easy step for them to take.  The opposite of this would be to expect a vendor who really understands competitive differentiation such Oracle to say “Test our product and it will speak for itself”.  Whilst this might be true a company like Oracle will never turn up the opportunity to thrust the differentiation dagger into the chest of the competition.

Somewhere in the middle lies the truth I guess.  There is immense credibility, not to mention the moral high ground in looking to let your product win the battle for you.  But equally, aggressive marketing by aggressive competitors can cause you to be de-positioned in the eyes of your prospects such that they think they know where you are positioned and won’t even bother to evaluate the product.

So I’m going to cover this subject in a series of short blogs taking a look how differentiation works from a psychological perspective and how this translates into corporate psychology.

Danny Goodall.

Just a quick note to say that the updated High Performance Messaging REPAMA Segment Analysis Study has been uploaded to the Lustratus site.  It now contains the reverse-engineered product marketing strategy for TIBCO’s Messaging Appliance P-7500.  Existing customers and Lustratus research subscription holders will already have been contacted with details of free upgrades.

Following on from the blog entry I made when the first version of the report was released I thought I’d show the updated value proposition below.  As I mentioned in a previous blog entry TIBCO’s primary competitive focus is very unusual – it is TIBCO Rendezvous – one of its own products.  The different approach to the market doesn’t stop there as you’ll see from the report extract below.  TIBCO also plough its own furrow by taking a different proposition to the market when compared with most of their competitors.  This one based around green IT and data centre costs (in addition to the obligatory low latency = competitive advantage proposition).

For more information on the REPAMA methodology visit here.

Danny Goodall.