Stay updated
Keep current with the latest trends in technical communication by subscribing to the I'd Rather Be Writing newsletter. 5,800+ subscribers. (See email archive here.)

Search results

Three types of knowledge every technical writer needs to be successful

by Tom Johnson on Apr 27, 2016 •
categories: technical-writing

Today I was thinking about the most important element in a successful technical writing career, and I think it's knowledge. The more you know, the better information you can write. There are at least three main types of knowledge: product knowledge, technical knowledge, and user knowledge. Just knowing one of the three won't provide you with the kind of information you need to write good documentation.

I’ve illustrated the three types of knowledge in the following diagram.

These are the three types of knowledge you need to be successful as a technical writer.

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:

  • Product knowledge: A solid understanding of the product. You get this information usually by reading the company wiki, roadmaps, sprint items, and other domains where product managers and others write specfically about the product.
  • Technical knowledge: A strong understanding of the technical details needed to be successful in this domain, such as an understanding of a programming language or platform. Java, Android, PHP, and so on.
  • User knowledge: An understanding of user questions, issues, complaints, requests, and other feedback. You often acquire this knowledge by reading forum threads, looking at support logs, attending trainings, or other interactions.

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.

Buy me a coffeeBuy me a coffee
Stay current with the latest in tech comm
Keep current with the latest trends in technical communication by subscribing to the I'd Rather Be Writing newsletter. 5,800+ subscribers. (See email archive here.)

follow us in feedly

About Tom Johnson

Tom Johnson

I'm a technical writer / API doc specialist based in the Seattle area. In this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, visual communication, information architecture, writing techniques, plain language, tech comm careers, and more. Check out simplifying complexity and API documentation for some deep dives into these topics. If you're a technical writer and want to keep on top of the latest trends in the field, be sure to subscribe to email updates. You can also learn more about me or contact me.