Technical Communication with a Purpose

Defending the Documentation Budget

PDF download icon
Money is tight these days, especially in the software business. When money gets tight, budgets get cut. Unfortunately, sometimes the wrong line items get cut. Often, far too often, software companies cut the documentation budget when they shouldn’t.
Balancing Time and Dollars
This is because most software companies think of documentation in the wrong way. Nearly everyone—VPs, engineers, sales reps—thinks of documentation as this thing that you need to have to be able to say that the software is done. Some even recognize that it has this niggly, bean-counter purpose of reducing support. However, both of these points miss a critically important function of documentation. One of the most important uses for documentation is selling the software—not in some vague, this-might-be-OK, eye-candy flyer way, but in a more concrete, get-the-order way.

Think about the typical sales process. Your company has given someone a great demo and it has gone well, but everyone (you and your prospect) knows that demos can be a perilous walk down a thin path of working software, with a swamp of bugs and “unimplemented features” on all sides. The customer is interested in committing some bucks, maybe even making a big buy, but they want some time alone with the software, time to push on it and see what works and what doesn’t. And, they don’t want you there. So you have to leave them with the software CD and the docs.

The next day, the manager with the money gives the CD and the docs to someone to evaluate—not their best person, because he is too busy. Maybe not their worst, either, because the manager doesn’t trust his opinion; but, it might go to the intern as a test to see how robust the software is. The instructions he will give this person will be something like:

Take a look at this in the next day or two and see if you think it’ll work for us. Don’t take more than 4 or 5 hours and I need an opinion by Wednesday at 1, by email.

Now the intern is in his office with the CD thinking, “How am I going to get this done with all the other crap that needs to be done by Wednesday.” And, if he wants to he can do NOTHING with the software and just say to the boss, “Naw, I don’t think so. Too many bugs and it looks like it was designed for a different kind of OS than we use,” and the boss will go with that.

This is when the docs need to go to work. This is when the docs need to sell the software. The first thing the docs need to do is get him to install the software. The install document needs to be easy to find, clearly labeled, and it needs to tell how long it is going to take to do the install. When he’s trying to decide if he can get the install done before lunch, the install guide needs to tell him “Sure! It’ll just take five minutes!”

Now that the software is installed, the docs need to make it easy for the evaluator to solve his problem. The docs need to know what kinds of problems he needs to solve with the software, and they need to show him how to do it easily. He should be able to pick up the docs and find his problem (or something like it) in five minutes. Then, the docs should show him that the software designers understand his problem and that the software will solve his problem.

Within the first fifteen minutes, he should be thinking, “This looks pretty good.” Within the first hour, he should have an idea how to solve the boss’s problem. And within two hours, he should be able to try a solution and see that it works. At the end of the four hours, he should have tried another variant, found out that the manual isn’t lying, and then be looking in the manual for features that will make it a better fit for their needs.

If the software and docs pass this test, chances are some sort of purchase will get made. Yes, new requirements will be discovered and demands for new features will be on the way, but after they purchase, they are a customer. They won’t switch to something else unless you fail them. But the docs will have fulfilled one of their most important functions—they will have gotten you a sale.

If you think your documentation budget is being cut in a way that will harm the product, in a way that will make the product harder to sell, try introducing your marketing folks to the idea of documentation as a marketing tool, one that will stay with the prospect and sell them on the details of the product.

And, if you need help getting the docs done, please give Expert Support—that’s where I work—a call. We understand software, we understand how people really use software, and we understand documentation. We can create superior product documentation for your software that will help your software succeed.

Tell your friends:

We have a few of our calendars available. Would you like one?