Blog

When writ­ing blog posts, we usu­ally reply to one or sev­eral other posts, quot­ing at most 2–3 extracts of them. In emails, it is fairly com­mon to keep reply­ing and artic­u­lat­ing refine­ments as fur­ther thoughts are spurred. Why don’t we do it on blogs as well? I don’t know, but I’ll try here, and it may prove inter­est­ing. Let me know what you think, pos­i­tive or negative ;-)

I recently asked Olivier Amp­rimo to exam­ine my argu­ment around pric­ing for Enter­prise Social Com­put­ing offer­ings. He kindly did it with an excel­lent post, so this is my reply, a bit in the spirit of old-fashioned cor­re­spon­dence. Olivier gave some back­ground info in his post, and let’s just add that I have rarely wit­nessed such deep thinking—his blog is full of excel­lent mate­r­ial as well. Obvi­ously, there is much more in Olivier’s analy­sis, than the points I reply on here. (You may want to read the post Olivier scru­ti­nize, then his before this one)

Let’s start with a basic typol­ogy. There are at least 4 dif­fer­ent types of Enter­prise Social Com­put­ing offer­ings, each enabling a dif­fer­ent set of capa­bil­i­ties for the organization:

1. A core foun­da­tional plat­form for enter­prise social net­work­ing: think of it as Face­book or LinkedIn redux inside an orga­ni­za­tion. Employ­ees have rich pro­files, explicit con­nec­tions, an activ­ity stream tied to their net­work and an open archi­tec­ture allow­ing to pull activ­i­ties from the exist­ing busi­ness sys­tems. News­ga­tor is an excel­lent example.
2. Spe­cific but corporate-wide tools avail­able to all employ­ees: here we have the Twitter-likes, Youtube-likes, etc.
3. Per­sis­tent, large-community, but not corporate-wide social tools: wikis, blogs, and so on used by spe­cific and per­sis­tent com­mu­ni­ties. Tra­di­tional com­mu­ni­ties of prac­tice exem­plify this type of needs.
4. Per­ish­able social tools used by focused teams, usu­ally project or busi­ness teams: these are the wikis used within teams to pre­pare the busi­ness doc­u­ments for exam­ple, a Team­Space if using Share­Point, etc.

Onto Olivier’s post:

http://venividiluxi.com/en/?p=96“>

Fundamentally, Julien makes the assumption that Enterprise Social Computing offering is all about product offering.[...]

An Enterprise Social Computing pilot is not about testing an off the shelf solution, it is about building a contextual platform, with mashups and tweaks. Yes, convergence happens in the social computing software. Products are embarking more and more features. Lines are getting unclear between blogs, wikis, social networks and … But there is no off-the-shelf social stack. The most expensive is therefore not the software; it is its implementation. It is not the product; it is the know-how and the sensemaking.

When testing offerings falling in Types 2, 3 or 4, I would agree. But the license fees for a good platform, even for a pilot period are important and rival the implementation costs. While there is no off-the-shelf social stack, organizations need to start with the best possible platform (best is highly contextualized to each organization). Often times, the fees for this kind of platform, with a regular volume-discount pricing, are taking up a good proportion of the budget. Even if just equal to implementation costs, license costs are material in launch decisions.

http://venividiluxi.com/en/?p=96“>

As a result, the pilot phase is actu­ally the most expen­sive phase. It is where one injects know-how and mean­ing. Post pilot costs are just deploy­ment costs and, some­times, addi­tional customization.

My point exactly. As Olivier says, pilots are already incred­i­bly expen­sive in terms of know-how. If you pile high license fees on top of it, as you do when using volume-discount pric­ing, then the cost of the pilot explodes along with the risks, and the poten­tial ROI of a full deploy­ment sinks. Hence my argu­ing for very low pric­ing for a pilot, essen­tially cost-offsetting, before increas­ing the pric­ing as usage increases.

http://venividiluxi.com/en/?p=96“>Julien makes the assumption of a standard and enterprise-wide deployment, upfront. This works well with traditional (non-social/individual) client applications (such as office) or with Enterprise-wide process applications (such as an ERP or a CRM). The problem is that there are hardly any standard and enterprise wide deployments of social computing, upfront. Social computing tools are not addressing the same issues as traditional IT ones. The deployment is progressive as social computing tools address contextual and previously implicit interactions around explicit, usually enterprise-wide processes.

We disagree on this point, and here’s why: even though any deployment will be phased, the business case is built with the sought-after end in mine: a global deployment. Pilots are for tasting the water. Generally cheap in terms of funds, always expensive in terms of resources. Clients don’t test technology stacks without being assured they will be able to deploy if they want to. Hence, they negotiate and lock pricing in before they start the pilot. If they don’t, the price will unfortunately have doubled when they want to pursue ;-)

http://venividiluxi.com/en/?p=96“>That’s why they have a net­work effect as Julien rightly noted, but that is also why the logic of apply­ing the net­work approach to pric­ing is dif­fi­cult.

1.    One approach is the game the­ory that Jean-Lou Dupont uses on RWW: “it only takes *one* detrac­tor (i.e. some­one who sells an equiv­a­lent ser­vice at bet­ter price… that’s what com­pe­ti­tion is for, no?) to make this the­o­ret­i­cal model fall down”.

Some­how I fail to see how the incen­tives work that way. Volume-increasing pricing:

• is not chang­ing the total cost (for the client) or total rev­enue (for the ven­dor). It sim­ply changes how it’s vary­ing over time. The Total Cost of Own­er­ship when fully deployed is the same.
• makes ini­tial pric­ing per user very low and even free when the rea­son­ing is applied 100%. How a com­peti­tor or free-rider can emerge in this context?

