Beyond features & benefits, beyond good relationship building, beyond even budgetary restraints, sometimes your customers choose a product based on a single reason: they go with the company that offers the best documentation.
Mark makes the case that many companies will blame every department for the problem (It's a sales problem! No, marketing! No, tech support!) before looking at their documentation. Based on what I've seen in the building product industry, I would agree. Just last month at World of Concrete, a dozen companies told me they were having trouble reaching architects, but they knew it wasn't their guide spec because they've been using the same "tried and true" document for over three decades!
Fine, but is it possible that in the past 30 years your product has changed a little bit? Or the way people search for information is slightly different? If so, then maybe it's time you update your technical documentation for the new millennium.
Even many companies that have good, meaning functional, documentation miss some important opportunities. Starting with a simple one: did you make it possible for clients to include your documentation in their specs, or easy? Did you provide data or answers?
From Mark's post:
Which means that having good documentation does not mean just print documentation. It means posting it online, and understanding that digital media is used differently than print. Posting that 400 page pdf Mark describes is functionally the same as posting nothing at all.
Over at the Mindtouch blog, Mark Fidelman suggests It’s Not Your Product, Your Documentation Just Sucks.
Do we really have to wade through your 400 page text-based manual you’ve posted online in order to find out why an error keeps us from using your software? Worse, when we finally find the answer it’s incomplete. So what do we do? A Google search and find the answer elsewhere.Great advice, and a well thought-out post (although the end turns a bit into a sales pitch for "customer experience" software). And especially important to remember in the construction industry.
Mark makes the case that many companies will blame every department for the problem (It's a sales problem! No, marketing! No, tech support!) before looking at their documentation. Based on what I've seen in the building product industry, I would agree. Just last month at World of Concrete, a dozen companies told me they were having trouble reaching architects, but they knew it wasn't their guide spec because they've been using the same "tried and true" document for over three decades!
Fine, but is it possible that in the past 30 years your product has changed a little bit? Or the way people search for information is slightly different? If so, then maybe it's time you update your technical documentation for the new millennium.
Even many companies that have good, meaning functional, documentation miss some important opportunities. Starting with a simple one: did you make it possible for clients to include your documentation in their specs, or easy? Did you provide data or answers?
From Mark's post:
Most organizations are optimized for short term revenue growth not in building a sustainable relationship with their customers.The move to digital by the construction world has been slower than the mainstream business community, but it is happening. There is a real perception now that finding the information online is "faster" than a phone call or email. And that's true, if your site is structured well enough that the first search finds the needed information. If not, then your client is going to waste a lot of time finding it. Or they will call, but only after they've become frustrated.
That may have worked in a pre-internet world, but it’s not going to fly now. Why? Because your prospective customers are going elsewhere for support. That elsewhere may be your competition.
Which means that having good documentation does not mean just print documentation. It means posting it online, and understanding that digital media is used differently than print. Posting that 400 page pdf Mark describes is functionally the same as posting nothing at all.