Boxes And Arrows : The Design Behind the Design

I was a product manager at Adero and then Inktomi. Requirements were generally written in a Word document which got bigger and bigger and increasingly more impossible to manage. Worse was communicating small changes which occurred frequently. Now I am at Traction where the process is a world apart. We do this interactively with 1000s of requirements pages that are individually marked with release milestones and can be reallocated with a button click. And documentation representing a snapshot in time (if required) can be produced instantly. This wiki style approach is a totally different model than folks are used to, but it is, without doubt, the future approach. For additional context, Read this bit on Wiki vs. Blog and this bit on compound documents.

I think this is a great idea for an article. One thing is that the three points you’ve mentioned above seeme to be focused ont the process or writing documentation, not the *importance* of writing documentation, which is what you’re suggesting (at least by my reading of it.)

Were you going to look at it from the perspective of users?

Sorry for the late reply.
Yes, I have often worked with technical writers who, when asked why their manuals are not easy to use, they reply: “Come on, nobody reads the technical documentation”. I don’t have all the information to write such an article, but I am really interested to read an article on how important is the software documentation from the user’s perspective. What do they tend to read? How are they searching the information they need in a documentation? What makes a usable documentation?

I like the idea of selling documentation to product management, other managers, etc. and relating it to people who read this site. However, there are already a lot of articles on how to create good documentation.