I 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.
