In my current role I was recently given the assignment of improving the visibility internal stakeholders had into Product Management and Engineering. After a thorough assessment, we decided to onboard Confluence from Atlassian to accomplish the goals we had set. This article is not meant to rehash best-practices related to communicating with internal stakeholders — I want to discuss some of the challenges we have experienced as the application has gained traction and the amount of information in Confluence has proliferated. While this continues to be a work in progress, I want to also explain some of the solutions that have been implemented. In another article I will explain the architecture that we have implemented to manage the spaces of multiple development, Product Management, and operations teams.
- Product spaces took on a life of their own — When we decided to use Confluence as a repository for product related information, roadmaps, and tribal knowledge, we had to create a standardized architecture for the spaces to use. We have 10+ development teams, many of which manage more than one product. If we were to allow the development teams to create a distinct architecture for their spaces, the operations departments would have to spend significant time learning how to locate the information they seek in each space. Creating a common architecture has decreased the amount of time that has been required to onboard the Sales, Support, and Operations departments. The outcome has been that the information we are publishing on Confluence is discoverable and accessible.
- People started to complain of information overload — This one made me laugh a little. Before we launched this initiative, the Sales, Support, and Operations departments yearned for improved visibility into completed and planned work in Engineering and Product Management. While onboarding Confluence was only a component of our efforts to improve transparency, it was one of the core tenets. One of my goals was to have Product Management utilize Confluence and their product spaces as a single communications channel for their product with internal stakeholders. The Documentation team now uses Confluence to publish all customer facing documentation — release notes, set-up guides, API documents, and others. With all this information, it can be difficult to navigate and find information that you want. Requiring a common architecture for each product space has helped stakeholders locate the information they need, but what has really come to the rescue has been the search feature in Confluence itself. It has taken time to educate Product Management on how to make sure their content is discoverable. Atlassian has done a great job with the search feature, making the use and results UI familiar to users — it reminds me of Google search results.
- The amount of information put into Confluence differed by team — Before we launched and took Confluence live, we knew that the amount of information that would be published by Product Managers would vary. However, we needed consistency in this area to assure that Confluence had value to internal stakeholders. I manage the Scrummasters in our company, which provided me with the ability to drive the addition of content through a team that I manage. I set priorities and then had the Scrummasters work with Product Managers to get content that I wanted added along the timeline I had set. This is still a work in progress, but we have achieved a level of consistency that I am proud of.
Confluence is tool that can help improve communication between Product Management and the rest of the company, but the benefit is only realized when the right information is published to the right audience at the right time. These are three of the issues that we faced as we launched Confluence as a company and the solutions that we came up.
Do you face the same issues? Have you driven the solutions from a different direction? Leave me a comment so we can start the discussion…