Let's have a closer look at a typical product development meeting day. The team assessing the project requirements decided that is time to start documenting the product final specs, user, maintenance guides and future training materials.
At this point, the project manager is showing the product development project schedule (presentation display), while someone is considering the budget (the long scroll on the table). Feed up on time and budget constrains someone spills the coffee over the table.
Some questions are on the table:
- What's the purpose of documenting the product?
- Who is the best person to do it?
- The documentation role requires some special skills or any one on the team is able to do it efficiently?
- What's the catch?
- Supporting evidence
The project manager (PM) may argues: What resource we need? Is a software/hardware engineer able to do it? Or is a Businesses Analyst able to do it?
What's the purpose of documenting the product?
The PM, thinking about the answer, says: in my point of view, the main purpose of documenting the product is to improve its usability.
Who is the best person to do it?
So who have the expertise to covey the product specs and functionality to the end-user? Are the engineers or BAs, even though that may be able to save some spare time to do it, experienced enough in this sort of things?
Requires that role some special skills or any one on the team is able to do it efficiently?
Do the engineers or BAs know the tools and expertise to deliver a professional and well structured documentation to our end-user helping to sell our products? Or do we require someone with that particular expertise, a Technical Writer, perhaps?
Some of the team members rise their voices arguing:
- But how someone hired outside of our team would be able to understand the product we built?
- How can such person can learn the intrinsic complexity of our system and describes it to others?
- Do such person need to learn what we already know?
What's the catch?
The PM finally concludes: do we know the professional attributes and required qualifications and skills from a Technical Writer? Considering our requirements, If we decide to hire one, let's put on the table what we considering the most important attributes, or a professional able to:
- Quickly learn new systems detecting its bottlenecks suggesting workarounds or improvements.
- Interact with SMEs and stakeholders learning the product features and user and maintenance workflows.
- Organise the gained information and the experience with the product creating content easy to understand according to the product target audience.
- Structure that content using professional tools to deliver that user/technical documentation on a variety of devices.
So the catch is: even though we know our product better, we need someone with the expertise to deliver its features and functionality from the user point of view, not from our development point of view. Users need to know how to use our product and not what make it thick. Our users need to have a documentation written not for engineers or BAs but for them. That's the major selling point for us.
Supporting evidence
Supporting the conclusion above is my experience with more than 10 years working as a Technical Writer/ Documentation Specialist in a wide range of industries and organisations, dealing with different software and hardware systems, producing quality Technical and User documentation from specs, release notes, user guides, configuration guides, maintenance guides, quick reference sheets and guides, online and web help systems. I am what's can be called an expert on demand adapting and learning new systems on demand and using my experience to decode new systems translating technical jargon and complex processes and procedures into a friendly, concise and precise manner. Producing a product documentation that can really assist your client when they are most in need.
