Successful Social Software Launches: Marketing vs. IT

I sat in on a good webinar sponsored by social software vendor Jive, maker of Clearspace in December. One of their users, a member of the Business Sales Team at T-Mobile who has been instrumental in setting up and managing a departmental implementation of Clearspace, presented. As I listened to Jenny Moran, Channel Manager, talk about the community they created, MagentaNation, it occurred to me: If marketing people launch and drive adoption of social software, is it on the whole likely to be more successful than if IT people deploy it?

I thought about this because this is what Jenny talked about:

• “Pull not push: “We did not push the site on people or force trainings”

• “Building excitement:” such as a very brief launch call, involving managers, and launching “exclusive” content here first

• “Maintaining excitement” by engaging users, for example, by posting videos and allowing anyone to post videos, by showing users how to make their own customized dashboard…

• “For the people, by the people:” a phrase she used more than once meaning that users helped design MagentaNation, seed it with content, and will continue to be actively consulted about usage.

All of this was marketing language, and more importantly was indicative of thinking about people’s behavior.

And driving adoption is all about thinking about behavior.

When I talked to Jenny in person and suggested that a marketing social software deployment might be more successful than an IT one, she seemed to agree but articulated it a bit differently. She felt that because Business Sales Support approached it from the user perspective, not the IT perspective, they were more flexible and they "let the community create itself." This is, I suppose, the number one marketing principle: “Give the customer what they want.”

It turns out that there is some data about user satisfaction with implementations by business (referred to below as LoB-Line of Business) users vs. IT implementations. Ross Mayfield of Socialtext recently posted this:

“According to this year's McKinsey survey on Building the Web 2.0 Enterprise, IT-driven implementations had 60% user dissatisfaction, whereas LoB-driven had 74% satisfaction."

---

About MagentaNation

Business issues that gave rise to creation of MagentaNation:

• Dissatisfaction in Business Sales with non-relevant content being pushed at them
• Lack of connection with other Business Sales members
• Need for vehicle for continuous learning and sharing of best practices

How the community created itself:

1. T-Mobile had a one month pilot in January ‘08, before they signed a contract, consisting of 15-20 people from different groups and levels in Business Sales Support, using the site and creating content.
   
2. Expanded outwards to 50 people, for a second month-long pilot.
   
3. Then each of those people invited one or two people, so 150-200 people were using the site and creating content.
   
4. In May, they launched to the Business Sales population of 700.
   

Usage statistics (from mid-May launch to beginning of December)

• 46,790 visits
• 275,243 pageviews
• 6+ minutes average time spent on site
• @6 page views per visit
• 97% of the Business Sales group is registered
• Now, over 90% of Business Sales members log on at least once a month
• Stats for 2 random days: Friday: 10 posts, Monday (by 11:30 a.m.): 7 posts

Customizations

• Leadership widget showing picture of leader and latest activity
• Video widget for latest videos posted
• Scrolling ticker with important news

What do the two people who manage the community do?

• Help drive engagement within the community
• Review site content, moderate (rarely have needed to "moderate," occasionally coach users, Jenny repeatedly stressed that the community was for users so moderation with the lightest touch possible was key)
• Help answer questions
• Administrate

How many hours do the managers work on MagentaNation?

• Channel Manager: Approximately 20 hours per week
• Q&A counterpart: Approximately 10-15 hours per week

Looking forward to...

• Live chat, which Jive should release next year
  

For two screenshots of the site, see slides 10 and 11 of the presentation.

What’s the “Best” Wiki?

When I show people my introductory presentation on wikis often the first question I’m asked is. Well, then, what wiki should I get? What’s the “best” wiki?

In the Winter of 2008/9 there is no such thing as the “best” wiki or the “best” "collaborative software suite." Each platform offers different capabilities and appears to have different strengths.

What’s important is to match your organization’s requirements with a platform.

• You could think about what collaborative software capabilities are of most importance to you, and then figure out which platforms have them. I list the most obvious ones in the post before this one.

But there are lots of other things to consider as well, which ultimately may be more important.

• Beyond your tech requirements (which can include simple things like we want a platform that is installed on our server, or more specific issues like programming language, security features) there are dozens of features you’ll want to look at: things like what level of permissioning you need, notification functionality, document versioning, ease of use, quality and type of support, tagging capability, export capability—the list can be very long.

• Wikimatrix is a good place to start to narrow down options. You can perform a customized search on attributes critical to your organization. Just know that not all information on Wikimatrix is up-to-date or accurate—check out particulars on the vendors’ websites. (Potential inaccuracies create the hazard that a wiki might be the right one for you but not show up in your Wikimatrix customized search short list.)

