My assumption has always been that customers refuse to read documentation (or e-mails for that matter). Maintaining an up-to-date comprehensive manual is very involved (potentially a full-time job). I would much rather spend my limited resources coming up with software that is easy to use.
On the other hand, when speaking with potential customers I often get asked to provide a product manual or guide.
What works for you? Do you find that having a manual helps with sales or reducing support costs? Do you think a more strategic "How-To" guide works better? What about a "training mode" built into your software?
Customers don't "refuse to read doc."
Truth: They won't go there first; they often prefer to email tech support.
But when the answer is in the manual, the tech support response becomes trivial, and people don't mind being pointed to the manual if it really does solve their problem.
If that happens once, that user is more likely to consult the manual first next time, reducing tech support again.
However, can you release version 1.0 without a manual? Of course! If the manual is still out of date should that prevent releasing a new feature that might make more money? No way! The manual is certainly secondary.
But it's not useless.
I agree with other answerers that "the manual" need not take the form of the traditional PDF-or-online system, although there's nothing wrong with that system. Forums are good too.
Main thing: Make it searchable!
You reference potential customers as those requesting a manual. For 'pre-sales' use, it seems the trend is screencasts that show off the software. Something along those lines may satisfy those wanting more information without the cost of a fully documented manual.
After the sale, if you don't provide some kind of reference or manual, I'd say your product needs to be dead simple to use, or you need to provide quick and complete support. Or just buy a stack exchange site and use that in place of a manual.
I think the idea of going with a short & sharp how-to guide, backed up by a few FAQs, is the right one. You are very wise to be reluctant to invest too much time and effort into a manual that may never be read.
A few screencasts of specific features and a gentle introduction would round out user documentation pretty well.
If potential customers are asking for a manual you may want to write one, and just have a few ready to be printed off, or at least have it available as a PDF.
One way I judge software is by how thick the manual is. If it is intuitive then the manual shouldn't be needed, but, you may need some basic manual to explain how the application is laid out, to give some guidance on how to use it.
You can explain that your manual is thin because you have put a great deal of effort into making it intuitive to use, and that a big part of the beta test is to see how well people do with no training.
Our experience has been that the documentation is very useful during our sales process and for handling support. We often can answer a user's presales inquiry right from the manual, so we do, usually in the form:
{Summary answer to the question} and you can read more in the online documentation:
{link to the right page in the doc} This has worked so well it's now a test case for us- if we get a question twice that isn't in the manual, we make sure it goes in for the next round. This is a bar you could also use to build incrementally: Make sure you hit the questions you're getting asked as well as the paths TO those questions in your application. That way once people "learn" that the answers are faster when they go to help they'll continue to do so.
As a bonus, you can look at your web stats to see what people are looking at which is a great piece of data to have. If a page is getting a lot of traffic then it's likely both an important feature, and a confusing one. Two things worth knowing.
We purchased a documentation tool early on to help us "single source" all of the documentation for our product - it can create HTML help to ship with our application, Visual Studio integrated help (our customers are developers), PDF's (which we've done when people ask for a copy) as well as the full web help, which you can see here.
I wonder why your customers are asking for a manual or product guide. So, here are a few strategies to deal with that, depending on the reason for the requests.
First, your customers may really need a manual. This may be due to the following reasons:
Then, at least an online manual is useful. Maybe, FAQs or similar would also do the job.
Second, the requests for a manual may just be a sign of your customers mistrust or fear; your prospects could have problems judgeing the value of your product. This may be due to the following reasons:
In this case, your manual is technically not really needed. It just serves as a signal of your commitment and the (hidden) quality of your product. But having one could raise sales. If such a case, here's a tip: The more expensive and throughout it looks, the better.
However, you may also use other means to signal your commitment. The look and the amount of your advertising and sales material are possible options: Better web page design, high-end advertising, display of other companies' trust in your product, etc.
Third, the request may just be an adhoc objection, raised to find any reasons to not buy right now. Then, you would only get these requests during sales meetings. The best response would probably to ask, why they would need such a manual; followed by reasons why they wouldn't really need it, since your product is designed to be useable, requires no training or manual, etc. etc.
Hope this helps.
I might say that if your product need a manual to use, your product have to be remade.
I think that making a manual, is just a proof that your product is not easy to use (I don't like the term "Usable").
My advice is:
Review your product usability issues, make a few tips inside the screen, and try to keep it simple...
I guess you'll save some hard work of documentation.
Good Luck pal..
Why don't you create inline documentation on the application or a tooltip instead? Wouldn't that be easier to maintain and easier for the user?