Recently, Julien LeNestour, from the IT Innovation Lab of Schlumberger, wrote an interesting and debated post on enterprise social computing pricing @ ReadWriteWeb. He suggested me to contribute to the conversation, but it turns out that I need more than a comment slot to do so. So read his post before reading below.

Initially I want to give a bit of background. I know Julien. He was a Headshift client that I personally catered and we happen to be friend. Julien has a background in software development, but from a socio-economic side. He has a keen interest in finance and a true ability to capture meanings contained in formulas and graphs. He is bright, highly educated and talented. He follows with attention the social computing scene for a while now, and contributes to some first class conferences. He is discreet, but as underground South London people say: he is a “face”. He blogs @ MacroPrinciples.

Julien’s approach is interesting as he addresses the pricing policy of the software companies. It is interesting because it is very singular, while it is in fact a key element of decision making. Usually, the majority of us talk about features, implementation in a social environment (the organization) or function covered. We sometimes talk about ROI, but never about the price / cost of the software. It is a taken-for-granted conversation. I’m glad Julien opens the conversation.

Now, back to his post.

“Every product bearing what is usually dubbed a “social component” has significant network effect and peer production dynamics. The more employees actively use the application, the more they — and so their organization — extract value out of its use. Marginal benefit per user, and hence total value, thus increases with the number of active users. Yet, most pricing structure are degressive, Volume-Discount schemes: price per user decreases with the number of users. Price and value varies in opposite ways:

What happens here is a total reversal of what should be aligned: the more employees use the system, the more value you get out of it per user, the less you pay. And the less users you have, the less value you get, the more you pay. This explains both the refusal of lots of companies to pilot new technologies, and the difficulty to transition from pilots to full deployment: if you can’t do it in one shot, the economics will be much less in your favor to do it in a phased way.”

Fundamentally, Julien makes the assumption that Enterprise Social Computing offering is all about product offering. Given where I come from, this is in my opinion a very reductive approach.

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.
In a traditional software, the know-how is inside the product and is usually protected by a patent. In social computing software, the know-how is outside the product.
Take the example of the wiki. As a product, it is a simple blank page that is easily editable from the web browser. Now, transforming the wiki into a platform for collaboration by building relevant template is where the value is. And experience shows that most of the time, the know-how is lacking which leads to poor implementations and deception among both end users and decision makers. The lack of know-how is the principal reason for aborted adoption of enterprise social computing.
As a result, the pilot phase is actually the most expensive phase. It is where one injects know-how and meaning. Post pilot costs are just deployment costs and, sometimes, additional customization.

“This means that, with classic Volume-Discount pricing structures, companies will usually have the choice between a full deployment or no deployment. Deploying on a smaller scale would decrease the ROI significantly as it lowers the value and increases the costs. Unfortunately, what this means is that disruptive innovations, where the value is by definition not obvious for stakeholders, and where it usually emerges from early adopters experience, are very difficult to successfully transition from pilots to production. They would need a phased deployment, starting small and scaling up progressively, that is not profitable with a Volume-Discount price scale.”

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. To illustrate: they are the flesh around the bones.

That’s why they have a network effect as Julien rightly noted, but that is also why the logic of applying the network approach to pricing is difficult.
1.    One approach is the game theory that Jean-Lou Dupont uses on RWW: “it only takes *one* detractor (i.e. someone who sells an equivalent service at better price… that’s what competition is for, no?) to make this theoretical model fall down” (tainted with falsficationism I agree).
2.    A second approach is purely organizational. There is no relevant reporting or analytics process in place to monitor and evaluate the value those tools have. Despite all the money thrown in ERPs, reporting processes and reporting people the organization is blind. Properly put: Managers are blind. They have no clue of what really happens. They have not changed their metrics and KPIs for years. Most of them keep on focusing on numbers (as “facts”) and short term bottom line. They keep on measuring the performance in a knowledge-based economy with the instrumentation of the industrial era. This is the principal reason why pricing/licensing need to be capped at some point (or so far … if we are not too lazy). One of the fundamental lesson of scientific work is that discovery is bound by instrumentation, which is bound by sensemaking. “Thoughts precedes matters”; we have to learn from Galileo Galilei (and stop just praising him).

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.

In fact, it is a question of perspective (sensemaking) and methodology. As in charge of innovation, Julien is in a position to go for pilots, which means that he is in a position to search for and interact with the “correct group” to build a successful (or not) use case. That’s empiricism. This would help him get a sense of the impact the pilot might have at a larger scale, as well as the difficulties of pre-requisites for a successful implementation (with enterprise-wide in mind on the term).

Now, if as Julien you want to pursue with the product approach for pricing, you might want to look more into details the business models of software “companies”. Pricing is rooted into the way company pretend to make money.

 This opens the door to understanding that Julien addresses in fact only one type of revenue generation, the most traditional in the software industry.

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

More deeply, Julien’s post post highlights the fact that there is a de-correlation between cost and value. Reason why some people like Lorino, a renowned French researcher on accounting at ESSEC (and a key member of my PhD crew), moved away from cost analysis to value analysis. In fact, this de-correlation between cost and value is the accounting acknowledgment of the true mutation of work and the dematerialization of capital as the prominence of reasoning (over execution) positions knowledge as a key economic factor (see here for a detailed explanation).

Julien these were my 2 cents, happy to discuss this further.