My Portfolio / Documentation / Data Sync
Developing documentation for a new product
Aim: Create documentation to facilitate onboarding and minimise the need for direct assistance as customers navigate through a technical setup process for a new product: Pendo Data Sync (2023).
Problem
Pendo Data Sync was a new offering designed to streamline the integration process between Pendo and various Business Intelligence (BI) tools. It eliminated the need for separate integrations with each BI tool, providing a unified solution for data synchronisation. I was assigned as the dedicated technical writer for this offering, which was an opportunity to build documentation for a product from the ground up.
Documentation was a central part of the product experience for Data Sync. Most products should allow the user to self-serve through the UI, using documentation as fallback guidance when they encounter a problem, have a question, or need clarification. In contrast, onboarding and setup for Data Sync was multi-platform and, as with installation and configuration, relied heavily on documentation relative to standard Pendo products.
Process
1
2
3
4
5
Scope and plan
Content creation
Review and revise
Publish and close
Maintain and update
1. Scope and plan
I met with the Program Manager (PgM) and Product Manager (PM) to understand needs. I also:
-
Requested recorded demos of the setup to understand the workflow.
-
Explore internal documentation in Confluence to gather additional information and context.
-
Sought walkthroughs of feature designs and provided feedback directly in Figma.
2. Content creation
I created referential, informational, and instructional content in separate articles for the initial version of Data Sync. This was initially focussed on using Google Cloud as the cloud storage destination for Data Sync, which was eventually expanded to other popular services. Content creation included diagrams, tables, code blocks, and annotated screenshots, edited in line with Pendo style guidelines.
3. Review and publish
I solicited feedback from multiple stakeholders to ensure the documentation effectively addressed user needs. I collaborated with the Data Sync team to draft documentation using Google Docs and then moved these to Zendesk for internal review of final drafts.
4. Publish content and close ticket
As standard, content creation work was captured in documentation Jira tickets and attached to engineering tickets. Tickets for new articles need to be moved to Localisation in Jira before they can be marked as Done. Because localisation of new articles requires planning, I also contacted the Localisation Manager directly to give her a heads-up and a link to each article in Zendesk as soon as possible. The Localistion Manager then closed each ticket when that work was done.
5. Maintain and update
As the technical writer assigned to Data Sync, I attended weekly go-to-market (GTM) syncs, where the team aligned on important tasks for Data Sync updates and releases. This included myself and team members from Marketing, Sales, Customer Support, and Product to co-ordinate launch timelines and foster cross-functional collaboration. Here, we synchronised on the activities, messaging, and resources for launching and promoting Data Sync. Eventually, the PM also started to create tickets on my behalf, but these were also always discussed in GTM meetings.
Outcomes
The initial focus was on integrating with Google Cloud Storage (GCS), which later expanded to include Amazon S3 and Microsoft Azure Storage.
For the initial Data Sync with GCS offering, I started with the instructional content needed for setting up Data Sync, targeted at customers engaged in the Beta version of Data Sync.
Setup involved bouncing between Google Cloud and Pendo, and so it was important to break up the steps and summarise the expected order of activities. I walked the reader through each high-level step with procedural instructions.
I aimed to ensure that the reader wouldn't need to rely on best guesses or presumed knowledge. Meanwhile, readers who were more familiar with various processes could skim through the instructions based on the high-level steps outlined in the main headings.
Following the initial instructional content, I then set out to work with the PM to write the following:
-
An overview article for Data Sync, including a diagram.
-
An article that summarised the export handling process.
-
An article that described the files exported as part of the Data Sync process and the values they included.
The documentation was a part of the Data Sync product, being necessary for smooth setup and adoption, and thus central to its success. Data Sync has since met and exceeded ARR targets in the first year of general availability. The documentation also served as a valuable resource for internal teams, ensuring consistency in customer interactions and support.
Challenges and learnings
This wasn't something I could explore for myself in a dev or demo environment. I relied on my colleagues to keep me informed, share designs, show me how things worked, and answer questions. The Integrations team and the Product Manager especially was always very responsive, and gave me everything I needed to write good documentation. The processes in place with this team gave me appreciation for GTM meetings and I bring this with me to other teams and projects.