Your Technical Writer Knows More About Product Development Than You Do
That technical writer in the corner quietly working on content? They know more than you do about the efficiency and effectiveness of your product development.
What? How?
Technical writers are still, usually and unfortunately, downstream from product, engineering, UX, and other functions, yet depend on timely information, good processes, and product quality to do their jobs well.
Ok, sure. Not every technical writer truly knows more about your processes than you do, but if they are any good, they will. To understand how this is possible, let’s dive into what technical writing often looks like in an engineering organization.
Technical Writers Depend on Development Processes
Traditionally (I’d say “in the past,” but it still happens), technical writers are hired after a product has been in development for roughly 3 years. At that point, content already exists, usually written by an engineer, a support person, or a product manager (or all of the above). Typically, an organization hires a technical writer when they realize customers need help using the product and the content that exists is insufficient. At this point, content is usually scattered, duplicated multiple places, or lacking in volume and quality. Or all of those things.
To remedy these issues, a technical writer must become intimately familiar with every step of your product and engineering processes. They need access to the product roadmap, so they can deliver documentation with the product release. They need to learn the product like a power user so they can answer the questions of an actual user before they are asked. They need to understand the steps in the engineering process so they can research, write about, and publish content on new features at the sweet spot where the product is mostly developed and unlikely to change, but hasn’t yet been released.
If they’ve been a technical writer anywhere else, they’ve seen other engineering and product teams do better (or worse) than yours. The sign of a mature engineering and product process is one that allows for success of everyone, including technical writers. Good processes on the product and engineering side means not just high-quality documentation, but a more efficient approach to creating and releasing features in your product, higher customer satisfaction, and better overall employee morale (clear expectations = higher morale).
Thus, if your technical writer were ever in a large company that has good documentation, you can be sure they have helpful takeaways about how product and engineering processes can be more efficient, streamlined, and set your entire business up for success.
Technical Writers See Where the Process Breaks Down
Technical writers are sometimes the only people who see the entire product and user journey from beginning to end before it’s released. In becoming power users of your product, they find the bugs and inconsistencies in words and navigation. UX designers work to eliminate these up front, but rarely get to check or impact this after feature development. Technical writers see when UX writing input was ignored or missed.
Engineers and product managers see the nitty gritty details of the small pieces for which they are responsible, engineering and product manager leaders see the products and features as they work together at the highest levels. Technical writers see both.
How Can I Learn from the Technical Writer?
If a Technical Writer has suggestions for how to improve your UX, product, and engineering processes, listen. If that information isn’t volunteered, you can ask them what they think.
Not all technical writers may have an opinion, but I bet they can tell you what would make their lives easier. And, if you are proactive in checking in with them, you might learn a thing or two that would solve other issues in your product development processes.
Even better, get your technical writer involved early. If you don’t have a UX writer or content strategist, your technical writer can have a huge impact on the success of your product by suggesting some consistent words. They can put together strings for error messages or recommended wording or tips for engineers or product developers to make them more understandable. And, they can read, edit, and ask questions about them too. And, since they see the entire product they might provide insight you don’t have into how the product works already.
The best companies I’ve worked with have built listening to everyone into their culture (technical writers, UX designers, admins — everyone). You just never know who might have an incredible idea or thought that can improve and change things. And, this often is a way to elevate and listen to the voices of people who are underrepresented in other areas of your business (for example, BIPOC).
I hope I’ve convinced you that technical writers can add value far beyond documentation. I’d love to know your thoughts on other reasons why technical writers may know more about your product and engineering development processes than you do. Please comment!
