Execute Whole Product Technical Communication

While the concept of whole product technical communication sounds simple, the execution is anything but straightforward. In this post, we are going to look a bit harder at the issue in the hope of coming up with actionable items.

Where are we now – a simplified responsibility matrix#

The less-than-ideal situation in which many technology products find themselves is due to the insufficient coordination between marketing teams and technology teams. With the rise of customer-centric methodology, what had worked before needs adjustment.

The very term “whole product” implies coverage beyond the main phases of the product life cycle. No surprise that “whole product technical communication” is a cross-functional endeavor at the organization level.

Before proposing anything, it’s important to understand where we are now. Below is a highly simplified Responsibility assignment matrix that intends to show the demarcation between departments or teams regarding content creation.

It would be an exaggeration to claim the matrix above applies everywhere. Let’s take it as a sketch of one end of the product technical communication spectrum. Corresponding to the four divisions (marketing, product management, product development, and operation & support), content falls into three categories:

• marketing collateral: by the marketing team
• technical documentation: by the product development team
• knowledge base: usually scattered knowledge created by the operations and support teams for internal usage

Product management mostly focuses on building the product and acts between marketing and product development.

Whole product content composition#

In the customer-centric era, there are two domains that need special attention. One is knowledge base; the other is partner collateral (content used in partner communication).

But why?

Information gathered in the knowledge base and communicated with partners not only sheds light on how the product is doing in the business ecosystem, but more importantly, it can inspire new ideas to build up the product. Such information is of particular importance for the “Augmented Product” and “Potential Product” in the whole product model, and also for post-sales support.

Revised content responsibility matrix#

With the whole product model covered, our content responsibility matrix also needs an upgrade. Below is a speculative matrix. It now has all the four key responsibilities and more deliverables (new entries highlighted).

Note that depending on the adoption stage of the product, which parties need to be consulted or informed may vary. For example, while a partner relationship might not exist for a “true” startup at its early stage, it becomes almost indispensable when the product needs to gain entry into the mainstream market.

Two more things#

Cross-department endeavor often runs into tricky situations even if all parties involved have agreed on a detailed RACI matrix. The good news is that there are strategies and tactics available and free, and it’s not my ambition to go into that area. Here I’m only going to briefly mention two things.

Content management and governance#

UX research and consulting firm NN/g has an article discussing the models of Content Management on Intranets, the idea applies to content for external consumption as well.

Given that different content types cater to different target audiences, have different timelines, and require different output formats, a hybrid model seems to be the most plausible.

The central team or group is in charge of top-level structure and style. A corporate Style Guide with sections for each specific content type could be a promising starting point.

Single sourcing#

For technical documentation teams, single sourcing usually means publishing both webpages and PDFs using the same source files.

I’m not a fan of single-sourcing publishing, but am one of technical documentation as the single source of truth. See Gitlab documentation style guide for a discussion on this topic.

What’s next?#

Ideas evolve, roles evolve, because business and people change, and we need to adapt.😉

On the other hand, it’s always good to think and experiment, to try something different. I’ll come back to this topic when there are new ideas or experiences to share. Meanwhile, comments are welcome!