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.