We sat down with Jeffrey Aftel, Director of Product Writing at Gong, to discuss his approach to rebuilding legacy software documentation, his principles for impactful content, and the traits he looks for in technical writers. Jeff's background also includes technical writing leadership roles at HP and Velo by Wix.

I was brought on to build out a documentation team at Gong because the sole technical writer at the time was stretched impossibly thin. She was managing over 500 legacy help center articles while trying to keep up with supporting new features.

When you inherit hundreds of articles in various states of quality, imposing a top-down strategy like “here's the new standard, rewrite everything” isn't practical. While I certainly have mantras for what great documentation should look like, I didn't have the resources to start from scratch. Bulldozing existing work would have been highly counterproductive.

You also can't impose blanket principles of what good looks like because ‘good' differs heavily depending on the context. For example, configuration guides, analytics reporting, and experimental feature overviews all have different audience goals and require different approaches.

Rather than a one-size-fits-all strategy, we took an incremental, bottoms-up approach to refresh Gong's software documentation. Focusing on one section of articles at a time, we identified specific gaps—whether in structure, clarity, or content—made improvements, and established principles that can be applied to similar sections.

This chunk-by-chunk let us make steady, meaningful improvements that we could apply to other sections as needed, helping us scale without forcing a one-size-fits-all solution.

1. Documentation is part of the product.

Prioritize and treat it accordingly.

2. Documentation should add real value.

Nobody needs "duh" documentation, like telling users to "Click Save to save". While users often look for basic procedures on how to navigate the UI, it's critical to take the view that that is just the beginning and to ensure that your content goes beyond the basics. Documentation should focus on adding value to set your user experience apart.Make their lives easier by highlighting use cases, offering additional considerations, and sharing best practices. If users' goals touch on other product areas, help them see the bigger picture and point them to related concepts that'll support them. Focusing on value-add sets your documentation apart in up-leveling the user experience.

3. The first two sentences of a help center article are everything.

Your intro sets the tone and hooks the reader. You need to immediately either acknowledge the reader's pain point and show how you'll solve it, or spark an "aha moment" where they think, "Wow, I didn't know I could do that!"Your goal is to create an environment where the reader feels compelled to learn more. This is especially critical for experimental features that might be unfamiliar to your reader. Captivating them upfront helps them to discover more of what your product offers.

‍Writing well is only the baseline. Tests can help evaluate sentence structure and word choice, but I always like to apply this principle: it should read as though it was effortless to write. Whether it actually was effortless doesn't matter—what counts is that the reading experience feels completely natural.

Beyond concrete ability, the best technical writers don't just complete tasks they're given; they ask questions, challenge assumptions, and look for better solutions.

For example, I gave candidates a test where they had to write copy for a checkbox. One standout candidate didn't just provide wording—she questioned if the checkbox should exist at all. She suggested replacing it with a button to make the behavior more intuitive and in line with the previous steps. That kind of thinking went beyond the task and showed a deep understanding of the user experience.

This curiosity is what separates good writers from great ones. When writing anything, they should ask, “Where is the user in this flow? Is this the right approach? How does it fit into the bigger picture?”

I expect my team to know the product extremely well because their job goes beyond content—it's about solving problems and advocating for the user.

‍We follow a pod model where each pod has engineering, product, design, and technical writing. The technical writer of a pod is expected to be a subject matter expert of their area. Whatever happens in product, technical writing is in the loop.

This level of context is necessary because I expect my team to have deep knowledge of the area that they own. In order to create the value-add documentation that I mentioned earlier, my team can't be relying exclusively on extrapolations from a PM or engineer—they need firsthand knowledge.

When technical writing is embedded in development, it improves the entire flow and end result for users—documentation is part of product, after all.

‍

Thanks for reading this Fireside Chat. If you have different perspectives and would like to be featured, or you just want to chat with our team, get in touch at [email protected].