Tag Archives: flow

More on Microblogging: Evolution of the Enterprise Market

Following my post last week on the need for additional filters in enterprise microblogging tools and activity streams, I participated in an interesting Twitter conversation on the subject of microblogging and complexity. The spontaneous conversation began when Greg Lowe, a well-respected Enterprise 2.0 evangelist at Alcatel-Lucent, asked:

“Can stand alone micro-blogging solutions survive when platform plays introduce the feature?”

I immediately replied:

“Yes, if they innovate faster”

Greg shot back:

“is microblogging autonomy about innovation, or simple elegance? More features usually leads to lower usability?”

And, later, he asked a complementary question:

“is there a risk of Microblogging becoming “too complicated”?”

Is Greg on to something here? Do more features usually lead to lower usability? Will functional innovation be the downfall of stand-alone microblogging solutions, or will it help them stay ahead of platform vendors as they incorporate microblogging into their offerings?

One of the commonly heard complaints about software in general, and enterprise software in particular, is that it is too complicated. There are too many features and functions, and how to make use of them is not intuitive. On the other hand, usability is a hallmark of Web 2.0 software, and, if we make it too complex, it is likely that some people will abandon it in favor of simpler tools, whatever those may be.

But that dichotomy does not tell the entire story. Based on anecdotal evidence (there is no published quantitative research available), early adopters of Web 2.0 software in the enterprise appear to value simplicity in software they use. However, as a colleague, Thomas Vander Wal, pointed out to me yesterday, that may not be true for later, mainstream adopters. Ease-of-use may be desirable in microblogging (or any other) software, but having adequate features to enable effective, efficient usage is also necessary to achieve significant adoption. Later adopters need to see that a tool can help them in a significant way before they will begin to use it; marginal utility does not sway them, even if the tool is highly usable.

Simple may not be sustainable. As I wrote last week in this post, as enterprise use of microblogging and activity streams has increased and matured, so has the need for filters. Individuals, workgroups, and communities want to direct micro-messages to specific recipients, and they need to filter their activity streams to increase their ability to make sense out of the raging river of incoming information. Those needs will only increase as more workers microblog and more information sources are integrated into activity streams.

In the public microblogging sphere, Twitter provides a solid example of the need to add functionality to a simple service as adoption grows in terms of registered users and use cases. As more individuals used Twitter, in ways that were never envisioned by its creators, the service responded by adding functionality such as search, re-tweeting, and lists. Each of these features added some degree of complexity to the service, but also improved its usability and value.

In the evolution of any software, there is a trade-off between simplicity and functionality that must be carefully managed. How does one do that? One way is to continuously solicit and accept user feedback. That allows the software provider and organizations deploying it to sense when they are nearing the point where functionality begins to overwhelm ease of use in a harmful manner. Another technique is to roll out new features in small doses at reasonable intervals. Some even advocate slipping new features in unannounced and letting users discover them for themselves. Hosted deployment of software (whether on-premise or off-site) makes this easier to do, since new features are automatically switched on for people using the software.

So back to the original question; can stand-alone microblogging solutions fend off the collaboration suite and platform vendors as they incorporate microblogging and activity streams in their offerings? My definitive answer is “yes”, because there is still room for functionality to be added to microblogging before it becomes over-complicated.

Based on the historical evolution of other software types and categories, it is likely that the smaller vendors, who are  intensely focused on microblogging, will be the innovators, rather than the platform players. As long as vendors of stand-alone microblogging offerings continue to innovate quickly without confusing their customers, they will thrive. That said, a platform vendor could drive microblogging feature innovation if they so desired; think about what IBM has done with its Sametime instant messaging platform. However, I see no evidence of that happening in the microblogging sphere at this time.

The most plausible scenario is that at some point, small, focused vendors driving microblogging innovation (e.g. Socialcast, Yammer) will be acquired by larger vendors, who will integrate the acquired features into their collaboration suite or platform. My sense is that we are still 2-3 years away from that happening, because there is still room for value-producing innovation in microblogging.

What do you think?

Advertisements

Why I Am Ignoring Google Buzz

Note: This post is purely personal opinion based on my preferences and work style. If your are looking for an analysis of Google Buzz based on methodical primary research, abort now.

I have heard many people say that their email inbox is the mother of all social networks. For me, however, email is  the antithesis of a well-built, functioning social network, because it is a communication channel, not a collaboration enabler.

