Seven year old blog post: "[LinkedIn] about four weeks into a viral explosion"

Thanks to archive.org, I was able to find this seven year old blog post of mine. I had just attended the Planetwork conference in San Francisco, a combination social media - social responsibility conference.

In my blog post from June of 2003, I found this gem:

I signed up for LinkedIn, another hot topic at the conference. LinkedIn, like Friendly Favors is a social networking site, that allows us to utilize the relationships we already have. For example, let's say that you know I know Peter Theony, author of TWiki. And you would like to make a proposal to Peter, but you also want to make sure he'll give it due consideration. So you ask me to give you an introduction to Peter, or to forward your proposal to him, and putting in a good word for you. Well, this is exactly what LinkedIn does, except that it does it automatically, and allows us to utilize relationships that you don't know about (like my unusual connection to Weekly World News). Conference reports suggest they are about four weeks into a viral explosion.

It's funny to consider that we really had to explain what it was, or people just didn't get it.

I also wrote:

I met Rebecca Blood, author of The Weblog Handbook. We had an interesting conversation on the social effects of macroeconomics (amazing what you can talk about as an MBA student). We also talked about my WikiAdoption experiences at HP. 

That chance conversation led to a panel presentation on wikis at SXSW in 2004.

Socialnomics

A compilation of statistics regarding the ROI of social media from Socialnomics author Erik Qualman (via John Perez):

The Technological Singularity

From http://en.wikipedia.org/wiki/Technological_singularity:

In 1965, I. J. Good first wrote of an "intelligence explosion", suggesting that if machines could even slightly surpass human intellect, they could improve their own designs in ways unforeseen by their designers, and thus recursively augment themselves into far greater intelligences. The first such improvements might be small, but as the machine became more intelligent it would become better at becoming more intelligent, which could lead to a cascade of self-improvements and a sudden surge to superintelligence (or a singularity).

The implications for human society are interesting:

In 2009, leading computer scientists, artificial intelligence researchers, and roboticists met at the Asilomar Conference Grounds near Monterey Bay in California to discuss the potential impact of the hypothetical possibility that robots could become self-sufficient and able to make their own decisions. They discussed the extent to which computers and robots might be able to acquire autonomy, and to what degree they could use such abilities to pose threats or hazards. Some machines have acquired various forms of semi-autonomy, including the ability to locate their own power sources and choose targets to attack with weapons. Also, some computer viruses can evade elimination and have achieved "cockroach intelligence." The conference attendees noted that self-awareness as depicted in science-fiction is probably unlikely, but that other potential hazards and pitfalls exist.^[8]

Some experts and academics have questioned the use of robots for military combat, especially when such robots are given some degree of autonomous functions.^[9] A United States Navy report indicates that, as military robots become more complex, there should be greater attention to implications of their ability to make autonomous decisions.^[10][11]

The Association for the Advancement of Artificial Intelligence has commissioned a study to examine this issue,^[12] pointing to programs like the Language Acquisition Device, which can emulate human interaction.

A Brief History of Social Media

Tac Anderson put together a nice article about the history of social media, starting with its beginnings in the Cluetrain Manifesto:

At first there was no terminology to describe what was happening. One of the earliest attempts to put a voice to this, The Cluetrain Manifesto,  tried to explain the shift, years before the bubble popped, by pointing out that markets had become conversations. Companies could no longer push messaging at customers and expect them to act like sheep. 

Check out the full article.

Using The Customer Support Experience Framework

A few weeks ago, I posted about a framework for considering the customer support experience. The framework is composed of four phases: awareness, navigation, diagnosing, and solving.

Pete Hwang, a collegeue of mine, asked if the framework could be shortcut by people using Google:

Framework makes sense. But could you argue that web savvy customers who start with a Google search shortcut the whole thing? The customer experience journey in this case: Customer recognizes they have a problem. Google for error code or best guess at describing problem. View hits on possible solutions... Corroborate entries and take educated guess at likely best solution. Hopefully, solve problem. Otherwise, look toward 2nd most likely answer. If still not solved, try a fresh google search with fresh search terms. The official HP support doc only comes into play as it receives high credibility (high ranking) on Google.

Pete's point is certainly valid. The framework isn't intended to dictate a specific support path down which the customer is forced, but instead is a thinking aide to understand their experience and compare the role that different tools play. The way that we've used the framework is by describing different support tools within an "AAA NNN DDD SSS" diagram. The letters stand for Awareness, Navigation, Diagnosis, Solution. We repeat the letters simply to remind ourselves that frequently there may be multiple steps within each phase, and that different tools may help get the customer through different phases.

