This could also be part of marketing or evangelizing software, but speaks of what to avoid.
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.