This week’s debate question came from a reader of ProductCraft who was responding to our debate on where design should sit. In a LinkedIn post, he suggested that if only we debated the question of who should own documentation, all would be well. Well, you’re welcome!

Despite the dusty library feel of it, documentation is an important aspect of many software products today, especially for large enterprises. Even if it no longer exists in any way that resembles the manuals of yore, documentation is a critical resource for your users that should reduce friction and be easily accessible. Ideally, you’d serve it proactively and in context, but to make that happen – who should own it?

In our poll, 61% of you thought that the product organization should own documentation. 21% voted for customer success, 11% for engineering, and only 7% to support.


Product documentation is as labeled – documenting the product in terms of what it does, how it functions, how to configure and so forth. Docs is becoming a core part of any good product company’s customer experience, and increasingly, directly available within the product experience itself. This should be product-led at the bare minimum, but the doc writers or other content creators themselves may be in other orgs, like support or engineering. It’s also not just about traditional documentation – help and support content (topical, single subject content), which support sometimes owns, helps deflect inbound contacts while giving customers quick answers they need without reading ‘the manual’. Wherever support, help, or doc content creators are, PM should be driving alignment on how it all coexists, how a customer uses it and measuring it as part of product success.

Tom Witczak

Director of Product Management, Okta


In short, I believe it depends on the nature of the document, the nature of the team, and the nature of the product. For example API documentation, in most cases, should be co-owned by engineering and product; Support or customer success should own help center and knowledge base (which should be reviewed and QAed by product), etc.

David Schwartz

VP Product, Wix