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.