In our previous article on documentation as a growth engine, we saw how great help docs can convert trial users into paying customers. But knowing documentation is crucial begs a practical question: who on your team should actually write these help articles? It’s tempting to simply hand off documentation to a single department (or outsource it to marketing), but that approach often falls flat. The best SaaS documentation is a team effort, combining multiple perspectives. By involving the right roles in the process, you ensure your help center is accurate, user-friendly and truly helpful (instead of vague marketing copy that frustrates readers).
Below we outline four key roles that should collaborate on your SaaS documentation. On a small team, one person might wear multiple hats, and that’s okay. What matters is that these perspectives are represented. If you cover these bases, you’ll avoid the common pitfall of docs that are technically incomplete, confusing to customers or simply not useful. Let’s look at who should be involved:
The Subject Matter Expert (Technical QA or Developer)
Who are they? This is the person with deep knowledge of the feature or product, often the developer who built it or the QA engineer who tested it. They understand the feature inside-out, including edge cases and technical details.
Why their input matters: The SME ensures the documentation is technically accurate and thorough. They know exactly how the feature works (and breaks), so they can document correct steps, expected outcomes and important caveats. In many cases, the person with the deepest insight into a topic should be the one documenting it. For example, if Developer X implements a new feature, part of “Done” should be updating the docs for that feature. No one else can provide the same level of detail and correctness for that part of the product.
What they contribute: Subject matter experts contribute the core content, the step-by-step instructions, the technical explanations, the accurate descriptions of how to configure or use the feature. They make sure nothing important is missing or wrong. As a result, your docs will contain “the complete and accurate information” for that aspect of the product. Skipping SME involvement risks leaving out critical details that only the implementers know.
Caveat: SMEs might not naturally write in a user-friendly way. They may assume too much knowledge or use internal jargon. That’s why we don’t want them working in a silo (and why the next roles are needed). But without the SME, you get shallow documentation. Always have the feature’s expert either draft the doc or closely review it for accuracy. In short: the people directly involved in building a feature must contribute to its documentation.
The Customer Support (or Customer Success) Person
Who are they? This is someone on the front lines with your users, support reps or customer success managers who field questions every day. They know what real users struggle with and which parts of your UI or setup process cause confusion.
Why their input matters: A support professional brings the customer’s perspective. They can ensure your help docs actually answer the questions users ask in the real world. As one documentation expert notes, support team members “know how outside users experience the product”. They are keenly aware of the common pain points, misconceptions and “gotchas” that new customers encounter. By involving support in documentation, you make your help content practical and relevant, addressing the issues that would otherwise become support tickets.
What they contribute: Support folks can suggest topics for FAQs and troubleshooting guides (based on frequent tickets), flag ambiguous instructions and push to explain things in plain, non-jargony language. They help the team avoid the curse of knowledge (“everyone knows that!”) by reminding us what new users actually don’t know. For instance, if customers often ask “What does this setting mean?”, your documentation should proactively answer that. Something a support rep will immediately recognize. This role also ensures the tone is patient and helpful, not terse or overly technical.
Bonus benefit: When support agents contribute to docs, you often reduce future workload for the support team itself. Good documentation deflects basic “how do I…?” questions, because users can self-serve the answers. It’s a win-win: users get instant help and your team spends less time answering repetitive questions. (In fact, one SaaS company saw 12% of all trial sign-ups originate from help pages, showing that users often find answers in docs and then convert on their own.)
In summary, loop in your support team to make documentation customer-centric. They’ll ensure your help center speaks the users’ language and solves the actual problems people have, not just what the developers think people have.
The “Know-Nothing” Newcomer (Fresh Eyes)
Who is this? It’s the person with little to no prior knowledge of the feature, essentially standing in for a brand-new user. This could be a new hire, someone from another department, or even a friendly beta user. The key is that they aren’t immersed in the product’s jargon and assumptions.
Why their input matters: When you’ve been working on a product for months or years, it’s hard to un-see what you know. You might skip steps in the docs because they feel obvious to you, or use terms that seem common (but aren’t to outsiders). A fresh pair of eyes will quickly spot these gaps. They’ll tell you, “I’m stuck at Step 2, what’s an API token and where do I get it?” or “This intro is all buzzwords, I still don’t know what this feature actually does.” In other words, they catch where the documentation isn’t clear for a true beginner.
In fact, insiders often write documentation in their own voice, which can inadvertently feel like marketing speak or assume too much background. A newcomer won’t let you get away with that. If any explanation doesn’t make sense to them, that’s a signal you need to rewrite it more simply or add more context.
What they contribute: Think of the know-nothing role as doing a usability test on your documentation. Have this person follow the doc without insider help. Where they struggle or ask questions, you improve the content. They will point out jargon that needs defining, steps that were glossed over, or instructions that are confusing. Their feedback ensures that even a totally new user can go from zero to hero using your guides. (As a reminder, a great user manual should be able to take someone who knows nothing about your product and enable them to use it independently. Testing your docs on a know-nothing is how you make sure that’s true.)
On small teams, you might recruit a friend outside the company or rotate someone not involved in that feature to serve this role. It’s an invaluable sanity check before publishing a help article. After all, if a novice can’t understand your “How to Get Started” guide, chances are many customers won’t either, and that defeats the whole purpose of your docs.
The Editor (The Polishing Pro)
Who are they? This is the best writer on your team. Whether it’s a professional technical writer, a content marketer with a knack for clarity or just someone with strong communication skills. You need a person who can take the raw contributions from others and turn it into a cohesive, polished piece of documentation. On a larger team, this might be a dedicated tech writer or documentation manager. On a smaller team, it could be a product manager or marketer who happens to write well.
Why their input matters: Even if your SMEs and support folks generate great content, it needs refining to be truly effective. An editor role ensures the final documentation is clear, consistent and easy to follow. For one, they’ll enforce a unified tone and structure. Different contributors have different writing styles. Without editing, your help center could feel patchy or disjointed. A good documentation editor will smooth these out so that the docs read with one coherent voice (fitting your brand and audience).
Critically, this role also ups the quality bar in terms of language and presentation. They make sure terminology is explained (no undefined acronyms!), instructions are in logical order and sentences are concise. As we highlighted previously, clarity is paramount: you want plain language, step-by-step guidance and helpful visuals in your docs. An editor will add those visual aids (screenshots, diagrams) and call-outs where needed, and cut any fluff or overly technical gibberish. The result is documentation that’s not only accurate, but truly user-friendly.
What they contribute: Editors review and revise the documentation draft. They catch grammatical errors and fix awkward phrasing. They ensure formatting is clean (headings, lists, tables of contents, etc., for easy scanning). They might suggest breaking one long article into two, or adding a “Troubleshooting” section based on common questions. Essentially, they are responsible for that final 10% polish that elevates your docs from okay to excellent.
Just as importantly, the editor often acts as the owner or coordinator of the documentation process. In a collaborative effort, someone needs to keep track of which pages need updates, enforce standards and make sure the docs stay up-to-date. It’s wise to designate an “editor-in-chief” of your knowledge base. As one forum of experienced testers concluded, you should have one person who “owns” the documentation to keep it consistent and current (this doesn’t mean they write everything, but they oversee quality control). On a small team, this could be an unofficial role, but do assign it to someone. Without a clear owner, docs tend to fall out of date or vary in quality.
Note: If you don’t have a full-time technical writer, the editing role might fall to a marketing team member, and that’s okay as long as the core content came from the product experts and support. Marketing can help with style and SEO (e.g., ensuring help articles are indexed and maybe subtly optimized for keywords). Just avoid the trap of having marketing create documentation in isolation. As the Mad Devs engineering team warns, documentation spans many departments’ knowledge, and if one person from one department tries to write it alone, it likely “will not include everything you need in a proper form.” Instead, each part should be written by those who know it, and then a skilled writer makes the final docs “comprehensive and easy to use”. In short: collaborate first, polish second.
Putting It All Together (Collaboration is Key)
It should be clear by now that great SaaS documentation is not a one-person show. Each of the roles above brings something essential to the table:
- The Subject Matter Expert provides depth and accuracy.
- The Support/Success team provides empathy and real-world clarity.
- The Newcomer tester ensures it’s approachable for beginners.
- The Editor/Writer turns it into a polished, coherent final product.
On a large team, you might have distinct individuals for each. On a scrappy startup team, one person might wear two or three of these hats. What matters is that you intentionally cover all these bases. Perhaps your QA engineer drafts a how-to article (SME ✅), then a support rep adds a FAQ section and clarifies a few steps (user perspective ✅), a new hire tests it out and asks questions (fresh eyes ✅), and finally your content marketer edits the language and adds screenshots (polish ✅). The end result will be far superior to any single-handed attempt.
This cross-functional approach guards against the weaknesses of a siloed method. Documentation created solely by developers might be accurate but too dense; done only by marketers, it might be pretty but superficial. As a Customer Experience lead at CMSWire puts it, involving support, product, and others in documentation leads to more comprehensive content (it “benefits both customers and internal teams”). It’s truly the sum of parts: when you combine product knowledge with customer insight and writing craft, you get help docs that excel on all fronts.
A note on “outsourcing to marketing”: Our goal here isn’t to pick on marketers (they often produce great educational content), but to emphasize balance. Documentation is fundamentally about helping users succeed with your product, which means it must be deeply informed by the product’s details and the users’ needs. Marketing teams alone might lack one or both of those inputs. By all means, use your best writers (whether they sit in Marketing, Product, or elsewhere) to refine the docs. Just be sure to feed them the raw expertise and customer knowledge first. The documentation process should break down silos, not reinforce them.
Conclusion
If you treat your help documentation as a team project rather than an afterthought, you’ll end up with far more effective results. Remember that documentation is an extension of your product experience and your customer experience. It deserves input from multiple angles. As you plan your next help article or knowledge base update, bring these roles together in a quick collaboration. Even a brief meeting where a developer, a support agent, and a writer hash out a page can make a world of difference in quality.
The investment is worth it. High-quality docs mean fewer confused users, faster onboarding, and ultimately more conversions and retained customers. By having the right people write (and review) your SaaS documentation, you ensure that customers not only find answers, but also gain confidence that your product will meet their needs. And that confidence is what turns trial users into long-term, happy customers. Don’t leave that to chance. Assemble your documentation A-team and start writing the kind of help content you’d want to read if you were a new user of your own product.
Sources and Further Reading:
- Natalie Luneva, How to Turn SaaS Product Documentation into a Growth Engine, ProductLed Blog, May 8, 2025
- Archbee Blog, SaaS Product Documentation: A Guide to a Company’s Secret Sauce, March 18, 2024
- Michael Murphy, The Secret Power of Technical Documentation in Customer Experience, CMSWire, Sept 19, 2023
- Who Writes Project Documentation?, MeisterTask Guide (2025) – “Documentation is a team effort… Subject matter experts should contribute”
- Mad Devs Blog, Why Documentation Is Important in Software Development, Oct 2023 – Emphasizes cross-team collaboration and having a technical writer for polish
- Ministry of Testing (forum discussion), “Is it common for testers to write the product documentation?” – Various professionals advocate that docs should be a team effort with testers, developers, and support all contributing
