Top 6 ways technical communicators can benefit from the groundswell

When Anne Gentle mentioned the book Groundswell on her reading list the other day, I was just in the middle of it. Now I’ve finished it and thought I’d report back on it.

Groundswell is a book by Forrester analysts Charlene Li and Josh Bernoff. This groundswell is “a social trend in which people use technologies to get the things they need from each other, rather than from traditional institutions.” It’s about how web 2.0 social media change online marketing and CRM as well as the corporate culture that drives it.

So the book is not about technical writing as such. However, I think technical communicators are in a good position to promote and benefit from the groundswell, especially if they collaborate with marketing, customer care or product management teams. (Caveat: “Groundswelling” doesn’t work in every company. Your mileage will vary, depending on your position, leeway and corporate culture!)

So here are my “Top 6 Ways Technical Communicators Can Benefit from the Groundswell”!

6. Understand why no one reads the help anyway.

Because “people believe other people more than media” (p. 131). It’s the reason why users resort to forums or search engines and why reader recommendations beat publisher blurbs.

Scott Abel makes the same point that “Users don’t care where they get help from – they just want to find the answer to their problem when they encounter it”, and if it’s from another user at 2:30 a.m.

5. Apply a high-level process that puts people first.

Li and Bernoff suggest a 4-step “POST” process (67f.) as a guide when communicating with users:

1. People: What are your customers ready for?
2. Objectives: What are your goals?
3. Strategy: How do you want relationships with your customers to change?
4. Technology: What applications should you build?

With a little tweaking, this process is beneficial to tech writing, too. Granted, our objectives are usually a given. But note that technology is last on the list, since they start with the users. That’s always a good idea, whether you do conventional audience analysis or – as Li and Bernoff suggest – you try and figure out just how much you can and want to involve them. Which brings us to…

4. Decide what kind of relationship you want to have with users.

Beyond talking at them with online help or printed documentation, technical writers can

1. Listen to what users have to say (publicly) about your product, either in forums and blogs or in a hybrid format such as help comments as MadCap’s Feedback server provides them.
2. Talk with users. Engage in a sincere dialogue. Participate in forums and communities as a representative of your company – though check with management first… Maybe you can even initiate or join a corporate blog (108ff.).
3. Energize enthusiastic users into evangelists for your product (130ff.). The MadCap forum assigns different “propellerhead” titles to users depending on their number of contributions, because “allowing participants to build up a reputation is crucial” (175).
4. Support users to support themselves. Give them a way to share their experiences constructively. You’ll save on support queries and gain user insight. Call it psychic income or karmic debt, “people are willing to spend lots of time helping each other, if you just get out of the way” (158).
5. Embrace your users so you can collaborate to create better products (176). You might just ask them to step into your shoes as product manager for a day: What’s the one thing you would improve about the product? (188) – Be sure to follow through on some of the suggestions.

No matter what relationship you’re aiming at…

3. Take your users seriously and engage them…

… especially when you’re in a public relationship that will shape the reputation of your company and product. Because “people expect you to listen and respond to them” (176).

• Be sincere and honest: A public reply in a forum or blog may thwart off dozens of support queries. Even if you don’t have an answer (yet) to a common bug or problem, users will appreciate that they’ve been heard and that you’re working on it. (I know I would!)
• Inspire users to make a difference work towards a common goal of a better product.
• Close the feedback loop and show them how you’ve improved your product or service after their specific feedback.

The theme is again to focus on the relationship with your users, not the facts of your product. The claim is that features & bugs are less important than how you deal with them. (I’m not sure I’m buying this, but I appreciate the alternative perspective…)

So your documentation should do justice to your users and their needs – rather than your product. Which we’ve heard before in task-based documentation.

2. Channel and mediate user-generated content.

Users can contribute using any web 2.0 format, whether they’re making suggestions, complaining about a bug or a bad user interface or offering tips or workarounds to other users.

Blogs offer topic control at the price of more maintenance efforts. Wikis and forums are also well suited to help with complex products (124, 163). But make sure to treat collaborative channels as such: “Think of the wiki as our wiki – yours and your customers’.” (169)

1. Become an in-house advocate of users.

You’ll potentially join customer service representatives and testers in this. Yet when you listen to users (and can prove that you do), you will be more confident about your documentation and its usefulness. When you can also prove that your documentation actually helps users to be more efficient, you’ve added real value to boot.

Remember, though, that listening goes both ways: It gives your customers more influence in shaping your brand and your product.

Noz Urbina explores similar themes in his episode of Tom Johnson’s perennially excellent podcast Tech Writer Voices.

– If you think this has been helpful, please leave a comment!

• Is this actually applicable – or just marketing talk with little bearing on what we ought to be doing?
• Are such digests of management or marketing books useful, can we apply them to technical writing?