Glossary
By the Glue Team
Technical product documentation is written explanation of how a product works, how to use it, and how to integrate it. It includes API documentation, user guides, integration guides, and troubleshooting. Good documentation enables customers to use and integrate products successfully.
Technical product documentation covers:
Customer Success: Documentation enables customers to succeed independently.
Support Burden: Good documentation reduces support tickets. Customers find answers themselves.
Adoption: Products with clear documentation have higher adoption.
Trust: Professional documentation signals quality and care.
Developer Experience: For APIs, documentation is the product. Bad documentation = bad product.
Outdated: Documentation from six months ago is misleading.
Incomplete: Missing features or use cases.
Unclear: Assumes too much knowledge or explains too little.
Hard to Find: Information scattered across multiple locations.
Wrong Examples: Examples that don't work.
Write for Your Audience: Adjust for skill level and domain knowledge.
Include Examples: Show how to do things, not just what's possible.
Keep Current: Update when product changes.
Make it Searchable: Help users find answers.
Use Clear Structure: Organize logically. Use headings and navigation.
Get Feedback: Ask users what's confusing.
"Code is self-documenting." False. Code shows what; docs show how and why.
"We don't have time to document." You don't have time not to. Poor docs increase support burden.
"Documentation is support's job." Partly true. Support documents customer-facing issues. Engineering documents technical detail.
Codebase Documentation: Technical documentation for developers. Product documentation is for customers/integrators.
Developer Experience: Good documentation is part of good DX.
API Documentation: Specific type of technical documentation.
Q: How detailed should documentation be? A: Enough to answer common questions. Too detailed becomes overwhelming.
Q: Should users ever need to contact support? A: Yes, but for non-documentation questions. "How do I do X?" should be answered by docs.
Q: How do you keep documentation updated? A: Make doc updates part of product development. When code changes, update docs. Review quarterly.
Keep reading
