Your publishing model is broken

When do you publish (release) documentation? Inline with the latest version of your product I’d expect as that’s the traditional model and, and believe me I hate to be the one to break this to you, that’s no longer acceptable.

Please don’t shoot the messenger, it’s not my fault, if you are going to blame anyone, blame Google. Or perhaps Tim Berners-Lee.

Now, to say that the traditional “publish alongwith product versions” model is broken is a bit of a sweeping statement and of course it still has a place, will be and should be followed but have you ever taken a close look at the information you provide? Is it ALL based only on new features?

Maybe it’s just me (hey, it frequently is) but a lot of the information produced is sensitive to version not time, and as such can be published as and when it becomes available providing it has appropriate meta tags. Why do we wait until a product release is due to publish non-version specific information?

Of course there are a multitude of reasons why this may not be valid for you, but having looked long and hard at the information my team produce, I’m increasingly finding that a lot of it can be published instantly and, given that most computer/internet literate people are used to demanding information immediately (thanks Google!) then this at least goes partway to meeting that need. We are lucky in that we have control over where and how our information is published, and we’re slowly moving away from a document and release centric system to a more dynamic and immediate method.

After all, if our customers want information, and our job is to provide them with information, why are we waiting?

5 comments

  1. Completely agree! I feel the technical content process needs to have shorter turnaround time. This seems to be a very valid approach – to publish as soon as the feature is ready, rather than wait till a mainline release.

  2. Sita – I think you need to be careful here. You say “as soon as the feature is ready”, which implies both a software and documentation release which, if your company can manage that, is perfectly acceptable.

    But I am not advocating that feature specific documentation is shipped before the feature itself. Rather that any information that is not reliant on new features, can be published at any point. Apologies if I didn’t make that clear enough.

  3. I agree–I don’t like having to wait for production launches for updated documentation to go out. With the model I’m working in, it’s easy because it gets rolled out with the production build, but that also limits how often I can release the information. I’m pretty much at the mercy of the release schedule. I’ve started working on ways to change that, but I need a solution before I go to project management and customers and point out the problem.

  4. Sure, Gordon, it was clear when i said “as soon as the feature is ready”. This means, one would need to ensure that the software release for the feature is done.
    Thanks for clarifying.

  5. Pingback: WriterRiver.com

Comments are closed.