Part 5: More specifics about finding a focus
Audience and focus
On the web, for this blog (idratherbewriting.com), my audience consists of other technical writers. In the workplace, I’m not interested in interacting with other tech writers across the org (they can already read my blog if they want); I’d rather interact with people within my organizational unit. And the people within my organizational unit consist of product owners, developer relations, support, engineers, project leads, tech leads, quality assurance, senior executives, instructional designers, other technical writers, and more. At least, this is the audience I want to engage with, rather than other tech writers beyond my group at work.
The diversity of roles in this audience makes a huge difference. As a tech writer, I can share an experience related to writing docs, or a doc-related tool, etc., and other tech writers can often relate to the experience. We build on this common ground.
Take away that common ground, and you have to substitute in another way to bring people together. What brings all of these diverse people together? Most likely, they’re all working on the same product, focused within the same business domain.
But even though these diverse roles share a common product domain, their interests in that product will differ. A senior executive will have different interests than a quality engineer. A product manager will have different interests than an instructional designer, and so on. I guarantee you one thing: few will have much interest in documentation itself. The nitty-gritty details of documentation, such as how content is organized, styled, authored, published, etc., are going to be somewhat unimportant to these teams, in the same way that the database schema or code structure might not interest technical writers.
This makes it more challenging to connect with this diverse group. What content do you focus on? If you don’t write meta content about the details of documentation, what then do you write about? A few ideas come to mind:
- User experiences and pain points. For example, where are users getting stuck and why?
- Tech news/trends within the business domain itself. For example, what advancements and other new tech trends are occurring in this space?
- Comparisons to competitors. For example, how does our product and terminology differ from our competitors?
These topics seem worthwhile and might have broad interest despite the person’s role. The focus on user experience and pain points is more germane to documentation, but the other topics could also work well. Let’s explore each of these topics a bit more.
User experiences and pain points
Writing about user experience and pain points focuses tech writers in the right direction, for sure, but this focus is not as natural a fit as it sounds. User experience and pain points relate to the existing product features, not to features in development. Tech writers usually focus most of their time and energy documenting upcoming features for releases, so they’re a bit removed from the current user experience.
Additionally, engineers tend to focus on features for upcoming releases as well, so their attention isn’t always on the current user experience. Granted, pain points in the current experience should drive the upcoming product roadmap, but often the only teams focused on the current user experience are support groups and developer relations.
For example, regardless of the company, it’s not uncommon to see an incoming flow of bugs filed by users/partners. Sometimes when I look at these tickets, I think about the ways that better docs and more complete information might have prevented the ticket in the first place. But it’s hard to find the discipline to look through these bugs and write docs related to the issues (which are all over the map).
Instead, it’s more natural to focus on documentation for an upcoming release. Releases are often blocked without accompanying documentation, but existing bugs can remain in backlogs and even be resolved without any additions to the docs. (And the tech writer’s attention is dictated by priority — the team working on the upcoming release often dictates the highest priority.)
If tech writers are focused on what’s coming rather than the current user experience, this makes it difficult to focus on current user pain points. However, pushing tech writers to focus more on the current experience would be beneficial, so it might be a good focus anyway. The tech writer’s interpretation of user pain points will inevitably connect to documentation needs or efforts.
Another issue with focusing on the curernt user experience is that, sadly, tech writers tend to be disconnected from users. It’s not as if you’re chatting regularly with users during meetings and other events. I wrote about this challenge here: Principle 6: Reconstruct the absent user. The main challenge of technical writing is that you’re writing for an audience that’s mostly absent and disconnected from the writer.
Tech news/trends within the business domain itself
Another focus could be trends within the business domain itself. What trends, new products, and other newsworthy items are happening related to the product domain? For example, you could summarize reports from Gartner, Forrester, trusted online sites, and other insightful sources. You could describe relevant survey outcomes, or trending topics on various platforms. News (specifically, what’s new) is a topic that never fails to attract interest. You don’t have to be a pundit who assesses whether trends are here to stay or go; instead, you could just relay the information that you glean from other sources.
Comparisons to competitors
Another approach could be to describe comparisons with competitor products. When I worked at Amazon, I once wrote a detailed competitive analysis between Fire TV and Roku, describing the entirety of the developer’s app-development journey from beginning to end (how devs create an app, the language they use, available frameworks, the submission process, and so on). The competitive analysis report was interesting to senior leaders, and it was also informative to doc efforts (particularly with terminology).
It wasn’t just interesting to business leaders. As a writer, this research helped me realize how terminology differed, what the strengths of our product were (as well as the gaps), how developers had to split their codebases for apps across streaming media platforms, and more.
A focus on competitor offerings, techniques, and content and how it might compare with one’s own company could be engaging to both the writer and reader, especially because so many people tend to be focused solely on their own company’s products. I’m not sure if a competitive analysis could be an ongoing focus, and there might be a lot of landmines here, but it’s certainly a focus that gets people’s attention.
Let themes surface naturally
Generally, if you’re on the lookout for potential newsletter topics, they surface naturally. It could be that I’ve been blogging for so long that I’ve learned to develop an ongoing awareness, always on the back-burner of my mind, for potential topics to write about. But I think any writer who is paying some attention to potential article topics will find ideas trickling in.
My recommendation is to heed these ideas when they surface and note them somewhere. The more you write down the potential ideas, the more you train your brain to keep generating ideas. It’s like keeping a dream journal. If you start writing down your dreams, you begin to remember them more — you’ve trained your brain to watch for the dreams and remember them. This phenomenon is also why it’s easier to write regularly rather than infrequently. If you write regularly, you train your brain to look constantly for ideas, and the ideas start to flow.
Bringing up docs where relevant
With all of these topics, doc topics will naturally surface along a variety of themes and perspectives. For example, in analyzing a competitor’s offering, you might highlight the related documentation, or address your company’s own documentation. The same goes with user pain points. Trends might relate to upcoming features on your roadmap. This tie-in with documentation will help reinforce some of the reasons for the site itself.
In the next section, I’ll look more closely at the newsletter format as the predominant medium in the corporation for this type of content.
Next post
Continue to the next post in this series: The newsletter as the social content of corporations.
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.