Let's look at an example. In the picture, row 1 shows what most company's idealized view of the web support experience looks like. In this idealized picture, the customer thinks first of the company's web site, enters through the home page, navigates through the site using links, and ultimately finds a web document to solve their problem.

Row 2 shows a common alternative, and the one described by Pete. A customer does a Google search on a product, and again in the ideal world, the Google search's first result is a link to the support document for that problem.

Row 3 is another alternative - a Google search leads to a web forum discussion. Web forums frequently do exceptionally well in search engine results, so if a forum exists, and the problem has previously been posted, odds are good that a forum result will be high up in the search results.

Row 4 is just a hint of another tool that companies have at their disposal, but frequently don't take full advantage of. Error messages displayed by software applications or even hardware devices do much to make the customer aware of the problem, but usually do very little to help them find a solution. An error message that was linked back to a support document would directly make the link from problem to solution, and would bypass the need for navigation and diagnosis.

Please let me know if you make use of this framework. I hope it will be of use to you.

Why Content Management is Not the Same As Wikis

In the technical support documentation space I've been recommending wikis as a way to enhance collaboration on support documentation as an alternative model to the traditional approach of having a small cadre of technical writers and experts using a traditional content management tool to publish documents to the way.

While I'm an advocate of opening up the wiki to customer input, there are levels of collaboration that may make it easier for companies to get their feet wet without going so far as to open it up to customer input. The wiki could be used, for example, to allow input from other employees across the company, from R&D engineers to call support agents.

However, whenever I propose this, the established parties usually say "Why don't we just fix the content management process we have?" or "If all we want to do is collaborate inside the company, we can use the content management tools we have for that."

Wikis aren't just another content management tool however. Wikis embody design principles that encourage contributions. When Digg was first implemented, the earliest versions had a two-step process to submit a digg vote. Kevin Rose, founder of Digg, spoke about the impact that moving from a two-step to one-step process had on the site:

There was a huge shift in activity on Digg when we made the move to the one-click digg in November 2005. Once we added Ajax, activity went through the roof on [the number of] diggs. It was just insane. Just the ease of the "one-click and you're done" made all the difference in the world. Once the users grasped that the content is syndicated to friends, friends' activities then went through the roof. These small incremental steps in feature additions drove the growth.

The more direct and lightweight the process is for contributing, the greater the number of contributors. And it's not just pure volume of contributors: a simple contribution at first can then lead a user from passive recipient to enthused contributor. The editors at Wikipedia that devote much of their lives to upholding the quality of Wikipedia all started their involvement with a single, simple contribution at some point in time.

Wikis are perhaps the purest embodiment of the design principles of directness and lightweight processes. Every page has an edit button, so contributions are never more than a click away. The act of adding a few words to a document t is rarely more than clicking edit, inserting those words, and then clicking save.

Contrast that with a typical content management system: As a user who is browsing support documents on the web, and then spots an error in a document, if I've already used the content management system before, I have to then:

1. find/launch the content management system
2. login
3. navigate to the document I was already viewing, usually by an obscure mechanism that isn't the URL of the public document
4. choose to edit the document
5. make the edit
6. save the document
7. probably go through an edit review process relying then on other people to review the edit
8. wait for notification that the edit is published
9. check that the web document reflects the change

If I haven't used the content management system, I would need to:

1. Find out how the content is managed, probably by emailing peers until I get an answer
2. Find out how to apply for a login
3. Justify my need/right to modify the content (usually a lengthy process)
4. Find out how to use the system

The two choices differ so significantly in effort involved, that the result is not just a quantitative difference in the number of contributions, but a qualitative one as well: true collaboration among a large group of contributors is unlikely using a traditional content management tool, because only those whose primary job it is to manage content are likely to invest the effort to use it.

By comparison, wiki makes it clear that editing is possible, puts the edit tool only a click away, and removes the step of having to renavigate to the content to be edited. While these steps may seem small, like we saw with the Digg example, small reductions in effort correspond to large increases in contributions.

Side note: I'm currently reading Designing Web Interfaces: Principles and Patterns for Rich Interactions, which inspired some of these thoughts.

Four Phases of the Customer Support Experience

When large companies put technical support content online, the effort frequently comes with a variety of pitfalls. A large company may have dozens or hundreds of products, and each of those products may have dozens or hundreds of support documents, leading to many tens of thousands of support documents.

This can make it exceedingly difficult to find the right help content for any given product and problem. As a result, companies then undertake a variety of web site improvements aimed at helping customers get their problems solved from improving navigation, to providing top FAQ lists, interactive troubleshooting tools, and more.

But how do each of the potential tools affect the customer experience? How do they relate to each other? And what part of the customer experience are they really seeking to improve?

