The Cluetrain Manifesto
As the design progressed, we settled on one "review" as an example of a magazine article that might appear when the product shipped. The ersatz review was a hit with team members: it became a decision yardstick for months of subsequent design and implementation questions.
People also started giving copies of the review to customers and using it as a conversation starter with friends and colleagues in other companies. The review wasn't a product pitch — it required a person to deliver it, explain it, and fill in lots of details.
It wasn't a data sheet, but a foil for stories and conversations. Its value was not in creating some kind of official spin, but in enabling the reliable transfer of knowledge and new ideas.
A critical aspect of success with large numbers of customers lies in listening to them. It's not enough for employees to talk to customers.
There must be a way for the fruits of employee conversations to trickle back into an organization's plans. When Sun started to address the problem of providing technical support to the Java developer community, we made a glaring error.
We assumed our answers to technical questions were more valuable than answers from sources outside our group, than answers from our customers.
Sun's first launch of the Java Developer Connection Web site was an unabashed effort to package a fairly sleazy business proposition: selling per-incident support for a poorly supported and less than adequately documented software product.
We were doing a lousy job of helping Java developers. A bright marketing wag had the idea to sell people answers to their questions for one hundred bucks a pop.
When a licensing engineer who dealt with customers day in and day out posed the question, "Why should they feel good about paying us for answers that should be in the docs, or for consulting on problems caused by the instability of our products?", the marketing folks decided to use a bit of sugarcoating.
For $495 a year, a customer could purchase a "subscription" including five questions, called "support incidents," and a package including technical newsletters and other goodies.
Unfortunately, the marketing team focused on providing the hundred-dollar support answers and didn't spend much time setting up the information-publishing pipeline for the sugarcoating.
We had fewer than two hundred paying customers for the service. Almost all used up their magic answers in less than a month, then started clamoring for the "real" value, the (grossly understaffed) information subscription that was to be their pipeline to successful use of Java.
To add insult to injury, our own cross-divisional inefficiencies cost us $110 for each question answered. You do the math.
Time for phase two. We shut down the site, and relaunched a free service with a few critical new features.
The staffing problem hadn't gotten better, so we brainstormed ideas for getting the Java community to help us solve their problems. We now have a free site with question-and-answer forums where developers answer each other directly.
We added a tap into Sun's Java software bug database and provided a means for developers to add their own notes and work-arounds to our bug information, as well as vote for the bugs they wanted us to fix soonest.
A reverse pipeline into the company sent the bug votes to our engineers to help with prioritization. The site hit one million registered members in two years, a far cry from the two hundred in six months that the initial, traditional support efforts yielded.
Moreover, the site became a nexus for conversations about our products and services, and for conversations about other people's solutions to our problems.
Symantec took a similarly creative approach when they first launched their CafĂ product, a suite of programming tools for Java developers.
They had one person virtually living in the public support newsgroups. He responded to questions, fielded tech support requests, and generally got himself known as a very straight shooter about Symantec's products.
He was only one person, but he was almost single-handedly responsible for the developer community's positive take on Symantec. He wasn't there to promote, but strictly to assist.
He gave honest answers to hard questions, acknowledged product shortcomings, and painted an honest, open picture of the product's strengths and weaknesses. The developer community's collective opinion of Symantec soared.
Another anecdote from the public relations history of Sun's Java team paints an anti-example. In the first year and a half that Sun's Java group existed, members of the engineering team spoke directly with customers and the press.
Java grew from a glimmer, a possibility, to a platform with thousands of curious, turned-on early adopters. There was a general perception that Sun's Java team listened, answered questions, and was actively engaged with the community of Java developers.
After about eighteen months, the workload grew to such a point that we started shutting down our channels to the outside world. PR and marketing took over much of our contact with the outside world, and we put our heads down to deal with the increasing demands on the engineering team.
The reaction from our developers was stated in these precise words many times over:
"you disappeared." As we went underground, the perception of the Java group in the marketplace changed from "a small team of great engineers producing neat stuff" to "a hype engine to push Sun's stock." In projects that allowed engineers time to come back online more often, customers cut the engineers far more slack in their attempts to get things right than did the customers of their more close-mouthed brethren.
In such scenarios, of course, engaging in trivial conversations can chew up valuable time — though it's a tough call to know what's truly trivial and what deepens credibility in the conversational space.