TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: Dealing with a vague document request From:Julie Stickler <jstickler -at- gmail -dot- com> To:Joe Weinmunson <litlfrog -at- gmail -dot- com> Date:Thu, 23 May 2019 14:29:29 -0400
Sounds like your sales manager is looking for a features list that they can
use for sales. And when comparing your product to a competitor. They
might even need it for the RFP (request for proposal) process. It doesn't
hurt to ask why they need the information, as it will help you figure out
what format to deliver it.
What they're asking for is more marketing collateral than product
documentation. Product Management should also be able to help write this
up.
On Thu, May 23, 2019 at 1:11 PM Joe Weinmunson <litlfrog -at- gmail -dot- com> wrote:
> Hi all,
>
> Our company is growing and we have a few people doing documentation now.
> However, all of us are some combination of 1) young, 2) self-taught, and/or
> 3) not experienced in a big corporate environment. That's causing some
> delay right now because we are not sure how to interpret the Sales
> Manager's request.
>
> "the knowledge lies with you [tech support, training, and documentation].
> Our issue is that only a couple of people here at the company actually know
> what these products do. Mae laid out some groundwork, but pulled much of
> the info from the existing website. What we need is a basic list of what
> these products do. What they can do. I understand this is a big task. this
> will end up being a living document as the program changes. Certainly
> changes have been made since the site was built and will continue to be
> made. So what we need is a list of what each product does."
>
> I am trying to figure out whether to format this as some sort of internal
> white paper, as fact sheets for each module of the software, or as
> something else. I know we'll get there eventually, but I'd appreciate any
> advice folks have in dealing with the request.
>
> --
> Joe Weinmunson
>
> âWhat you read when you donât have to determines what you will be when you
> canât help it.â
> --Oscar Wilde
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Visit TechWhirl for the latest on content technology, content strategy and
> content development | https://techwhirl.com
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> You are currently subscribed to TECHWR-L as jstickler -at- gmail -dot- com -dot-
>
> To unsubscribe send a blank email to
> techwr-l-leave -at- lists -dot- techwr-l -dot- com
>
>
> Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit
>http://www.techwhirl.com/email-discussion-groups/ for more resources and
> info.
>
> Looking for articles on Technical Communications? Head over to our online
> magazine at http://techwhirl.com
>
> Looking for the archived Techwr-l email discussions? Search our public
> email archives @ http://techwr-l.com/archives
>
--
Julie Stickler
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Visit TechWhirl for the latest on content technology, content strategy and content development | https://techwhirl.com