Re: Technical Writing and the Business Perspective

Subject: Re: Technical Writing and the Business Perspective
From: "Gene Kim-Eng" <techwr -at- genek -dot- com>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Fri, 24 Oct 2003 13:57:50 -0700


A real-world example (no names, I still hang out with people from
both companies):

Companies "A" and "B" are competitors, and each designed what
could best be described as the "Swiss Army Knife" of the instrument
world. At least 50 different potential use scenarios. Company "A"
decided that 90% of their paying customers would only use 10 of the
50, and their product docs *only* cover those 10, in comprehensive
detail. Users wanting to know if some of those undocumented menus
could be used to <insert one of the other 40 possible scenarios here>
are referred to Product Support for a quote on a "custom application."
Company "B", otoh, documented - in equally comprehensive detail -
all 50 scenarios.

Today, Company "A" sells only 1/10 the total number of instruments
that Company "B" (the leading mfr in its field) does. Users of "A's"
10 scenarios almost never call Tech Support, despite the fact that
something like 60% of their SW menus are totally undocumented in
their manuals, because all the info they need is in their 60 page user
guide (or in the "custom application" guides they get if they pay for
the service). "A's" instrument makes a moderate profit. Company
"B," OTOH, spends more on Customer Support for its instrument
than sales bring in, and customers call in for all sorts of problems
with *every* application scenario, because they can't (or won't) find
the info they need in their 500+ page user manual.

Which company's products have the more "high quality" documents?
Which company did a better job of documenting its product?

Gene Kim-Eng


----- Original Message -----
From: "Goober Writer" <gooberwriter -at- yahoo -dot- com>

> It depends on your business model. That is why you
> should primarily satisfy business objectives and then
> look to address others as a subset. Your customers may
> personally benefit from rock-solid documentation, but
> your business might benefit from training and support
> contracts. Not to say you should write crap and make
> it up in other ways, but sometimes it makes sense to
> omit certain types of info so your customers do get
> info from docs, but can benefit from additional info
> provided by fee-based training and consultation. If
> this is your business model, and you disagree, you
> certainly do NOT want to literally write yourself out
> of a job.



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.520 / Virus Database: 318 - Release Date: 9/18/2003

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

ROBOHELP FOR FRAMEMAKER TRIAL NOW AVAILABLE!

RoboHelp for FrameMaker is a NEW online publishing tool for FrameMaker that
lets you easily single-source content to online Help, intranet, and Web.
The interface is designed for FrameMaker users, so there is little or no
learning curve and no macro language required! Call 800-718-4407 for
competitive pricing or download a trial at: http://www.ehelp.com/techwr-l4

---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit
http://www.raycomm.com/techwhirl/ for more resources and info.



References:
Re: Technical Writing and the Business Perspective: From: Goober Writer

Previous by Author: RE: Re: Technical Writing and the Business Perspective
Next by Author: Re: The unconfidentiality of techwr-l
Previous by Thread: Re: Technical Writing and the Business Perspective
Next by Thread: RE: Technical Writing and the Business Perspective


What this post helpful? Share it with friends and colleagues:


Sponsored Ads