Enterprise social networks : focus on philosophy, not technology

philosophieI recently had a long discussion on how to choose an ESN (enterprise social network). Of course, many people in the conversation suggested to do it in a well-known and mastered fashion : functional specifications, scorecards etc. Rational, exhaustive, reassuring. When my turn came to share my experience I could not fully agree with them. Not because such approaches lead to nowhere but because the place they lead to is seldom the place one should have headed to.

An ESN does nothing but empowers people to do things

An ESN, and more globally any enterprise social software solution, is very different from many solutions we’re used to. One of the differences (and not the least one) is that we’re used to choose tools that do things, that were turning inputs into outputs. ESNs does not transform anything but empower users to do things. That’s a slight difference but a difference that is a game changer. One can’t assess an ESN by listing its functionalities but by assessing the way they’re put at work, implemented and the resulting user journey, by assessing how easy it becomes to meet an objective, to do the “job-to-be-done“.So I often see a long list of functionalities which existence has to be checked. It’s useless. First because it says nothing about the way they combine one with another in the user journey. Then because such a list is the result of the functional transcription of an operational need, made by people who know very few about the matter, making guilty approximations. Such need = blog. Such need = wiki. And the blog must do this or that. At the end, some products are dismissed because they put things at work in a new fashion, in a way that was not in the mindset of the people who wrote the specifications while they were perfect to do the job(s) to be done. And others solutions are chosen because they have the right functionalities while they won’t help anyone to get things done in a more effective way and will not be adopted.

It’s like Ford saying “If I had asked people what they wanted, they would have said faster horses.” That’s what often happen : people ask faster others and dismiss vendors who come with a car.

In brief, choosing a social solution this way, as reassuring as it is, help to choose the tool that almost do what’s needed but not to choose a tool that does things the right way, making things meaningful and simpler.

A merely functional approach to ESNs leads to nowhere

In my humble opinion, the only question a vendor should be asked is “show me how to do this or that”. A series of actions with a purpose, coherence of  the sequence etc. Of course the 1450 lines spreadsheet is more impressive and show one’s boss that a tough work has been done but it’s time consuming and does not guarantee success. A good way to cover one’s ass, not to achieve an objective.

At the end, it’s the best way to end with a very popular scene : users saying “it does not match my use cases” and others replying “yes it does…we provideed you with all the needed functionalities”.

That said, most of the solutions on the market are looking the same. At the beginning each vendor followed his own track but experience made visions converge and the best ones are now offering slightly the same things. What one lacks is balanced by a killer feature no other has and, anyway, what lacks will come in the next version, after all the competitors have benchmarked what the others are doing and listened to their customers. And at the end there’s nothing differentiating here : functionalities are nothing outside of the user journey, without any consideration to the job-to-be-done.

The only thing that’s unique is the philosophy of the tool. What prevailed when it was first designed and marketed. That’s what made tools different in their early age and explains why such a functionality is implemented in such or such way depending on the vendor, explains why a given feature will or won’t be implemented in a close future. From my point of view, regarding to a business need and an enterprise context, that’s what’s key to a credible short list without spending 6 months filling spreadsheets that won’t help.

Philosophy is what will make a solution more open and integrable than another, more or less process or conversation oriented, more or less structured,  providing  advanced analytics or not, and drive the roadmap in a direction or another.

A solution’s DNA matters more than functionalities

What make solutions different today is not functional : it’s the conviction that prevailed when the solution has been conceived and deeply impacts its DNA even years after. In some cases things started with a CMS that was improved with social functionalities to look trendy but the product will always have the DNA of a CMS. Others started with workspaces and libraries with strict arborescences and right management and will never manage to become fully transverse, nimble, flexible because rigidity has been hard-coded in their DNA from the very first days. Others started with the assumption that conversations will replace documents and processes, others were convinced that everything was about communities and struggle to bridge the gap with business applications and are not comfortable with approaches based on individual productivity.

No one is better than the other (except if the execution is very poor). But depending on a need, on the context, on a priority, one will fit better than others, a philosophy will be more relevant than another.

In some ways the work on “adoption” starts here : making sure the tool philosophy matches the need instead of filling endless spreadsheets with functional requirements. With hindsight we can often see to what extent the choice of a given solution is a proof of maturity and shows what businesses are really willing to transform themselves or not.

Don’t try to compare solutions if you don’t understand they History

Choosing solution is like choosing a use case and management philosophy and, even within a product category like “enterprise social software”, there are big differences between products, differences that a functional approach will never highlight or will interpret in an irrelevant way.

As I said about the Real Story Group report, it’s impossible to compare tools without understanding their DNA, their history, paradigm except if you find relevant to compare apples with bananas.

Pin It
 
  • Ana Neves

    This is soooo true, Bertrand! I was reading your post and kicking myself for not ever having been able to spell it out so clearly.

    What you say above is exactly what motivated me to design Social Now: it’s an event where you can see the tools in action, answering specific business requirements, for a factual (*) company. You’re not being sold a list of features: you’re being inspired by how the tools can help you and by the type of work processes it allows your company to use.

    (*) “Factual” was a word I heard from Paul Corney (@PaulJCorney) and which means fictional but totally based on real facts ;)

  • christophschmaltz

    I fully agree with your views, Bertrand. I have seen my fair share of spreadsheets of functional specs. Once a client gave me a list of specs with the request to evaluate SharePoint 2010 against them. The spreadsheet mentioned things like ‘does the application provide blogging functionality’ or ‘A user needs to be able to move files to another folders’. Heck yes, SP2010 provides that, but its use is cumbersome because of poor user experience.

    Recently, I was involved in the selection of a CMS for a large international company. I first drew up a list of hard requirements (SaaS vs on-premises, license costs, extendability, potential risks involved with the vendor/system etc) to come to a short-list. Based on conversations with end-users I then drafted user scenarios that explained the most important workflows (creating, editing and publishing articles or organising media assets). These user scenarios were used to evaluate the short-listed systems. By trying to implement the user scenarios in the actual systems we were able to see what system would be a good fit for end-users. We were also evaluate the amount of customisation needed for certain systems, which often can go way beyond the initial license cost!

    Last year Ana Neves invited me to her conference Social Now that she mentions below. It was a valuable experience to see software vendors not simply listing and praising functionality of their products but showcasing how they solve predefined user scenarios (by Ana and her team). That’s how the audience got a real feel for the different solutions. I think this model of presenting software is examplary and should be used at other conferences.

  • kommbox

    This is absolutely true.

    A very common use scenario in an enterprise is to create a long list of features, go for a feature-rich (or feature-heavy?) product based on this list, and then dump it in a matter of months when it is found that the product actually complicates life instead of simplifying it. For this reason, we would tag this article as a must-read for enterprises before going for any communication tool.

    We have been studying this area and the products (including our own). There are many different philosophies at work here. It’s very important to see that these philosophies are more important than the features. Thanks for bringing it up.