top of page

My Portfolio / DocumentationData 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).



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 synchronization. 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.







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.

  • Explored internal documentation in Confluence to gather additional information and context.

  • Sought walkthroughs of feature designs and provided feedback directly in Figma files.

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.



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.

Screenshot 2024-04-21 at 12.30.03.png

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 and how it worked with GCS, including a diagram.

  • An article that described the files exported as part of the Data Sync process and the values they included.

  • An article that summarised the export handling process for Data Sync.

We wanted to maximise smooth adoption of Pendo Data Sync, keeping in mind that the documentation was a part of the product and central to its success. Data Sync has since met and exceeded ARR targets in the first year or general availability. The documentation also served as a valuable resource for internal teams, ensuring consistency in customer interactions and support. 

Senior Product Manager

“Regardless of what product she's writing about or engineers she's working with, Jeunese creates great documentation - verified to be excellent by specific customer feedback, including another recent piece of praise from a Data Sync prospect. Third-party integrations and data pipelines are challenging product areas to document, but the confidence I have in our process for publishing and iterating upon our docs gives me great confidence in the product."

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.

bottom of page