In, This Is Why It Matters if Your User Guide Is Just an Afterthought, Bill Kerschbaum posits a scenario in which a potential customer, impressed by your glossy website, downloads a trial version of your software, is initially impressed, but then tries to figure out how to do something, is disappointed by the poor user manual and decides not to buy the full version.
My immediate thought on this was, but that is not what happens today. People don’t turn first to the user manual. The first thing they do is Google or ask their social network how to do something. Unless your user manual is online (preferably in the form of Every Page is Page One topics), and unless it ranks reasonably well in the search results for questions about your software, it isn’t even going to get a chance to disappoint. Instead, whether the user decides to buy your software or not is likely to depend on whether some other user has documented how they did the particular task they are interested in.
In other words: its a Google-first, manual-later-maybe-never world.
But then I realized that that is not actually how it works at all. The difference from the old world order of buy the product than read the manual is not that we now Google for the solution before we read the manual. It is that we Google for the solution before we buy the product. It is that we only hear about the product because it is mentioned in a solution.
Once we already own the product, of course, we then Google for how to solve new problems using it, because we already have money invested in it. But the scenario that Bill is describing is the one in which the user has not yet made a commitment to the product. The scenario he is interested in is the one in which the documentation makes a difference in the customer’s purchasing decision.
That, of course, is a scenario we should all be interested in. Show that docs drive sales, and you can justify your tech comm budget.
Image courtesy of Stuart Miles / FreeDigitalPhotos.net
But the scenario in which docs drives sales is not the one in which the glossy website generates the lead and the user manual closes the sale. At least, that is not the only scenario. It is not the scenario that has driven my last several software acquisitions (paid and free).
The scenario that has driven my last several software acquisitions is this: I have Googled for a solution to a problem and I have found documentation (usually from a third party) that describes how to solve that problem using a particular piece of software. I then downloaded that software, because I needed it to complete the procedure I was following to fix my problem.
Here’s the really interesting bit. I must have seen this 100 times before the significance of it hit me. In so many cases in third party documentation, there is a step in the middle of the procedure that says, download product X. That’s right — the instruction to acquire the software is part of the procedure itself.
Here’s an example from a WikiHow page on combining PDF files:
1. Open NitroPDF. If you do not own NitroPDF, you can download the free trial here. It’s free for 14 days; after that, you’ll be prompted to buy a license.
Here’s another, from a discussion related to solving BAD_POOL_HEADER crashes in Windows, from http://www.geekstogo.com/forum/topic/316114-bsod-bad-pool-header/:
Run hard drive diagnostics: http://www.tacktech….ay.cfm?ttid=287
Make sure, you select tool, which is appropriate for the brand of your hard drive.
Depending on the program, it’ll create bootable floppy, or bootable CD.
If downloaded file is of .iso type, use ImgBurn: http://www.imgburn.com/ to burn .iso file to a CD (select “Write image file to disc” option), and make the CD bootable.
Pretty cool, I think. The reader is invited to acquire the software to solve a problem right in the middle of the procedure that solves the problem.
Though we have been telling ourselves for decades that our task is to document the user’s task, not the product, we have always worked on the assumption that the user has already purchased, and is committed to accomplish their task using, our product. We assume they already have the product.
But in a procedure truly focused on the user’s task, the selection and use of particular tools is not a presumed starting point for the procedure, it is part of the procedure.
This is what sales and marketing folk call the “call to action”. Inviting people to buy your stuff. Marketing 101 says that there is no sale without the call to action. So if we want to argue that documentation drives sales, where is its call to action? If you write as if the action had already taken place, there is no place to put the call to action.
Of course, in the days when we shipped user manuals in boxes with the product, there was no point in putting the call to action in the user manual, because the user would not have access to the manual until after they had already taken the action.
But on the Web, people do not lay out cash for a product hoping, based on the copy on the outside of the box, that it might solve their problem. They Google for a solution to the problem and buy the product because it is part of the solution they have found. They solve first, buy afterwards.
When we move our documentation to the Web, one of the key things we must remember, therefore, is that a major part of its audience includes people who have not bought the software, and whose modus operandi is to solve first, buy afterwards.
This means that when they hit your content, they don’t own your product, and are not necessarily even aware of your product. They have landed on your content because it contains a solution to a problem they are having. They will respond well if the content begins not with your product, but with their problem. And if you provide a good solution, you set up a perfect opportunity for a call to action that sells your product.
Today, people solve first, buy afterwards. Give them a solution that they can find on the web and that addresses their task, not your product, and you will have created the perfect conditions for a sale to occur.
Make the call to action. Then go and show management how you are driving sales, and ask for that tech comm budget that has been turned down so many times in the past.
Hi Mark,
As usual, an excellent post, and I think spot-on for a certain class of software products. But probably not so applicable to other classes of software. I currently work for a company that sells electronic medical records software and associated apps to everybody from small practices to huge healthcare organizations. Obviously, this is not software that a doctor is going to just read about and download. Nor do I think information on the web is going to be a big influencer, either. Prospective clients are going to talk to other physicians and organizations, learn about the pros and cons of their experiences. They’re going to talk to our sales people. It’s going to be a long and careful sales cycle, because it’s a huge financial investment that carries with it the enormous burden of having to be right or else risking the effectiveness and integrity of the entire organization. And finally, it’s not likely that our users are going to be posting a lot of feedback or tips and tricks on the web because of the confidential nature of the data involved. We are, of course, always eager to increase our (tech pubs’) visibility and value to the company, so how do you see this model of documentation availability fitting into companies that have a large but very narrow user base constrained by issues of confidentiality?
Thanks,
Leigh
Hi Leigh. Thanks for the comment.
Clearly the notion of step 3 being to download the software is not going to work for products of that size and complexity.
One the other hand, products of that size and complexity have been bought on the solve first, buy afterwards model for a long time. That is really what the whole RFP process is about: it lays out a problem to be solved and invites vendors to show how their product solves the problem.
The interesting question is, how much influence does the web have. You say that prospective clients are going to talk to other doctors and organizations. The question is, where do that do that conversation. Increasingly, the web is the place that people talk to each other. But the practice is not evenly distributed yet. The easy way to find out is simply to Google some typical question in your space. And indeed, there is no obvious community discussing medical records management on the Web.
I think the primary way that tech pubs can help drive sales in these kinds of situation is during the evaluation period. Even if your docs are not available on the Web, they have to be available while the prospects are doing their technical evaluations. I’d also look at the RFPs and see how well your docs match up with the things people are looking for in the RFPs. Responding to RFPs can be onerous, so if tech pubs makes it easier, that’s a big win, and of definite value to the company.
I think we need to talk about certain classes of users. If we look at learning models, above the competencies of learning and understanding, there are levels you can loosely group and call “mastery”. In Bloom’s taxonomy, they are called Analysis, Synthesis and Evaluation.
As some users have become more skillful and some software has become more intuitive/easier to use, this class of user has been interested in mastering a product. This mastery information tends to be more of a dialogue, presented in screencasts (certainly for video games) rather than in an “how-to” manual. So for a sophisticated user such as yourself, you’re looking beyond the manual.
However, not everyone is at that level, and not all products are simple and familiar to use. Some are complete learners, others are learning how to be functionally competent. This means both Bill and you can both be right – it depends about whom you are talking.
Thanks for the comment Ellis.
I don’t think Bill is wrong. I think everything he says about how the manual can affect the sale is spot on, for those who read the manual. What I am arguing is that the larger opportunity for tech pubs to drive sales may lie on the Web rather than in the manual.
I agree that there are different levels of users, and that different forms of content can work for different users, and that therefore gives us different ways to make the call to action part of the content.
I’m not sure though that we can conclude that it is beginners who read the manual. We write the manual for beginners, certainly, but I don’t think there is much evidence that beginners are the ones reading it. Beginners often prefer to ask someone. Any form of written communication is harder to deal with when you don’t have any grounding in a subject, which is why I think people would rather ask. And the Web is full of places to ask. Indeed, much of the tech comm that exists on the Web today was created as a result of someone answering a question asked by someone who had not read the manual.