Differential Content Strategy

By | 2012/10/03

Traditionally, the content strategy for technical communications has tended to be undifferentiated. That is, organizations would define the components of a doc set: user guide, admin guide, quick reference card, reference, etc, and would produce that same set of documents for every product and every product release from 1.0 to the very last release before the product was finally put out to pasture.

This undifferentiated strategy was based on a expectation about the role of documentation in a product — an expectation shared by both customer and vendor. But today, thanks to the Web, expectations have changed, and with frequent releases and squeezed margins, the cost of meeting the old expectation has become increasingly burdensome. As a result, more and more organizations are questioning the value of documentation, and the value of developing it in-house  as opposed to outsourcing or off-shoring it.

A differential content strategy focuses on the places where content can add to shareholder value. Photo: FreeDigitalPhotos.net

We can no longer afford to respond to the market with an undifferentiated content strategy. We need a differential content strategy.

In my TechWhirl article, The Paradox of Tech Comm, I pointed out the paradox that while documentation is a common source of user frustration, it seem to play very little role in shaping user’s buying behavior, at least in the general market.

Ultimately, every business exists to create shareholder value, and if people complain about the docs but buy the product anyway, trying to improve the docs will not add to shareholder value, it will only drive up costs. Many companies today clearly see documentation in this light and seek only to minimize the docs they ship and the amount they spend on them.

The aim of a differential content strategy, therefore, is to figure out how and when documentation expenditures will add shareholder value by either increasing margins, increasing sales, or reducing costs.

Cost reduction is the most perilous of these, for a docs group, because it can easily become a race to the bottom. Arguments based on cost avoidance for other functions, such as tech support, are a little better, since they can be used to justify moving money to tech pubs rather than away from it. In any case, cost reduction and cost avoidance arguments for tech comm abound, and it would serve no purpose to rehash them here. Instead, I want to focus on documentation’s potential contribution to margins and market share.

This is where the differential part of the strategy comes in. The same type of documentation is not going to add to share and/or margins at every moment, with every customer, with every product, or with every company. As Tom Johnson points out, in his blog post Exploring the Tech Comm Paradox,  the presence and promotion of documentation can often suggest that the product is hard to use (because you need docs to use it) which could discourage buyers and therefore hurt share and margins.

The differential, then, is about figuring out when documentation can make a difference in either direction, for good or ill. It is about figuring out when to push docs forward and when to pull them back, when to increase docs expenditure, and when to reduce it. For a docs manager, the demonstrated willingness to make both calculations, and to urge both courses of action at the appropriate time, can do a lot to establish them as someone who is thinking about the company’s business needs as a whole, rather than just buttering their own peas.

