How to ruin any chance of your software’s success (if you are a Wiki Vendor)
Twitter
Facebook
Delicious
Digg
Stumble
Reddit
This could also be part of marketing or evangelizing software, but speaks of what to avoid.
If you are unfamiliar with Wikis, they are great tools to get your teams collaborating, however they have been particularly plagued by end-user adoption issues.
It is obvious why that is the case : You go into an office that is functioning well and start pitching technology (problem 1), you introduce a WHOLE NEW Concept of Wikis, something they have never heard of before (Problem 2).
What happens when they still aren’t sure about adopting your software? You make one of the biggest marketing blunders you can think of.
You make one of the most complex and technical user guide to Wikis that you can think of, and force it down people’s throats, as Confluence has done with www.wikipatterns.com
Why is this such a huge mistake? What is the point of promoting the flexibility of wikis, if you are forcing people to constrain themselves around definitions and terms that they dont want to learn!?
Isn’t that ironic? You say that Wikis will unleash bottom-up innovation by giving people freedom of expression within the enterprise, then force them to think one certain way about their people.
Now, can you imagine their salesman coming into your office with a pitch akin to “Well you will have a wiki, and identify your fairies, and trolls, and champions, and put in the Poker pattern to get things started” Huh!?
What if I just want to see who “gets” wikis in my team, and who “does not” and explore ways in which those people can make themselves more efficient using wikis?
This was a bad, bad move on Confluences part, and it does nothing but turn their leads further away.
How this case study relates to evangelism
It comes down to Lesson 1 we had earlier in this blog — do not start explaining something in technical terms, and rather focus on the benefits I can have in my workday with the software. Confluence could have done much better, but I wont explain how.
11:31 pm
A few counterpoints.
Customers have been asking for _ever_ for us to come up with some kind of “best practices” document for wiki adoption. We get a lot of feedback from people saying “I get wikis. I convinced my company to buy Confluence, my team use the wiki, but I can’t seem to get anyone else to play”.
Meanwhile, we had a bunch of material sitting around stagnating that Mike Cannon-Brookes gathered during his “Patterns of Wiki Adoption” session at RecentChangesCamp 2006. It seems dumb to sit on all that useful material because it may not be ‘commercially friendly’.
A common pattern of adoption that we see of Confluence is that it gets installed by technical people, and then spreads virally to the rest of the company. Providing those technical people with a tool that _speaks to them_, and that gives them good techniques to set up a wiki that both they want to use, and that everyone else will want to use, isn’t such a bad idea.
You use all sorts of strong language in this post: “force it down people’s throats”, “forcing people to constrain themselves”, “force them to think one certain way” that we’re simply not doing. We’re offering people in a situation we know is common a box of tools that might help them.
Wikipatterns isn’t a sales tool for Confluence. I doubt we’ll ever point anyone who’s not sure whether they want a wiki or not to wikipatterns. We are, in parallel, coming up with marketing materials for those folks showing the various ways in which a wiki can help different kinds of teams or companies. Wikipatterns was just ready first.
12:26 am
Charles,
Thanks for the clarifications.
I will admit I used strong language but it was based on some frustration. Let me tell you about our experience with wikis
We use a wiki within our company, but the first people to adopt it were HR and Marketing — they needed a tool to help them get organized in specific plans. From their success, Engineering and ITCOMM have automatically shifted to the tools. I would say our adoption has been smooth.
The road we took was to first identify areas of inefficiency in our work, and find tools that explicitly allowed us to gain in those areas without adding additional overheads and inefficiency. That is a straightforward approach that most operations consultants would take.
Now the important thing is that this is an implementation of a continual improvement process — the goal given to everyone is to improve their ops, and they themselves find a model that works for them. That is one of the reasons Wikis work for us, because they gave everyone a bottoms-up approach to modifying the wiki around their specific workflows.
In the end, they have vested interest in getting together to use the Wiki. What’s more, all we have had to do is constantly explore new ways of adjusting work models around wikis with the goal of improving the functions’ throughput.
So for us, people either “get it”, or “dont get it”, and if not, we just start doing Thought Experiments and workflow efficiency analysis with them.
For ITCOMM and Engineering, the shift is usually more straightforward — often because most good engineers are also well organized in my observation.
OK, so all that background aside, I will also admit that we still face some snags on our adoption roadmap — there are people who do not contribute as often, or do not follow the teams’ conventions or structure.
So I went to wikipatterns quite like you are hoping — to find answers to our adoption challenges.
To be honest, I spent 2 hours on it and all it did was give me a migrane. Even back in the hayday when I was designing satellite base-stations I didn’t see anything so technical as those patterns.
So obvious question is — why should I have to resort to drawing out a map of fairies and trolls or character profiles on a whiteboard before I can start getting enough clues to understand how to fix adoption issues?
If I am trying to find a human solution to a human problem, why start with patterns and character profiles to begin with?
I argue that in most of my consulting career I have not yet seen any technical people that have an influence in the day-to-day workflows of other functions. The only thing they can perhaps to do is Internal Marketing of Wikis (i.e. raise awareness).
However, the adoption decision for each department — in fact, each person — is based on understanding the benefit to me from using it.
So I argue that you should definitely look to your adoption patterns with a “sales oriented focus”. Call it post-deployment sales of the benefits of wikis to internal teams.
I also argue that even technical people will have a hard time actually adapting the Patterns to their specific situation. Even if there has been some good work done in identifying “Patterns” of behaviour, they should only be consumed by academic interests such as the study of social behaviour in the enterprise. I have my doubts that these patterns — atleast as they are — can be much useful.
There is no doubt that we need a “best practices for adoption” guide for wikis, but this is just the wrong approach. As I went there, if your customers are going to that website as a means of finding after-sales support, then they might just end up thinking “This company has no idea what my problems are”.
I am glad to know that you guys are working on a “marketing” version, but all I am arguing is that we need a “human” version first.
Don’t sell me on wikis, just help me understand them in language that I relate to… You are, after all, the person that introduced me (the average consumer) to it.