Tina the Technical Writer doesn't work here

If you're a technical writer, you may have had this experience:
The new guy on the product support help desk walks in, holding the system administrator's guide that you designed, researched, wrote, and illustrated. He scans your cubicle, looking for signs of - heaven only knows what, but clearly it's not there.

Help desk guy: "Hey, I just started here and they handed me this manual. It's great! Who wrote it?"
You: "Um...I wrote it. I'm the technical writer."
Help desk guy (gawking): "YOU wrote it??"
You: "Yes. That's my job. I write the manuals. I write the help, too."
Help desk guy: "Who helped you with it?"
You: "Each of the developers answered my questions about the features they own, and they each reviewed the topics where their features are discussed."
Help desk guy (floundering): "But...I mean...how did you know what to write?"
You: "I started with the product requirement documents and the feature design documents, and I spent a lot of time playing with the product as soon as it was stable enough for me to poke around at it."
Help desk guy: "You actually use the product?"
You: "Sure. There's really no other way to get familiar with it, and I have to understand it myself before I can help other people understand it."
At this point the help desk guy generally wanders off to recover from having his world rocked.

If you've ever had that conversation with the disbelieving help desk guy, you know the source of his disbelief and your frustration: Enough people have encountered non-stellar tech writers that stereotypes exist. You can't change that. Neither can I. The only thing we can do is choose not to conform to the stereotypes.

So forget Tina the Technical Writer, the character in Dilbert. She's a cartoon character. Roll up your sleeves and get into the technical details of the thing you need to explain to your customers. Tell your developers when you spot things that may cause problems for customers - "Can you build some validation into this field? Right now, this form lets me build a test condition that's nonsense." Focus on what you do best and let the stereotypes take care of themselves. It doesn't take long for people to realize that whatever they expected, in you they've got a person who readily grasps technical concepts, is passionate about communicating useful information to people who need it, and visibly contributes to the organization's success.

Manuals are not the point

With the sole exception of my first technical writing job, every time I've been hired as a writer, it's been by someone with a vague notion that their organization needed manuals. More manuals, better manuals, up-to-date manuals.

We technical writers tend to justify our jobs by saying our employers or clients need manuals and help systems, and usually that's where it ends. We sound like Mr. L. Prosser, the road construction foreman in the opening of Douglas Adams's book, The Hitchhiker's Guide to the Galaxy, justifying the demolition of the protagonist's house by explaining that they're building a highway bypass, and "you've got to build bypasses." Press a technical writer to explain why our employers or clients need manuals and help systems, and things get vague fairly quickly.

The truth is, you don't need manuals. You need the right product documentation, delivered in the right medium to meet your customers' needs. The business case is very simple: It saves you money, and it saves your customers money.

The wrong material, though - a poorly organized manual, or a help system that focuses on what the product or service does instead of the tasks your customers want to accomplish with it - is worse than no manual at all. It frustrates your customers. It undermines their confidence in your product or service.

The right product documentation gives your customers the confidence to set up your product or service and become proficient with it faster than they would otherwise. Just by reducing your customers' time to success, you've saved them money.

Beyond building your customers' confidence and getting them from zero to success quickly, you've also avoided the all-too-common technical support call in which the customer says plaintively, "I can't figure out how to set this up." If your organization doesn't have a technical support function, your engineers or developers may be the ones talking your customers through basic steps. All the goodwill in the world won't make up for the drain on their time and the interruption of their thought processes. Worse, if a customer has trouble using the product documentation and places a technical support call instead, you've just induced and reinforced this costly behavior.

With the right product documentation, your customers feel confident enough to take their first steps without asking for help - and when they realize they can easily find the answers to their questions in the documentation, they only call technical support if something isn't working right. Your engineers spend their time engineering, your developers keep on developing, and your customers gain confidence in your product or service.

Getting out of the box

Anybody can write - right?
Sure.
But do you want just anybody writing the help or the administrator's guide for your product?

Your product development team has worked hard to bring a vision into being. You wouldn't have spent the time and effort on it if you didn't believe - passionately - that the project could meet your customers' needs in a way no other product can do. Your team wouldn't have put their hearts and souls into developing this product unless they believed in it. Doesn't your team deserve to have their brilliant work showcased? To put that another way: Shouldn't you give this product the best possible shot at success?

Great product documentation shows your customers how simple it is to use your product, and makes them want to try out all its features. Because as complex and sophisticated as the design may be, as elegant as the code may be, what's going to sell your product is the perception that it's robust, reliable, and easy to use. Great product documentation gives your customers the confidence to get familiar with the product - and once they've cleared that hurdle, the product looks a lot easier to use.

What does great product documentation look like? Like Supreme Court Justice Potter Stewart, you probably know it when you see it. But what is it that you see?

In great documentation, you see little about the product's capabilities or design philosophy. Instead you see information about how people can use the product to accomplish what they want to do. It's about your customers first.

It's easy to make the business case for top-notch product documentation - be it installation drawings, administrator's guides, quick tip sheets, or help: If that's part of the package, you'll win more competitive evaluations, and you'll spend less on technical support. And amazing as it may be, it takes fewer words and less time to communicate the people-centric information that your customers need than the design-centric material that they dread - so even the direct cost of creating great product documentation is lower than the direct cost of creating lower-quality material.

Move your product documentation out of the box. Put it on the winner's platform - along with your great product.