Here is a framework Steve DeRoos and I like to use to think about technical support experiences. To help customers get their problem solved using eSupport, there are four phases of the user experience to consider:

1. Awareness
2. Navigation
3. Diagnosing
4. Solving

Awareness: How do your customers become aware that you offer self-support help? If you're recently improved your self-support help (for example, if you've recently added forums), how will customers be aware of those changes? Most customers, particularly web savvy customers, will choose to use a website visit over a phone call to get their problem solved. But less savvy customers, or customers who previously had a bad web support experience are likely to gravitate directly to phone support.

However, the more web-savvy they are, the more likely they are to go direct to Google to get their problem solved.

Navigation: Once the customer has made the decision to use self-support, how do they find it? Do they need to navigate to a product specific area of the website? Can they search and find it? Are there multiple kinds of support content and tools - if so, how does a customer choose which one to use? One example of a tool designed to make support navigation easier is HP's Automatic Product Detection, a tool that detects what HP products the customer has, and links directly to the support pages for those products.

Diagnosing: When the customer finally arrived at the support content, how do you narrow down the specific problem the customer is having? Is it an install problem or a use problem? If it is a paper jam on an all-in-one printer, is it a paper jam for the printer portion, or the scanner portion? With regular paper or something unusual like labels or card stock?

Solving: When the problem is finally known, what are the steps to solve the problem? How do you insure that the customer follows through on the steps? If there are multiple ways to solve the problem, how do you lead the customer through each of the different ways? How do you know if the problem is resolved?

Having a framework like this helps ensure that all aspects of the user experience are considered. It also helps when considering proposal investments in eSupport: What problem is being solved? What percentage of the user base will it work for? And what is the business impact of improving that aspect of the user experience?

*Bridge photo used under Creative Commons license. Original photo by mozzercork. Shakey Bridge, Cork City, Ireland

Taming the Comment Trolls

When a large company rolls out social media capabilities on their website, they frequently worry about negative posts. A large company represents to many, a large target. Even the best companies with excellent customer service will have the occasional frustrated, angry customer.

How to deal with this? If the company moderates posts, and filters out anything negative, they will lose trust with their customers. If the company does nothing, and lets negative posts pile up, they could dominate the online community and discussions even if they are not truly representative of most people's experiences.

It's not so much whether a post is negative or postive, but whether it is constructive or destructive. A constructive post might point out a flaw in a product, but lead to a discussion about how to improve the product or work around the flaw. A destructive post might point out a flaw in a product and then proceed to personally attack the employees of the company.

Luckily, communities can police themselves. Using comment moderation features, users of online communities and websites can rate comments up or down, or report them for violation of community guidelines (such as inappropriate language).

When the right tools are in place, the constructive members of the community (who generally represent the majority) will tend to vote down destructive contributions. The company who sponsors the community or social media aspects of the site won't need to be involved in moderation, and so they won't be perceived as trying to control the conversation.

Pete Hwang, Experience Designer-Strategist at Hewlett-Packard, recently brought to my attention an excellent Wired magazine article by Clive Thompson on "how to open your website to comments without inviting the flood of toxic and inappropriate comments & flamewars that often arise".

The world’s top discussion moderators have developed successful tools for keeping online miscreants from disrupting conversation. All are rooted in one psychological insight: If you simply ban trolls—kicking them off your board—you nurture their curdled sense of being an oppressed truth-speaker. Instead, the moderators rely on making the comments less prominent.

Pete's favorite approach to disarming those destructive comments:

Here’s another hack: selective invisibility. It was invented byDisqus, a company whose discussion software handles the threads at 90,000 blogs worldwide (including mine). In this paradigm, if a comment gets a lot of negative ratings, it goes invisible. No one can see it—except, crucially, the person who posted it. "So the troll just thinks that everyone has learned to ignore him, and he gets discouraged and goes away," chuckles Disqus cofounder Daniel Ha

(It turns out that selective invisibility is a technique that actually dates to Bulletin Board Systems (BBBs) back in the early 1980s.)

Twendz: Tool for Twitter Brand or Topic Analysis

Recently Waggener-Edstrom, the PR firm, released Twendz, a tool for analyzing Twitter posts for topics. It’s a pretty great tool, and they are making it freely available.

I used it recently to search for “photosmart”, a Hewlett-Packard printer brand. You can see that results of that search.

From this search, I get a sentiment ratio (percentage of positive versus negative posts) for “photosmart”, as well as a subtopic sentiment analysis for the top five subtopics. A word cloud also lets me see other common words used. In many cases, the twitter posts also include a link to a blog post with a lengthier description of the problem/question/topic.

Now there's no excuse for not monitoring your company and products on Twitter.