Creating a documentation strategy for a new product in 2024

A documentation strategy is a plan to develop, publish, and maintain documentation that supports a product, technology, or concept. But how do you build a documentation strategy in 2024?

As the business world grows increasingly international and competitive, it is crucial to adapt documentation strategies accordingly. The following is intended to guide you in the process of building a modern documentation strategy that will give the best chance of success to the documentation, the team, and the project it supports.

This guide is broad enough to apply to almost any industry, but do keep in mind that some steps may not be necessary in your particular area.

When thinking about your documentation strategy, the first step is determining what documentation is actually necessary. These questions will help you get started:

1. Is this a new technology, and will customers need proof of validity?

An innovative product is exciting; but as it takes time for users to write their personal reviews, trust in the product needs to come from trustworthy impartial sources with brand recognition. These include (but are not limited to) industry analysts, thought leadership whitepapers, scientific articles, and research documentation.

2. Will this product be manufactured, and have components that are replaceable or upgradable?

If the product will be manufactured, build procedures must be developed. In addition, documentation detailing how to check the quality of the finished product must also be supplied to the manufacturer – even if the product is being manufactured in-house.

If the product has any parts that will be replaceable or upgradable, a parts manual or catalog will need to be developed. A successful catalog will allow a customer to identify the component that needs replacing and how to order that component.

3. Will this product be installed?

Some manufactured products will be installed by the organization or third-party installers. They will need installation instructions. For example, industrial air conditioning might be manufactured and installed by a company and its subsidiaries.

Software may have separate installation instructions too, for example, if something needs to be installed on a server as well as locally.

4. Identify your users and their needs.What resources will they all need?

You need to know who the users are for each type of documentation you are going to create (in-house staff, third-party manufacturers, customers, installers, etc). For example, without detailed and accessible internal documentation, customer support will need to lean on the direct support of the development team. What does your team need to know to help your customers? What documentation will be accessible to the customers, and internal-facing only? Document it!

5. Is this project similar to previous projects? Use your experience!

What documentation was most referenced for previous projects? What written knowledge seems to be missing? For example:

• Were there any consistent problems in manufacturing? This would indicate that the manufacturing documentation is not up to standard.
• Did customer support need frequent help? Use your experience to dictate what information should be documented this time around.
• Were there repeated problems during installation? If the documentation is lacking, installers may continue to make the same mistakes, which could be costly.

6. What format will the documentation take?

Is it going to be delivered as online help, printed manuals, videos, etc. What is the optimal choice for the end-users and are there any time-related elements to take into account when making this decision? Videos can take longer to make, edit, and update for example.

When the documentation requirements have been identified, it is time to begin planning and development.

This step revolves around the strategy to develop and write the documentation. Consider these questions:

1. How will each document relate to the project it supports?

No document stands alone in any project because all of the documentation relates back to the product. For example, the internal documentation used by the customer support team to the external documentation used by the customer. It is important to deliberately strategize these relationships, and how each document relates back to the project.

2. What will marketing own?

Marketing is the decision-maker in many customer relations issues, and therefore has a say in customer-facing documentation. They will also be responsible for the overall brand voice and tone of the content. It is therefore important to identify which documentation marketing will need to clear before it is published.

3. Who will own which documents?

It is important to define who will take ownership of each subject, and to then assign specific writers and reviewers. The goal is to not only get the writing completed, but to also ensure accuracy. Reviewers are a vital step in quality control. They can spot inaccuracies, confusing information and inconsistencies in your content, before it is published.

4. Resources and priorities.

An organization may recognize the necessity for a considerable amount of documentation. But they don’t have the resources to deliver all of it within the timeframe. So they would need to consider bringing in extra staff/consultants or prioritizing some projects over others. For example, if your manufacturing staff are well-trained and know what they are doing, you might make installation documentation a higher priority.

Even with end-user documentation, you might need to prioritize certain parts, and have updates scheduled for later.

5. Deadlines, deadlines, deadlines.

Each part of the project should have specific, agreed-upon deadlines assigned. Deadlines should be set for writing, reviewing, iterations, and final documentation submissions.

The documentation is written, reviewed, and finalized. But the documentation strategy is not done yet!

Proper documentation can greatly simplify processes. But what good is the documentation if no one ever uses it? That is why a publication plan is so important. When developing a publication plan, it is important to strategize the where, who, and when:

1. Where will the documentation be published?

How will the documentation be provided to the audience and how will you manage version control? For example: manufacturing. How will the manufacturer receive build procedures and quality control references, and how will you prevent version control issues? Will the customer-facing documentation be stored in a customer support library on the company’s website, or will the documentation be printed and shipped with the product? Keep version control in mind when planning publication.

2. Who will publish?

Every organization will have a different process when it comes to publishing, and as the documentation expert, you must familiarize yourself with and adapt to these steps. Determine who specifically will be responsible for uploading the documentation or shipping it to the appropriate parties. It is also recommended that you double-check with each person in the process so that they are aware of the part they need to play. For example, if marketing is to be the final hand on any outgoing documentation, they must take ownership of those documents to ensure consistent messaging.

3. When will the documentation be published?

It is important to set product-centric deadlines for when each document will be published. Uninformed customers lead to frustrated customers. Delivering content on time means your customers have access to the information they need, when they need it. That enhances the customer experience and should reduce the demand for customer support.

The documentation is published – that means the documentation strategy is complete, right? Not yet!

Documentation maintenance is necessary to deliver a consistent, high-quality customer experience. It helps to:

• Keep content up-to-date, which is vital if documentation is to meet user needs
• Identify and address issues with quality
• Increase customer satisfaction and reduce demand for customer support

Consider the following:

1. Determine the product’s schedule

If a new version of a product is scheduled to be released, the updated documentation needs to be published by that time too. This also includes any related documentation.

2. Schedule the documentation maintenance to support the product.

The documentation maintenance schedule should be timed so that the work is completed before the product release. Work backwards from the product’s schedule and determine how long each document update and review process will take.

3. Create a system for updating the documentation team.

It is important that the developers can easily inform the documentation team of updates. Aim to create a system where the developers can provide the update information with minimal interruption to their work.

4. Get stakeholders to agree to the maintenance schedule.

The documentation maintenance schedule must be agreed to by all parties, including the writers, the reviewers, and any other stakeholders. Otherwise, the documentation maintenance will always be pushed aside for “more pressing” matters – despite how critical proper documentation is to the project’s success.

Congratulations, you’ve created a documentation strategy! You now have a clear plan to develop, publish, and maintain content. As your strategy is centered on your product, its end users, and your support team, you have the basis for a successful project. 

And if you would like to read more about documentation strategy, read our in-depth article, Documentation Strategy: Empowering Effective Communication

This article was originally published in September 2020. Updated February 2024.