As a software technical writer, I recently finished reading the book "The Product is Docs" by Christopher Gales and the Splunk documentation team. The book offers practical advice on treating your documentation as a product. Initially, I was fully convinced that technical documentation is a product in and of itself. However, after careful consideration, I've changed my perspective.

While researching for a method article about measuring documentation quality for The Good Docs Project, I came across Bob Watson's insightful series on his blog "Docs By Design." Watson presents compelling arguments that documentation is a satellite to the main product or project. This resonated with me because documentation exists primarily to help users when they're stuck. Most people consult documentation to find answers to specific questions, not for leisurely reading. They engage with the docs because they need assistance, not for the sake of reading the documentation itself.

So, no, the product is not docs.

However, this realization doesn't diminish the importance of treating documentation as a product. In fact, I believe it's the best approach to building trust with your users or clients for the following reasons:

1. Commitment to User Experience: Treating docs as a product demonstrates your commitment to providing users with the best possible experience with your actual product.

2. Meeting User Expectations: Users and clients expect to find autonomous ways to solve issues and get unstuck when using your product. High-quality documentation meets this expectation.

In summary, while the product itself is not the documentation, treating your docs like a product is crucial. It showcases your dedication to helping users succeed with your product and fosters trust in your commitment to their experience.

So, there it is – my nuanced view on the matter. The product is not docs, but docs should be treated like a product.