A while ago I went to a tech writers meet-up. During the usual introductions I usually end up asking the people I meet, what they do. On that day, I met someone that dropped this one on me:

“I create documents that add value to the business”.

I found this a bit odd since it basically means, “I do stuff”. Since I had just met the person and didn’t want to be that socially awkward and inquisitive guy, I moved on.

Later on as more people arrived, this one person kept on repeating the same sentence, just like if it was previously trained in front of a mirror. “I create documents that add value to the business”.

This led me to think that she didn’t really understand how did she fit in the company she worked for. Unless her company makes money by producing documents, I don’t see how she can add value to the product or service her company sells, by creating documents. If she really understood how she created value by creating more documents, she would not be presenting herself as someone who “does stuff”.

I know, I know, I’m oversimplifying it, but the point is: documentation is a collateral, a means to an end. Unless your company can make money out of producing documents, then the documents are just a way for you to educate your prospects and customers, so that they understand that with their skills and your product, they can become more effective and productive. And that my friends, is what people pay for.

Documentation as a source of revenue

There are a couple of business plans where delivering documents, really means delivering value to the business. These are a few examples I can think of:

• Authors or publishers. They make money by selling (hopefully interesting) content;
• Internationalization companies. They make money by converting documents from one language to another.

I’m sure there is some kind of business model where a company develops a product and pays another one to produce the product’s documentation. Since I don’t believe you can do a good job outsourcing this to another company, I’ve not included that business model in here.

Documentation is a means to an end

If you work for a software company, then you cannot say that the documentation adds value to the business. Because your company does not sell documents, it sells software. But there’s a catch.

Documentation is relevant for both evaluators and existing customers. Evaluators might not have the time or the chance to test drive your product, so you need to tell them what makes it unique. As for existing customers, you’ll need to create an efficient way to answer their questions without being interrupted. One solution for this is documenting your product.

So you can say that the documentation you create for your product or service supports the product. The value comes out of the product or service, the documentation is just a necessary evil.

If you don’t agree, just imagine that you created all your operations manuals, technical notes, and all other kinds of documentation, but didn’t implement a product. Would anyone read that? Of course not. On the other hand, if you create a meaningful product without documentation, would anyone use it? I’m betting that they will, if the product is in fact meaningful to your customers.

Evaluating software products

When your customers are evaluating your product, they will be trying to compare it with other existing products they already know. They will also have lots of questions in their mind that you need to answer, to convince them to buy your product.

Here the importance of the documentation grows with the complexity of your product. I’m not talking about complexity in its negative connotation. I’m talking about the number of new concepts that end-users need to learn in order to use your product.

So you can place your product between these two extremes:

• Simple app. Simple text editor, news consumption app, email, etc.
• Very complex system. Software for managing a nuclear power plant, a car electronic system, etc.

Since simple apps like text editors are cheap, and there are a lots of them available, your customers won’t invest much time evaluating it upfront. Since these apps are cheap, the cost of buying one and finding out that it is not suitable for the task your customer wants to achieve is low.

Another important factor to consider is the cost associated with the change. If your application stores the data in standard formats, the cost of change is low. If on the other hand, it stored data in a proprietary format, or does not let customers export their data, then the change cost is high.

That’s why you won’t waste much time evaluating text editors. There are lots of alternatives, some of them free. So it will cost you close to nothing to get one, and then change to another if you feel like it. Since text editors all read and output the same format (text), the cost of change is virtually zero.

Compare this with buying a complex CRM product. When you are buying one of these, it is a huge investment. It is very expensive, so not only the money you are investing is important, but also the opportunity cost. If you choose the wrong one, you’ll not afford no buy another any time soon. Even if you had the money to replace that system by another, it would cost you a lot to make the change.

Using a software product

I’ve also mentioned that documentation is relevant for existing customers. People nowadays take this for granted, but you should really think about it. You could either ship an existing consultant every time you sold your product, or you could design a product that requires no documentation.

Yes, both approaches seem ridiculous for different reasons, but are not impossible. So your documentations strategy really depends on your company’s business model, and (again) in the complexity of your product.

It’s easy to imagine what really takes to document a simple application like a text editor. The most frequent use case is writing a something, so by just documenting that single use case you’d be documenting 80% of your customer questions. In contrast, using a CRM product is much more complex. Since there are different use cases, you would really need to think which ones are the most important. And even if you documented those, probably it would not cover more than 50% of your customers questions.

So, the more complex your software is, the more important it is the documentation that supports it.

Final thoughts

The CRM example I gave is probably a good example that shows why SaaS products are common nowadays. Since you pay a monthly or yearly fee, instead of paying for the product upfront, it makes it easier for prospects to evaluate the product and their exit options.