And once you have narrowed your list, it’s important to know that there are key functionality gaps in every product, and they may not be immediately apparent when you just read about the platform.

For example:

• Search is important for every wiki. Test it and try to talk to users to see what they think of that product’s search functionality. Does it return useful results?

• If tables or spreadsheets are important to you, test out that platform’s tables/spreadsheets.

• With repeated use you are likely to find that none of the WYSIWIG editors act exactly as you would like; developers are still working on this. Play with some so you know what you are getting.

• You may also find that notification systems are lacking. Be sure to test these and any other functionality important to you.

The bottom line is before deciding on a platform: test it and try to talk to other users. Then pilot it before signing on the dotted line. (Migrating from one wiki to another, though doable, is often not a pretty picture.)

A Funny Thing Happened on the Way to the Wiki

With this blog, I have finally gotten around to publishing some thoughts about wikis.

And just as I have gotten around to it, the trend is for the wiki-as-wiki to bow out in deference to the "collaboration suite" (platforms that have wikis plus other collaborative or social capability).

The blank page of a wiki offers a lot of flexibility, but not always a lot of functionality and structure, or direction for the user.

So in the past year, as adoption of various forms of social software has accelerated, leading wiki platforms have added greater functionality.

Some vendors have added modules such as social networking or a Twitter-like micro-blogging ability. (In addition to adding social software capabilities some have made their wiki functionality stronger and deeper with a better editor, better user interface, more widgets, better extensions, or improved document management.)

Recently when I made a chart comparing eight (mostly) wiki-centric platforms I was able to compare them on these capabilities--because so many of them now had them.

• wiki
• blog
• discussion forums
• rich profile (profile which shows your "activity stream" i.e. contributions you have made)
• social networking
• document storage/search
• Twitter-like micro-blogging
• personal dashboard

Of the platforms I follow most closely, Traction TeamPage currently has all of the above capabilities except social networking, Jive Clearspace, all of the above except microblogging and Socialtext, in a re-designed website as of mid-December, touts all of the above, except forums. Atlassian’s Confluence comes out of the box with enterprise quality wiki and document functionality. I would guess a tech savvy user could build the rest in Confluence--except for microblogging and social networking--using plugins, macros and more. (See this very good webinar for tips on how a discussion forum was built in management and technology consulting firm Bearing Point’s wiki.)

It was in the last half of 2008 that Traction introduced micro-blogging, Socialtext, social networking and a personal dashboard, and Atlassian, the Office Connector which allows you to save Office documents directly into the wiki.

Wiki-centric platforms are evolving fast. Right now, as they add capablities, it looks like they are converging. I wonder, in this tumultuous climate, what we’ll be seeing at the end of 2009.

Collaborative Document Creation: Volunteer School Committee Drafts a 300 Page Report

I sent an email to my management school list serv asking for examples of wiki usage. One of the replies was from Sanjay Patel who worked on a committee in his local school district tasked with visioning "The School of the Future."

He was enthusiastic about how the wiki had worked for them. He laughingly characterized the group as "middle-aged not technically savvy people."

"The Visioning Committee tasked with writing a report on the School of the Future was made up of middle aged not technically-savvy people. We were a diverse group: teachers, administrators, parents, business and industry representatives, companies who hired locally. The tech coordinator for our school system suggested we use a wiki to log our research and pull together the multi-hundred page document we were to create. And it worked.

The wiki built on wikispaces allowed us to work on the report at a significantly faster rate than emailing back and forth. We also used the wiki to invite students in to read and contribute. We could post when we wanted, read, and respond to others."

They surprised themselves about how well and easily it worked:

"In one hour we were trained and we structured the wiki. Our school system's tech coordinator held an hour long training/workshop. There were 20 of us. We whiteboarded the structure and learned how to use the wiki. At the beginning, people were uncomfortable with editing other people's work. They would just write something underneath another person's writing. Then a couple of us decided, 'Let's get it done,' and started commenting in the text itself and editing. Others joined in. One of the things I liked best was that I could make an important contribution to the project without attending every meeting."

He explained they used the wiki for logging research and drafting the document, then used Word to finalize it.

"It evolved that people specialized on topics or sections of the document—researching an area and then drafting content. Two or three people would work on a section.

In the end, the tech coordinator, copied everything by section out of the wiki and edited and formatted it in Word to create the final deliverable report which we submitted to the School Board."