http://venividiluxi.com/en/?p=96“>

As a result, if you have to play with curves, you might want to play with the Long Tail. Because what social computing caters is the long tail behind the firewall.
Read further a previous post of mine.

Slide 12 of Julien’s enclosed scribd-ed KeyNote presentation, he states that “it is important for the client to make it available to all its employees: which groups of employees will recognize its value first is unknown, and you may not target the correct group if you do a target deployment”.
Julien works in an environment that is very specific, yet common. He is entrenched in IT (that is used to think “product’) and at a corporate level (that is far from operations, which happens to be very true in his industry). The combination seems to let him thinks about standard products that are easily deployable top down. One size fits all. Experience shows it tends to be time consuming, financially costly, operationally disturbing and employee frightening.

Back to my opening typology: for a corporate-wide enterprise social networking foundational platform, 1 platform is needed, not several living together. For specific but corporate tools, one standard tool is also needed. If organizations want to share videos internally, they are looking for one Youtube-like tool, not many which will compete for a critical mass in the knowledge pool built. For type 3, persistent tools, standardizing the platforms also ease the burden on the user by avoiding using different wiki tools when switching wikis for example. Not to mention on IT, I know :-) Only for Type 4 social tools can this be envisioned.

But the ROI needs to be taken into account, and yes, there are two parts: returns and investments. Two different scenarios can be envisioned for deploying wikis used in teams for example:

1. Let users choose the wiki application best suited for their needs, and let they deploy and manage them on an ad-hoc basis.
2. Recognize the need for on-demand and fully customizable wikis, but enforce a standard tool to create them, like Atlassian’s Confluence.

In case 1, you offer full control to the end-users to choose the tool they want, but this would inevitably result in a costly mess to maintain. In case 2, 95% of the control is given back, but the tool is standard. The ROI will of course differ widely in the two cases. Standardizing always brings cost-savings, and can more and more be done without impacting the returns on the applications.

http://venividiluxi.com/en/?p=96“>

In fact, it is a ques­tion of per­spec­tive (sense­mak­ing) and method­ol­ogy. As in charge of inno­va­tion, Julien is in a posi­tion to go for pilots, which means that he is in a posi­tion to search for and inter­act with the “cor­rect group” to build a suc­cess­ful (or not) use case. That’s empiri­cism. This would help him get a sense of the impact the pilot might have at a larger scale, as well as the dif­fi­cul­ties of pre-requisites for a suc­cess­ful imple­men­ta­tion (with enterprise-wide in mind on the term).

This is easy to do when you’re look­ing at build­ing capa­bil­i­ties enabled by tools falling in type 3 and 4, and this is what most com­pa­nies do. How do you do it when you are look­ing to deploy an enter­prise social net­work­ing plat­form? A twitter-clone? Within large orga­ni­za­tions, whether or not you’re in IT, you can’t pos­si­bly know all the dif­fer­ent groups oper­at­ing with their own cul­ture, goals, processes, incen­tive struc­tures, etc. Tar­get­ing is use­ful but not opti­mal at all. If you tar­get, you may hit some “cor­rect groups”, but then again you may not. Even if you do it exactly the right way, facts of life within large orga­ni­za­tions can turn a cor­rect group into an incor­rect one at a high velocity.

The best strat­egy seems to be to com­mu­ni­cate and pub­li­cize the capa­bil­i­ties, then let the groups who would ben­e­fit from the tech­nol­ogy enablers use them.

http://venividiluxi.com/en/?p=96“>

A particularly interesting approach in this conversation is Atlassian’s pricing policy and business model. Atlassian has a traditional pricing structure in the software industry, to a certain point.
Atlassian plays on:

• Lowering the entrance barrier.

The price is below the usual amount of money that requires the workflow of informing a lot of people to get one signature, as well as many opportunities for loads of “why” and a “no” and is capped. People are thus empowered to test the product, customize it to cater local and contextual needs. By doing so they potentially build a usecase and start the grassroot movement below radars. The client becomes the reseller. But the pricing is made in a way that if the first year is affordable, the next year ones are more expensive that traditional software: 50% of the initial license (vs 10-20%), not to mention the adjustment of users. So in the end, on a 3 year basis, the cost of the software is not cheaper than traditional software, but the product is up and running and inhouse (so that it is too late to say NO!)

• Volume of portfolio.

Lowering the entrance barrier is the best way to have a large client base. And because the balance between first and next year is 2 to 1, the turnover of Atlassian grow substantially mechanically.

• Nice and robust products.

They are self-explanatory thanks to a meaningful interface, that embarks contextual help and an exhaustive help documentation one click away. As such, they require nor cost nor effort in the support and maintenance phase (n+1 and beyond) and ensure that Atlassian milks the cow, with style

Yes, Atlassian’s pricing is smart. But the cow they don’t milk. One condition such pricing works well is that the unlimited user license is still not highly priced. If it was, then we would not see the same acceptance of the products. Yet, it fails to capture the producer surplus it could when used in large organizations with per user pricing, albeit not the tired old way.

http://venividiluxi.com/en/?p=96“>

Julien these were my 2 cents, happy to dis­cuss this further.

I cer­tainly hope so, although you might want to avoid this cor­re­spon­dence style :-) Not sure how this works for readers…

Source: Enter­prise Social Com­put­ing Pric­ing: insight­ful, but you hardly see the woods for the trees