What it is
Product documentation includes any intentionally produced information used to build, maintain, improve, or use a product. It includes things like:
UI wireframes (Figma, XD)
Project tasks (Jira, Asana)
Product tasks (Aha!, ProductBoard)
Information architecture (Figma, Miro, Visio)
Code (GitHub)
Knowledgebase (Confluence, FreshDesk)
Meta-documentation (XenBuild)
Together, these systems create a picture of your product, without which you cannot know the product. They are like the blueprint of a house or the CAD file for a car. Modern products are too complex to be understood without documentation. The time it would take to discover all functionality or issues through pure exploration means that there are going to be serious knowledge gaps in your organization.
And chances are, your organization probably has documentation problems. Ask yourself this: could I learn about any aspect of our product without having to ask someone? No? Then you have documentation problems. But you are in good company. Product documentation is a shared Achilles heel of most tech companies. Whether it is incomplete or out of date, documentation is bad all over.
Why you want it
Documentation prevents siloing
Without a common source of knowledge, organizational knowledge is concentrated in the heads of subject matter experts, which leads to siloing.
Documentation keeps knowledge in your organization
When subject matter experts leave your organization, they take their knowledge with them. If you have not recorded their knowledge in documentation, that knowledge is lost to you.
Documentation enables better decisions
Decision makers at the highest level of the company are often not familiar with the product about which they are making important strategic decisions. Good product documentation increases the likelihood that executives will make time to keep up on the reality of the product and make informed decisions.
No documentation leads to bad products
Poor documentation leads to feature bloat, inconsistent user experience, bugs, and a lack of product-market fit.
Documentation eliminates ambiguity
In software production, ambiguity is the enemy. Vague specs that are open to interpretation lead to bad results when developers misinterpret those specs, which happens all the time. This is doubly a problem with offshore developers.
What I do
I ensure that your product documentation is:
Complete: All functionality, all data, all bugs, all aspects of your product are recorded in the appropriate format.
Accurate: All documentation is a true representation of the reality of your product.
Current: Documentation is consistently updated so that changes to the product, or new information about the product, are entered into the document as quickly as possible.
Universal: There is a single source of truth for your company, and that any two people will have access to the same information with no siloing.
Usable: The presentation of the documentation, including the choice of software systems to present the documentation, is easily understood by all team members, and just as easily edited.
A documentation project may consist of:
New data type: The addition of a new type of information (e.g. rendering your product in Figma)
New format: The replacement of one documentation format for another (e.g. replacing Jira with Monday)
New content: Filling in gaps in documentation (e.g. adding missing Figma screens)
Restructuring & cleanup: Improving the organization or metadata around documentation (e.g. creating and applying new tags in Jira)
Consolidation: Migrating information from multiple platforms to a single unified platform (e.g. transferring Sketch and XD files into the existing Figma space)
I also use my proprietary product, XenBuild, to create a unified vision of your product, tying together all other documentation and giving you a view of your product that you've never seen before. Ask me about it.
How to get started
If you are considering a documentation project, book a call with me, and we can discuss your unique needs. Keep in mind that documentation does not have to be an all-or-nothing proposition. It can happen one step at a time, as your resources allow. Don't be daunted by the size of the project, because I will help you decide where to start.