I’ve illustrated the three types of knowledge in the following diagram.
When you combine technical knowledge, product knowledge, and user knowledge, you become a key player in your organization. Usually engineers dominate the technical, product managers dominate the product, and support dominates the users. Technical writers need to a decent understanding of all three of these domains to write useful documentation.
Here’s a little more detail about each type of knowledge:
I know that just writing docs, you pick up this knowledge. But you can also purposely turn up the dial by putting in “extra” time in all three of these areas.
Additionally, these three areas of knowledge feed off each other. If you want to ramp up on technical knowledge (say, by learning Android), there is simply too much to cover by just reading how-to books on Android. You may spend weeks learning about features that no user cares about, and which are irrelevant to your product. By understanding user questions and issues, you can more accurately focus your deep dives into technical and product knowledge, and vice versa.
Ideally, I’d like to test out my hypothesis about the importance of this knowledge by dialing up my expertise in these three areas over the long term.
Get new posts delivered straight to your inbox.
I'm a technical writer based in the California San Francisco Bay area. In this blog, I write about topics related to technical communication — Swagger, agile, trends, learning, plain language, quick reference guides, tech comm careers, academics, and more. I'm interested in , API documentation, visual communication, information architecture and findability, and more. If you're a technical writer of any kind (progressional, transitioning, student), be sure to subscribe to email updates using the form above. You can learn more about me here. You can also contact me with questions.