I value my social networks because I can work with members of those communities to get things done. When I worked at IBM, a very large company, my email inbox was more of a proxy for the organizational hierarchy than an instantiation of my social graph. Too much of my email activity was about low value (or value-less) communications and interactions imposed by command and control culture and systems. When I needed to communicate something up or down IBM’s or a project’s chain of command, I used email. When I needed to get something done, I contacted collaborators on Sametime (IBM’s instant messaging product), the phone, or BlueTwit (IBM’s internal-only, experimental microblogging system). In short, the contacts in my large corporation email address book were more reflective of the organizational structure than of my collaborative networks.

That is precisely why Google Buzz is a non-starter for me. The Google Contact list on which it is based does not represent my collaborative network, on which I rely to get work done. Very few of the people with whom I collaborate are represented, because I don’t interact with them via email. At least not often. A quick analysis of my Google Contacts list shows that Google Voice usage contributes more actionable, valuable additions to the list than does Gmail. My Gmail inbox is filled with communications, not action items, and most of them are low-value messages from application and service vendors whose tools I have downloaded or use online.

Google’s design of Buzz demonstrates ignorance of (or disregard for?) the reality that many social interactions happen outside of email. Had I wanted to use my Google Contacts list as a social network, I would have imported it into FriendFeed months ago. Strike One.

I just mentioned FriendFeed, which was my primary social network aggregator for several months. One of the reasons I backed away from heavy usage of FriendFeed was because it became little more than another interface to the Twitter stream. Yes, it is easy to inject updates from other sources into the FriendFeed flow, but, in reality, the vast majority of updates cam from Twitter (and still do.)

I see the same thing happening with Buzz. Too many people have linked their Twitter accounts, so that everything they tweet is duplicated in Buzz. And Buzz doesn’t allow for integration of the vast number of information resources that FriendFeed does. Talk about low-value. Strike Two.

I have not taken enough swings at Google Buzz yet to have recorded Strike Three. So, for now, I have not turned Buzz off. However, I am ignoring it and will not experiment again until Google provides integration with more external social networks.

In the meanwhile, I am still looking for a social tool that blends contacts and information streams from many sources, but lets me filter the flow by one or more sources, as desired. That would allow me to work both formal organizational and informal social networks from the same tool. Gist is promising in that regard, but needs to be able to capture information from more sources with corresponding filters. Hopefully, someone will read this post and either point me to an existing solution or build it. Until then, I will have to continue using multiple tools to communicate and collaborate.

Go With the (Enterprise 2.0 Adoption) Flow

WaterGlassPeople may be generally characterized as one of the following: optimists, realists, or pessimists. We all know the standard scenario used to illustrate these stereotypes.

Optimists look at the glass and say that it is partially full. Pessimists remark that the glass is mostly empty. Realists note that there is liquid in the glass and make no value judgment about the level.

The global Enterprise 2.0 community features the same types of individuals. I hear them speak and read their prose daily, noticing the differences in the way that they characterize the current state of the E2.0 movement. E2.0 evangelists (optimists) trumpet that the movement is revolutionary. Doubters proclaim that E2.0 will ultimately fail for many of the same reasons that earlier attempts to improve organizational collaboration did. Realists observe events within the E2.0 movement, but don’t predict its success or demise.

All opinions should be heard and considered, to be sure. In some ways, the position of the realist is ideal, but it lacks the spark needed to create forward, positive momentum for E2.0 adoption or to kill it. A different perspective is what is missing in the current debate regarding the health of the E2.0 movement.

Consider again the picture of the glass of liquid and the stereotypical reactions people have to it. Note that none of those reactions considers flow. Is the level of liquid in the glass rising or falling?

Now apply the flow question to the E2.0 movement. Is it gaining believers or is it losing followers? Isn’t that net adoption metric the one that really matters, as opposed to individual opinions, based on static views of the market, about the success or failure of the E2.0 movement to-date?

The E2.0 community needs to gather more quantitative data regarding E2.0 adoption in order to properly access the health of the movement. Until that happens, the current, meaningless debate over the state of E2.0 will continue. The effect of that wrangling will be neither positive or negative — net adoption will show little gain —  as more conservative adopters continue to sit on the sideline, waiting for the debate to end.

Anecdotal evidence suggests that E2.0 adoption is increasing, albeit slowly. The surest way to accelerate E2.0 adoption is to go with the flow — to measure and publicize increases in the number of organizations using social software to address tangible business problems. Published E2.0 case studies are great, but until more of those are available, simply citing the increase in the number of organizations deploying E2.0 software should suffice to move laggards off the sideline and on to the playing field.