Launch E2.0 Broad, Then Go Deep

In my previous post, I argued that companies should Skip the Pilot for Enterprise 2.0 applications. The argument, which came out of my own experience with hundreds of implementations, is that small-scale pilots are not representative of the way companies use collaborative tools at scale. As I put it there, "Scale is the oxygen that feeds collaboration."

The post was controversial. You can see the comments on both my personal blog and on the Socialtext blog. Many people agreed with me. Others trashed my advice to skip the pilot. But even those who trashed it agreed that small-scale collaborative dynamics and large-scale collaborative dynamics are different. They defended pilots on purely pragmatic grounds of risk mitigation. It's just too risky, too scary to launch on enterprise scale until you've proven adoption and value with a small group.

Chris McGrath and I have been going back and forth on this point, and his last comment summarizes his position nicely:

"How is E20 ever going to go mainstream if it requires massive deployments? I'd hate to be the person that convinces their company to make a million-dollar leap of faith, only to have a full-scale rollout languish."

Well shucks, I wouldn't want to be that person either. And you don't have to be. Skipping the pilot does not mean you have to be reckless or risk your career on an all-or-nothing Enterprise 2.0 deployment. The best launch approach ratchets down risk without artificially narrowing the scale of your launch.

Enterprise social software isn't one application. It's a range of collaborative modes that includes blogs, wikis, micromessaging, personal dashboards, collaborative spreadsheeting, and social bookmarking. As Ross Mayfield shows in his post The Power Law of Participation, these different modes have different adoption profiles. Some modes of collaboration have a really low threshold of participation: It's very easy to get started on them because individuals don't need a ton of engagement to find them useful. Other modes of collaboration have a really high threshold: Users don't see the point unless they invest a lot of time learning and using the tools.

Historically, Enterprise 2.0 implementations have focused on collaborative tools fairly high participation thresholds: blogs and wikis. That's not by design, it's by default. Until recently, those were the only Enterprise 2.0 tools that showed potential for high-value business use. Since these activities required a lot of engagement, we smothered our pilot participants with training and encouragement--which forced us to keep the pilots small.

Today, Enterprise 2.0 participation is a whole different game. At the "low threshold" end of the curve, we have low-engagement tools like social messaging (internal "Twitter"), social bookmarking. By leading your implementation with these low-threshold tools, you lower the risk of implementation while still launching at the scale required for success.

The results can be exciting. My company, Socialtext, recently held a webinar on micromessaging for a major financial services company in the Midwest. We didn't position it as a comprehensive Socialtext training. We just focused on Signals, our social messaging component. We were blown away by the response. So many people dialed into the webinar that we--no joke now--brought down the company's phone system.

The webinar itself was energizing (at least until the phones went dead). The group was super-engaged. People were actively creating profiles. They uploaded pictures. They sent signals razzing each other about their pictures. They tagged each other's profiles. And best of all...they signaled about what they were doing at work.

Signals was not just a useful tool, it was also a stepping stone that helped participants move to the right on the Participation curve (see image above). As participants started to get the hang of Signals, many started to ask about Socialtext's other collaborative features: What are workspaces? How do I use the Dashboard? How do I look up an individual?

After the webinar was over, a number of users wanted to go deeper by creating wiki workspaces to collaborate on tasks, projects, documentation, etc. We scheduled follow-up time with them to understand their collaborative needs and build tailored solutions.

This story describes a launch approach that simultaneously achieves seemingly conflicting objectives:

• Launch quickly and cheaply, without investing a ton of time or money in training and content creation.
• Achieve scale by inviting lots of people.
• Minimize risk by making participation opt-in rather than mandatory
• Generate active participation through interactive launch events that don't require a lot of training or engagement from the new user.
• Deliver deep value by following up with local champions who want to invest time and effort in more robust, group-specific forms of collaboration.

So let me ask the question one more time: Why do you need a small-scale pilot?

Comments

[Chris McGrath]

Hey Michael,

Another good post. Raises some questions for me:

1) Attention cost. The broad-launch approach requires that you "achieve scale by inviting lots of people." There is a cost here -- the cost of attention. Do you think you need to have a CXO in full support of the project in order to incur this cost? (Pilots are often run grass-roots.)

2) Pricing. You said this approach allows you to launch cheaply. As a vendor, how do you approach pricing? Do you use performance-based compensation, e.g. based on # of active users after a few months?

3) IT Support. An argument for pilots is they allow for a technology shakedown -- a period to ensure the underlying technology works well and is fully compatible in the new environment. How do you convince IT to risk a launch of unknown technology to thousands of users? (Good references, I imagine?)

[Kim Feraday]

Interesting debate. It also raises a question for me. While I agree that low threshold tools can encourage participation and increase interactions (building what I think Ross called collective intelligence) I wonder how the chasm is crossed to create really high value collaborative intelligence.

Let's take the example of the webinar you ran recently. You got alot of people engaged in microblogging and creating profiles. This led to a small number of users interested in creating workspaces and collaborating. How do then effectively leverage the scale you've created in the network to build effective communities (after all isn’t community the more effective glue)? In other words how does discovery happen (particularly in large organizations). I can imagine, particularly in large organizations there are instances where users with weak network connections to the core community can prevent participation. Without discovery underpinning everything it limits the success you will have in binding the periphery to the core. In some respects isn’t this why Twitter is moving more towards search?

[twitter.com/cmiro]

Michael - great post, and a much more sophisticated, updated perspective on implementation. E2.0 (particularly Socialtext) is so much more dynamic than it was even a couple of years ago; there are new ways for people to "play" which didn't exist before. Big, scary workspaces are not the only way to collaborate anymore; and I love that your post acknowledges the fact that there can be different "thresholds" of participation. In my opinion; any participation is a good thing.

I have found that low threshold users often become high threshold users as they start to feel comfortable with the technology, and start to see the possiblities. I agree that assuming small-scale pilots are the way to go without exploring other, more creative and larger-scale options would be a shame, and could potentially lead to an anti-climactic and less energizing roll-out. Without scale, you miss out on seeing and feeling "the oxygen" that is produced by company-wide collaboration. For what it's worth...

Thanks for another great post!