Some of the reasons it's likely that the wiki worked so well for them was that it fulfilled a real need--easing the process of collaborative document creation, and had at least one person, the school tech coordinator, who helped guide the wiki.

Email: Dispersed and Hidden

Copyright © 2008, Valdis Krebs

I love this image.

For me it says it all.

What’s the image of?

Here’s an edited version of what Valdis Krebs says about his image:

The social network map above shows the email flows amongst a large project team...Each person on the team is represented by a node. Each node is colored according to the person's department -- red, blue, or green. Yellow nodes are consultants...Grey nodes are not formal team members but are external experts...

...Only emails addressed to individuals were used...A grey link is drawn between two nodes if two persons sent email to each other at a weekly or higher frequency.

• It’s kind of astounding to think of all the information that is embodied here, but unavailable to the group as a whole.

• On the other hand, if all this information was available to the group i.e. the same information is in all these communications, there is tremendous inefficiency.

With email, ideas, plans, and information are hidden in dispersed inboxes.

With a wiki, information can be centralized, shared, contextualized in real time, allowing collaboration, and coordination. Knowledge can be retained, built upon, and is findable.

Note: This is only a picture of flows of emails addressed to individuals. “Reply all” emails are estimated to make up 30% of all emails in offices. When a wiki is introduced, wiki vendors, including Socialtext say that 30% of email migrates to the wiki, which is a much more useful place for them. 

Personal disclosure: I am a sucker for maps; I used to own and run a map business.

Peeking Inside a Wiki: Planning A Conference

For me it’s exciting to peek inside an organization’s wiki. It’s the best way to learn about how you can use one.

The Johnson Center (that’s the Dorothy A. Johnson Center for Philanthropy and Nonprofit Leadership at Grand Valley State University) used a wiki to plan their NP2020 conference. (NP2020 group pictured to the right.)

The screenshots below, for me, show—very simply—the power of centralizing information for lightweight project management.

Home Page-Orienting the User
Here's the wiki's home page with the wiki's purpose, a space to enter the conference goal, a link to last year's archive, and current announcements. (Click to enlarge the screenshots in a separate window.)

On the left is the navigation bar which has two main sections: Reference and Current Info. Current Info has dynamic information about such things as marketing and logistics.


Information—with context
Here's the page you arrive at when you click Meetings on the left navigation bar. There are action items at the top and then links to archived meeting notes.

After the meeting date, the meeting is described briefly. This is one of the exceedingly useful things about a wiki: information can be contextualized.

Broadcast email becomes the announcements archive


....retained, searchable and not cluttering your inbox.

A Table is Used for a Work Checklist
Here's the marketing checklist. Of course anyone working on the conference can add tasks, change due dates, and add the date completed. You don’t have to bother your colleague asking if that bit of the work was done—you just look here.




Centralized summaries
Finally, one of my favorite summary pages.

One liners: a record of all key decisions that have been made, centralized in real time. I was told that these were often referred to.





For the public, information about and a knowledge base of the conference
It all comes full circle. There is a public facing wiki for conference attendees. And as each session transpires, notes are entered by participants in the wiki, creating a record of the conference or knowledgebase.


Thanks to Brian Satterfield’s article on TechSoup for leading me to the Johnson Center.

Wiki Basics

The first presentation I did about wikis is here.

It’s a basic primer, and covers:

• What are the attributes of a wiki?
• How do wikis differ from other commonly used communication and collaboration tools?
• What kind of problems can a wiki solve? What are its uses?
• What are examples of these use cases? (with screenshots)
• How can you build a successful wiki?

The presentation is primarily images, not bullet points. A lot of the content is in what I said but the images still provide an introduction. The examples are nonprofits but most of the information applies equally well to for profits.

In the presentation, I incorporated a lot of ideas that Michael Idinopulos shares in his succinct, thoughtful blog, Transparent Office. Some of his most useful thoughts when you are starting your wiki are these:

Creating a Welcoming Wiki-On Structuring and Populating Your Wiki With Content

• Structure, populate, review, invite, and garden,
• How much predetermined structure for your collaboration space?
• How to populate your wiki
• Content in a wiki - Not more than one click away

Adoption

• In-the-flow wikis may be more readily adopted than above-the-flow wikis
• Redirecting work to your collaborative workspace
• Predicting wiki adoption
• A collaborative culture is not a precondition for wiki success

Wiki Uses

• 3 best practices on creating a participatory knowledgebase
• Enterprise 2.0 tools as your intranet
• Manage docs with a doc management system, collaborate with your collaboration suite
  

And finally...

Why you shouldn't worry about wiki vandalism