Because this is a differential strategy, there are no universals, but there are a number of places where it makes sense to examine the differential value of docs:

  • The place of the product in its product cycle: For a brand new product, where most users are not familiar with the product or how to use it, and there are few experienced users and little public content, documentation may play a key role in helping potential customers grasp what the product is about and understand how it could make a difference in their lives. But as the product matures and becomes easier to use, users become more experienced, and the amount of third party expertise and content grows, documentation may play less and less of a role in encouraging sales, and could tip over into being a disincentive. It might be time to scale back the documentation, or fade it into the background, allowing the ease of use of the interface and the strength of the user community to come to the fore. It may also be time to focus more on support and key product mavens as targets for advanced usage and troubleshooting information. As the product reaches its peak and starts to decline, it may be time to scale back the documentation effort as much as possible to preserve margins through reduced costs.
  • The place of the product in the product category cycle: Just as products have a cycle, so do product categories. If your new product is an entry into an already established market — if you are bringing out yet another tablet computer, for example — then user expectations and expertise for this product category are already established, and trumpeting your comprehensive docs may only suggest your product is not as easy to use as the competition. In this case, you might want to focus your effort on any distinctive features that differentiate your product, and keep general docs to the absolute minimum.
  • User expectations about documentation: There are products for which users expect to have to read documentation, and those for which they do not expect to have to read documentation. If someone does not expect that they should have to read documentation to use a certain product, they are more likely to reject the product if they can’t use it than they are to give in and read the docs. Of course, not everyone will have the same expectations, and some will expect to need help with products because of their lack of confidence in their own ability. But such people may not be confident in their ability to learn from docs either, and not apt to try a product without someone they trust available to help them. Yes, there will be exceptions, but will catering to the exceptions produce enough share or price differential to offset the cost of producing and shipping more or better docs? A differential content strategy can’t take account of every edge case.
  • Business, consumer, hobbyist, regulated: Documentation impact may vary greatly between markets. The consumer market generally isn’t a place where people expect to have to read documentation to use a product. In the business market, on the other hand, documentation can be a significant pre-sales asset, especially in long-cycle, high-value sales situations. The hobbyist market deserves special mention because while it is a consumer market, hobbyists are often voracious readers withing the scope of their hobby, and may be hungry for lavish docs. Regulated industries, of course, often have very specific documentation mandates, but it may be difficult to know if there is any value-add in providing documentation quality or quantity above and beyond the mandated minimum.
  • Discoverability: One of the key aims of UI design is to increase the discoverability of products and interfaces. But not all products have, or can have, a high degree of discoverability. Too often, documentation focuses on precisely those features of the system that the user could discover for themselves, while neglecting those that are not so discoverable. A differential content strategy should focus on providing information on the less discoverable features.
  • Communities and mavens: If your product has a strong user community, that is probably the first place people go when they need help. There may be little point in creating docs to reproduce what the community is already doing. On the other hand, within any community, there are certain individuals — the mavens — who stand out for their knowledge, skill, and dedication to the product. Aiming documentation at the needs of mavens may be the right strategy to strengthen the community, which in turn can be a huge sales asset for the company.
  • Novices, journeymen, and masters: Modern tech comm tends to fixate on the needs of novices. There are many reasons for this, including the history of tech comm in the tech boom, the writer’s classic defense of their function against the idea of letting the engineers write the docs, and the fact that the writer’s training and experience may not equip them well to writer for anyone above novice level. But while novices may be the most in need of help, they may not favor the docs as a source of that help, and they don’t usually do a lot to talk up your product and your brand in the wider market. It is the journeyman users who work with your product day in and day out who may be more likely to go to the docs for more obscure tasks and functions, and the masters who can take your product into new places and new markets. Serving the needs of journeymen and masters may actually do your product more good in the marketplace than catering principally to novices.
  • Market differentiators: In a competitive marketplace, sales and marketing are always looking for the differentiators: the features and capabilities that set your product apart from the competition. Focusing documentation support on the differentiators rather than the common features may do more to support the sales and marketing effort.
  • Pre and post release: Most of the information about a complex product, especially one that operates in a networked environment, is created after the product is released. Traditionally, documentation has stopped at product release (or actually, before it, to allow for printing, binding, and packaging). But there is no reason for doc delivery to end with product release anymore, or for every imaginable doc need to be met before product release. New market opportunities often open up for existing products, and new docs that address those needs can help open up those markets.

I’m sure this list just scratches the surface of the possible elements of a differential content strategy, and I hope you will feel free to contribute others in the comments.

In closing, though, I want to bring this discussion back to the roots of this blog: Every Page is Page One. In executing a differential content strategy, flexibility, and the ability to expand, contract, and refocus the content is key. This is much easier to do with an ordered collection of Every Page is Page One topics than it is with a set of traditional manuals. Every Page is Page One should be a key ingredient in a differential content strategy.

2 thoughts on “Differential Content Strategy

  1. Gordon

    Buttering their own peas.. that’s a new one for me!

    As a Docs Manager, whilst I don’t think I’ve ever rationalised the thinking as you have outlined, I have a simple strategy that is based on business benefit. We simply cannot document everything, so we have to have a way to make decisions. That means understanding costs, cost savings, and sales pressures, as well as how we can operate towards margins and push ourselves into the world of presales.

    Slightly contrary to Tom Johnson, I think talk of documentation in a presales engagement can be a positive thing although it’s likely dependant on the product being discussed. We have a complex product, so good documentation (and our developer community website we run) are a definite aid and resource for our sales team to pitch!

  2. Mark Baker Post author

    Hi Gordon. Thanks for the comment.

    I agree, and I am pretty sure Tom would too, that documentation is sometimes a sales asset. I would say it is an asset any time a user expects they will have to read documentation to use a product.

    The value of Tom’s insight is that it points out that there are many times in which the user thinks that they should not have to read documentation to use a product of a certain type, and that then highlighting the documentation, even if it is the greatest documentation ever penned, will still be detrimental to the sale. That’s not something that every tech writer thinks about.


Leave a Reply