The Business of Software

This is a partial repost of something I just responded to in another thread, but is interesting enough I wanted to have its own thread since it's a different topic.

A common advice for customer service requests is to improve the documentation, and this we have done for many years.

But I've noticed that we've reached a new level of this. Improving the docs increases the number of service requests.

Two reasons for this, based on feedback from customers seeking support:

1. Documentation is now so comprehensive that it is intimidating. People see a 1000 page manual and say "no thanks - I'll just call customer support instead."

2. Documentation has so much cool stuff described, that it makes people's imagination stimulated and they start thinking of other, even more exotic stuff they want to do but can not figure out and start a service request for it.

Thus, the common solution to service requests - better documentation - actually causes more service requests, not fewer.

It's a problem with software that is used to create things and not just read emails or such. People start to want to know how to be creative and hope that several hundred hours of personalized instruction from customer support will help and perhaps will be comparable to the similar experience of taking a college class.

So what is the answer? Other companies have faced this problem as well. The solution might be to offer classes for a fee. Big companies do this. Apple has a yearly convention where you can go and take seminars - at a fee of a few thousand dollars for the weekend.

But can small companies afford this as well? If not, perhaps just offering the service to the one or two customers who want to pay the fee can at least constrain this sort of service to a single weekend per year?

I don't know, but I will probably try something like that soon.

If you're a one man mISV then you seriously have to consider the business risk that a competitor will duplicate your product's functionality.  To put it another way, if you make a Photoshop plug-in, you have to acknowledge that Adobe could potentially develop their own version of the plug-in, in less than two years.

If your product is sophisticated enough that you quite literally have 1,000 pages of documentation, then yes, I would encourage you to treat that as a business opportunity.  The original poster mentioned on-site training, conferences and workshops.  I would also consider writing a book.  Selling the books and the classes would be a second, separate line of business, as opposed to an extension of the first.

In the event that Adobe does sell their version of your plug-in, you would hopefully be at the point where you can abandon your product, and instead modify your teaching materials to emphasize Adobe's product.  You would just then become a third party training resource.

I think that overall would be the easiest thing for an mISV to do but depending on your product, there are also additional solutions.  For example...

1) consider raising your prices such that the only people who'd buy the product are also the people who are willing to read the manuals and learn how to use it.  (In other words, discourage casual hobbyists.)

2) develop a lite version for hobbyists if you think the bulk of your revenue and support requests are coming from such people.

3) set up a forum where people can support each other and separately, charge per incident for the cases where people insist on your assistance.

4) hire user interface consultants and copywriters to review your product and documentation, and suggest ways to improve both; maybe an action is common enough that it's worth developing a one-click command as opposed to forcing users to do multiple steps.

5) depending on the product, consider a Clippy style wizard that can guide people through the steps the first time.

That's off the top of my head.  I'll revisit the thread if I think of anything else.

Consider short video tutorials for the most frequently-asked questions.  With something like Wink it's very easy to do, and could get you out of your immediate jam.

After that you could consider leveraging them (or more advanced ones) in a paid-access training forum, even holding a (perhaps scripted) seminar and filming it for those who want to quickly become experts.  Adding a book (like TheDavid suggested) could only help, but it could be a "workbook" to start, only to be fleshed out if you need to later.

if you could find a way to charge for service this would work out well. Oracle has 10s of thousands of pages of documentation. One of their most successful areas of business is support.

have you found that improving documentation has lead to more sales? More customer loyalty? customers buying more products? if not, then there is no business reason to improve your docs further.

have you thought about breaking up your document into several smaller documents instead of one big one? That is less intimidating.

Getting Started Docs
Doc on X
Doc on Y

etc...

"better documentation" does not mean more pages.  Your documentation has to be targeted to a specific audience.  End user docs are generally shorter, less technical, and intended to give the user an understanding of how to use the program.  It sounds like you are building too much into documentation for that particular audience.

Should you improve the documentation or improve the product?

We often make the decision to change the UI or the program functionality to so we can write _less_ documentation.  If it's hard to document or requires a lengthy explanation you will have trouble selling it.

Changing the UI requires a lot more imagination, work and decision making than writing a few more pages of documentation but it's worth it.

Just to clarify here, I agree with what you guys are saying, but none of this is new to me. As I mentioned in my post in the other thread that I partially quoted, yes we have comprehensive video tutorial support. I should add that there is a getting started manual that's simpler than the comprehensive reference, and the 1000 pages is not in a single document.

You can do lots of things with the product. The manual is how long it is. It's consistently referred to by people who have read it as the best product manual they have ever read.

And yes, for a long time I have embraced the tactic of finding something hard to explain in the manual and then writing 20,000 lines of new code to implement incredibly complex behind the scenes functions only for the purpose of eliminating steps that the computer can do and then rip out 10 pages of the manual.

We often here on this boards to improve the documentation. I am sure I have said that a bunch of times.

I mostly posted here to highlight this interesting phenomenon where at a certain point in the curve, better documentation starts to result in more service requests, and my thoughts that one way to address that might be to have paid seminars in real life.

A related topic is the "fire your customer" advice. I think that is reasonable in some very extreme circumstances of abuse, but it should not be an option when dealing with a customer who is sincerely trying to work with the program. Also, the level of abuse I tolerate is pretty high. I just had a customer go nearly insane a couple weeks ago and I totally wanted to tell him off, but I remained calm and now the guy is happy and recommending the software to others.

That was addressed as well. It's very common that these guys that need such intense instruction will highly recommend it, and also will become themselves teachers to others of advanced techniques, writing articles on their own blogs describing how to do things and so forth. So I think it's worth it to be nice to everyone and try to help them if possible. My own thoughts are about the ones who actually show up at the office for classes that don't really exist. Maybe they should exist since there is a need for them among some.

Scott, I for one clearly understand what you talk about.

Our app is also of the kind where the user can (and must) be creative. The more capability you add to the product the more complex ways of usage the users find.

I am not sure there is necessarily a correlation between the size of docs and service requests. You do not improve your docs without touching the product, right? So my take is that it is improving the product, making it more flexible causes more service requests. Your observation about the docs is likely a natural coincidence.

This probably does not apply to a typical small utility but it is valid for the development tool that we sell (don't know what is your product).

To add to the above.

No matter if your doc is 100 pages or 1000 pages I do not think it matters. Does anybody read entire documentation, all 100 or 1000 pages? Unlikely. Most people search for what they need (our docs are supplied both as CHM manual with index and online searchable via Google).

"..We often here on this boards to improve the documentation. I am sure I have said that a bunch of times.."

It's also been repeatedly said (at least by me on numerous occasions) that you should *avoid* the need for documentation as much as possible. The App should be self documenting and as simple as possible.

If the feature isn't something simple enough to market (and 1,000 pages of features sounds difficult to fully describe in any advertising ;-_) then I'd question whether those features are 'selling' the product. Seems like the functionality is a function of the doc complexity.  And while price is  a function of value not cost of development, the price better be above the cost or it's what we call a hobby (or what Chrysler used to call a "business")


There are times when software just needs to be that complex. But int those cases it had better be super valuable and help you get a lot of work done. In which case (as said above) this is an opportunity for training classes, etc.

How about a user forum where users can educate one another?

I really dislike the no-documentation-is-good mindset.  The problem with it is that can work fine for the basic user, but blows up badly on the advanced user.  I am currently fighting with Outlook and MAPI.  I have spent many hours digging through examples to little avail.

Oh,  sure there are Web pages, but quite often, the alleged solutions are followed by posts that it did not work on the user's system (and often others saying that it worked fine on that user's system).

Sincerely,

Gene Wirchenko