Strategy implications from the Nurnberg funnel

I am still thinking through the implication of Minimalism Beyond the Nurnberg Funnel. One of these ideas concerns the benefits to the software producer of supplying minimalist documentation. One of these is the idea of documentation as a product strategy. This is covered by Karl L. Smart in an essay in the book.

Software companies all too often view the production of documentation as a cost, not an opportunity. Documentation is seen as a necessary evil since supplying software without documentation is not acceptable but writing it will push up costs. So companies produce documentation but try to limit the costs and miss the opportunity.

In my experience this usually means that too few technical authors are employed, those that are over worked and their activity is something of an after thought. They are not integrated into the software development regime; they get the product late and are expected to document everything they can. To cap it all technical authors are often among the first to be laid off when a company needs to make redundancies.

(Of course they assume that the role of technical author is even recognised, many producers do not see technical author as a role in its own right. Such companies make developers, managers and particularly testers write documentation in addition to their main job.)

Overall technical documentation is a lose-lose. Companies don’t see the benefits of providing it, users demand it but do not have high expectations and when they do turn to the documentation it is pretty useless.

I have seen a variation on this theme a couple of times, this is the highly complicated product. There is no way the user can learn the product from the documentation so they need training courses. Training courses can be a nice revenue earner for the supplier but they don’t normally don’t manage training very well so don’t make money from it. To the buyer training is yet another hidden cost. To the user there is not enough training, it is not good enough and it is another cost that can’t get signed off. Meanwhile the software continues to get complicated and everyone hopes the training and documentation will act as a sticking plaster.

Smart argues that providing quality documentation is actually a win-win for supplier and customer. Minimalism provides the road to useful quality documentation which benefits the product in a number of ways:

• Good documentation differentiates the product from its competitors


• Good documentation is more useful to users who in turn use the product more – and exercise the features - so they extract more value from the product so they are more likely to buy more product.


• Good documentation means users are more likely to solve their own problems than call the technical support line. Therefore the supplier can save money on technical support.


• Not only the supplier saves on tech support but so does the customer. Research shows that for every $1 of direct technical support costs a user needs they use $3 of informal support when they ask colleagues to help them.


• Minimalist manuals are usually shorter than traditional one so they are cheaper to manufacture. Although now documentation is usually supplied in electronic format this argument is reduced.

Producing minimalist documentation might cost more because it requires more time and analysis from writers but this is offset against savings suppliers can increase profits by producing minimalist documentation. (A word of warning: minimalist documentation does not mean producing less of the same documentation, there is more to minimalism in documentation than simply doing less. It means doing things differently.)

Because better documentation makes the product a better product it enhances the sale-ability of the product and therefore improving documentation is a strategic move on the part of the supplier.

This also means that documentation should be an issue for product managers. In addition to specifying features and requirements of the software product managers need to RTFM and find a way of improving the manuals.