Over the years, I’ve read A LOT of product documentation and technical material - it’s part of working in IT. Much of it is OK, some is great, and lot of it is a convoluted mess of technical verbiage, broken links, shallow information and confusing hyperlinking. (We’ve all been there…right?)

Don’t get me started on open-source stuff, or beta MS doco :-)

As a vendor developing and supporting our service management product, HelpMaster, product documentation has always been a part of the process.

Documentation IS the product

Like the product itself, the documentation is under constant development. There is always things to update, “bugs” to fix, updating screen-shots and technical diagrams, optimizing content, fixing links and so much more. In fact, we spend almost as much time on our documentation as we do building the software itself. Creating and curating topics for new and experienced users, configuration guides, step-by-step tutorials take a lot of time, especially when they contain hand-made conceptual diagrams, screenshots and real-world examples.

Documentation built-in to the process

Our workflow for software development bug fixes and feature requests literally contains a whole section devoted to documentation. Our in-house development process won’t let us release software unless the documentation has been completed.

It’s a lot of work, but PRD Software appreciates that strong product documentation isn’t just an extra resource - it’s part of the product itself! Quite literally, we embed hyperlinks and other tags inside the software to point to the relevant documentation page/resource. Our software build process also builds our documentation, and all of it is source-controlled.

I’m proud that our documentation is written by the same team that designs and develops the system. The people explaining the system are the same people who either built it, or work with the people that built it, or support it. That means fewer assumptions, fewer gaps, and clearer answers when things get complex. Nothing has ever been outsourced.

Documentation and the support loop

Our internal support processes and workflow also devote a process to ensuring that relevant documentation is either updated, referenced, or retired as support operations require. As such, product documentation plays a key role in the support operations for the very product that it is written for.

If a support request comes in for a “How do I do this?”….or “Can HelpMaster do that?”, if the relevant documentation page doesn’t exist, is not easily understood, out-dated, or in any other way inadequate, this will trigger an whole new process and ticket that ensures that this is corrected. Technical and sales support is intrinsically connected to product documentation.

Artificial Intelligence and the bots

We recently used an AI bot to serve visitors to the website. Guess what we trained it on? We let it read our docs. Everything is there! Tech specs, how-to-guides, troubleshooting, configuration ideas, contact details and much more.

Good documentation serves the whole business.

Good documentation = Good Product?

You can tell a lot about a software product by reading its documentation.

If the guides are vague, shallow, or clearly written by someone far from the code, it usually shows elsewhere too.

For ITSM software especially, clarity matters. These systems sit at the centre of service delivery. If the documentation is solid, implementation is smoother, training is faster, and long-term ownership is stronger.

As I finish my work week, I pay tribute to the never-finished HelpMaster documentation.

https://docs.helpmasterpro.com/

#ITSM #Helpdesk #ServiceManagement #SoftwareDevelopment #Documentation #TechnicalWriting #docsy