I led an initiative to build an internal wiki for product documentation using Confluence. This story highlights my leadership and expertise in content strategy.
Problem Addressed
Operations teams were growing increasingly frustrated with the lack of information available around new features. When the pandemic forced us all into a remote work environment, their frustration grew further.
They frequently turned to product managers for help. But without formal documentation, the knowledge shared was often lost in emails and chat histories. In addition, product managers themselves were spending more and more time answering questions rather than planning and researching new features.
As a team-of-one tech writer, I had focused only on external documentation up to that point due to a lack of resources. But that only provided a basic level of detail. Teams like Tech Support and Client Success needed much more to support clients.
Further, I discovered that different operations teams had created their own knowledge silos to serve their needs. However, these silos often had outdated, conflicting, or incomplete information. This caused even more confusion.
Initial Solution and Challenges
I saw an opportunity to create robust internal documentation. The goal was to establish a reliable source of truth for the first time, directly from the Product Management team, that served the needs of operations teams downstream. This would help operations directly by reducing their confusion. This would also help product managers by reducing their time spent fielding questions.
Despite my good intentions, the wiki did not succeed at first. One issue was my approach. I approached the wiki the same way I approached other documentation. I mostly worked on my own, bringing others in only as SMEs and reviewers.
While this approach can see individual documents to completion, it didn’t work for a project as large as a wiki. I found adoption of the wiki to be a challenge. Very few people knew about the wiki. Even fewer trusted it more than the knowledge silo they already used. I had just created another knowledge silo.
Solution Implemented
Ultimately, the solution was not just the internal wiki. It was also the mechanisms for collaboration around the wiki.
The wiki started gaining traction when I started collaborating with other teams more formally. I enlisted the help of product managers to contribute to articles about their features. I also started meeting with various operations teams on a monthly basis to discuss their documentation needs. This consistent communication and collaboration fostered trust in the internal wiki, promoting wider adoption.
Results
The Product-led wiki reduced confusion internally, leading to smoother feature releases. The Client Success team retired their own wiki altogether in favor of the Product-led wiki. The Tech Support and Sales Education teams audited their materials using the Product wiki.
About The Sample
The linked sample showcases this wiki, using a modified version of a page template from the wiki. I have included details of a dashcam product’s ability to detect tailgating on the road. This is a fictional feature based on a real feature I documented, though many details have been changed for this sample.