Expanding from cross-product newsletters to a book club and site
- Abysmal newsletter metrics
- Pivoting to a cross-product newsletter
- Experimenting with a cross-product area newsletter
- Not much hope for the newsletter format
- Déjà vu to 2006
- New idea: a book club
- Conclusion
Abysmal newsletter metrics
Initially, I thought that newsletters might be the most common corporate format for getting a message across in a company. Blogs were highly uncommon internally, except for random pictures of employees’ dogs at work, from what I could tell. Instead, newsletters seemed to be more of a standard through which people could write and distribute lengthier content.
After some frustration over newsletter formats that stuffed all content into the email body, making link tracking impossible except for email opens, I converted our newsletter into a series of blurbs with links pointing to full articles on an internal website (not too unlike the newsletter for my idratherbewriting.com blog I send out). This approach allowed me to meticulously track clicks on the links. When I did, I was discouraged to find that newsletter readership was abysmal — people really weren’t clicking the links. I mean, maybe 5-8 people clicked links, out of several hundred recipients. People just weren’t reading newsletter content.
Pivoting to a cross-product newsletter
I decided to pivot the newsletter approach. I felt that my audience was too small, and I needed to expand it to get a more acceptable number of clicks. I modeled my new approach after another internal newsletter that targeted every related product group in a comprehensive way (cutting across multiple groups and org lines). I figured that if I had a much larger reach, such as the same reach as my personal blog, I’d see more clicks and traction.
I was convinced that size would be the needed trigger to see more acceptable metrics. Reason being, the newsletter distribution for my personal blog includes about 6,500 people. When I send out a newsletter, even if just a few people make comments or other reactions, it seems to make the effort feel worthwhile. With my personal blog, typically about 30% open the email, and about 200-300 people click the links on average. So overall, there’s decent reach.
Here are the newsletter metrics from Tinyletter (the newsletter tool I use) for the most recent newsletter I sent for my personal blog:
I use Rebrandly to track clicks on links. This is because I want to track clicks not only in the newsletter, but on Linkedin and Twitter as well:
And as much as I’d like to say I don’t care whether people read what I write, that’s not true. Few writers write without any anticipation of being read. It’s not that writing is an act of narcissism, where the writers aspires to draw attention to him or herself. Instead, I want the validation that what I’ve written is good. That what I’ve created is interesting, compelling, and means something to someone besides myself.
If no one reads my posts, it’s a good indication that what I’ve written is crap and that I should change my approach. Like a comedian, if no one laughs at your jokes [reads what you write], then maybe your jokes [articles] aren’t very good.
Experimenting with a cross-product area newsletter
To increase my audience reach, and hopefully find the readership I sought, I partnered with two adjacent documentation groups around me and sent out a cross-product area newsletter to a significantly larger audience.
How much larger? It’s hard to tell. With corporate email lists, there are often groups that include other groups as subscribers, with multiple levels of group nesting. I attempted to track down exactly how many people were included in the new list but lost visibility at some levels due to access permissions. My guess, however, is that the audience included around 1,000 recipients. Probably 3x my previous audience size.
In expanding the audience, it’s worth noting another difference between internet and corporate newsletters. Within a company, you don’t need to ask permission to send people newsletters. You can just target groups with information that you think is relevant to them. It’s the expectation that people just receive newsletters from relevant groups. Consequently, though, I’m guessing many view their inbox as a source of spam.
Partnering with the other doc groups to generate the cross-product newsletter was tougher than I thought. Not all writers were on board (at first), and they wanted much more discussion about the newsletter “plan.” I didn’t have a solid plan but wanted to keep it loose and experimental. My initial idea was to adopt a systems approach and comment on larger documentation trends and patterns across the developer portal.
In the first attempt, I simply wrote the newsletter content myself, identifying common themes across articles published by each group. For example, I noticed that each group was publishing information about certification, and I thought that trend was interesting. Should the certification steps follow a standard format? How did we ensure the certification steps across product areas didn’t overlap or contradict each other? Did certification align with some other canonical list of features or product roadmaps?
When I shared my proposed newsletter with the other writers, they unanimously told me that what I’d written was way too long.
They also said they preferred more of a contributor model where each group provided their input to the newsletter. So I scrapped my attempt at the emerging patterns approach, and we also simplified the theme to be easier and more practical. Instead of looking for higher-level patterns and themes, the new approach involved asking each group to answer these two questions:
- What are you currently working on?
- What have you recently published?
Each group kept their content to about 300 words, and I compiled the blurbs and sent out the newsletter. The newsletter looked pretty good and was more readable, but none of the recipients provided any feedback on it, neither as a reply to the email nor in the feedback survey. The number of opens was okay (~250), but this number doesn’t tell you if the email was open for 1 second or 10 minutes. In my experience, when you don’t hear any feedback about something you’ve published, it’s usually because no one is reading it, or if they are, they aren’t engaged by it.
Not much hope for the newsletter format
I started to realize that the newsletter format might be more limiting than I initially thought. I counted up about a dozen other newsletters sent by various groups within our product area, sent more or less to the same list. It seemed each group wanted to push out their own micro-newsletter, informing others that they exist and that they’re doing awesome things. I personally found little time to read these newsletters, especially because some were bulleted lists that assumed you already knew their acronyms and projects. I’m guessing our cross-product documentation newsletter was greeted as “yet another newsletter,” in the same way that people react when they learn that someone is starting yet another podcast.
I also became more perplexed by what I saw as an impossible situation. The only way to engage an audience, in my view, was to provide more interesting content. This is what I’d attempted to do with my systems view of documentation, focusing on trends and patterns. I thought if I were clever and insightful enough, people would take notice and our readership would increase. But the kind of content that would engage readers would require far more of an individual voice and bold depth than would ever be possible through a collaborative newsletter. Plus, it took weeks just to get all contributors on board to contribute just a few hundred words. Our writeups mostly resembled release notes as well.
Déjà vu to 2006
I started to think back to something I’d learned when I first started blogging back in 2006. At that time (before idratherbewriting.com existed), I volunteered as the Suncoast STC chapter webmaster, and I revamped the chapter’s website by converting it from Dreamweaver-based HTML to a WordPress site.
As I explored WordPress, I tinkered around with the blogging feature and tried to get the chapter to start a group blog. In a chapter of 100+ tech comm professionals, I thought it would be easy to have people contribute an article now and again.
Nope! The “group blog” was just Tom’s posts, which were mostly summaries of recent podcasts I’d heard. Getting others to contribute was like getting my kids to wash the kitchen dishes. After a half dozen attempts, I realized that this not going to work. The chapter blog would be heavily dominated by my own thoughts, and not representative of the chapter’s voice. So I started my own blog, separate from the Suncoast STC site, and I’ve been writing on it for the past 16 years. (For a trip down memory lane, here’s my first post, Why this blog, separate from the Suncoast Blog?)
So after sending out this first cross-product-area newsletter, it dawned on me that I was up against the same problem as I’d faced in 2006. Trying to get a group to collaborate on a content project would require a lot of arm twisting, motivating and reminding, and relentless project management.
And most importantly, there didn’t seem to be room for the individual voice in our simplified format (what are you working on? what have you recently published?). To write an 800-word, in-depth article that peered across product areas looking for insights didn’t seem to fit our simplified format.
I was stuck. The newsletter content that could represent a documentation group wasn’t the sort of content that would engage anyone. The diversity of roles we targeted (project managers, engineers, QA, and others) already cared little about documentation, and now with the newsletter devoid of any voice or interesting perspectives, the content was destined to confirm their non-interest.
Without engaging content, no one would read the newsletter. If no one read the newsletter, writers wouldn’t be motivated to contribute to it. This was a vicious cycle — the fewer people who read it, the less motivated writers would be to contribute. The less motivated writers were to contribute, the less engaging the content would be. Less engaging the content would mean even fewer readers, and on and on the vicious cycle goes. Pretty soon, both writers and readers would shrug their shoulders and say this isn’t worth it. That’s the course most newsletters run.
Despite the vicious cycle, I didn’t want to kill the effort, having just sent one cross-product newsletter. Also, I realized that I could use the newsletter to perhaps promote semi-related articles. For example, if I had any other content-generation efforts, I could include links to that content in the newsletter. But I abandoned hope for larger success from the effort.
New idea: a book club
While the newsletter idea struggled to survive, I had another idea brewing in the back of my mind. About six months ago, I started participating in a “Read a book a week” challenge at work. I’d become concerned that my reading had waned and I suspected the distraction of smartphones was a contributing factor, so I started a series that involved experimenting with techniques to regain my long-form focus. (See My awakening moment about how smartphones fragment our attention span.)
Among the books I started reading, I included a few books related to the auto and transport industry, such as books on autonomous driving, Tesla, the history of the automotive industry, and more. I work on documentation for geo-related automotive products, so this niche fit my work focus. To my surprise, I found the books really interesting, so I started reading more of them. In reading these auto-related books, I started to understand the big picture for the products I was documenting.
After having read a half dozen auto-related books, I began toying with the idea of starting a book club. Keep in mind, I’ve never actually participated in a book club all my life, despite being an English major (undergrad) and creative writing major (grad). And even though I write regularly on this blog, I was hesitant to start a book club at my work because this would involve promoting it, leading it, and doing other management tasks that would take me well outside my comfort zone.
Despite my unease in starting a club, I nevertheless created an internal site called the “Automotive and Transportation Book Club,” listed out six books that I thought were worth reading, and scheduled out discussions for each book at a monthly cadence. I described the reason for the club and then sent out a general email to my entire product area (hundreds of people) inviting them to join.
About a dozen people joined, which actually surprised me. During our first meeting, I introduced the purpose of the club and the books we would read. Some book clubs choose the books through member suggestions and votes, but I didn’t want to end up reading books that were duds or flops, which would likely kill the momentum of the club. I wanted to vet the books first. Consequently, the book club site looked more like a graduate course syllabus, highly crafted by me, rather than a monthly book club.
After a brief orientation meeting, we held our first book club discussion about a month later. We discussed Peter Norton’s Autonorama: The Illusory promise of high tech driving, which I reviewed on my site. The author, Peter Norton, advances a controversial position against autonomous vehicles (AVs), arguing that AVs will worsen rather than help transportation issues. To my relief, about 7-8 people showed up for this first discussion and had actually read the book (or part of it). The members included engineers, product managers, partner managers, and other writers. (Yes, there were multiple engineers who showed up, having read the book!) There were lots of smart people at my company, I realized, who wanted to expand their knowledge of the domain, no matter their role. I mostly facilitated the discussion, which lasted almost an hour.
Interestingly, many said that when they read Norton’s arguments, it was hard to know how to react. They didn’t know what to make of his arguments. But hearing other voices and perspectives in the room, they felt more confident in questioning or even rejecting some of the book’s ideas.
I knew I’d picked a controversial topic, hoping that it would draw people in by challenging some of the directions the automotive industry is going. It seems like everyone is moving toward autonomous levels of driving (thanks to Tesla), without fully questioning whether it’s the right direction. With this first meeting, I’d introduced an author who said that this whole AV endeavor was not only a fool’s errand but one that actively harms efforts at more practical solutions involving public transportation. Selecting this book was a bold move on my part, but one that I’d balanced with books later in the schedule exploring opposing points of view.
Actually, my timing for this book club was great. There’s no better time to start an auto and transportation book club than now. The automotive industry is on the verge of a massive transformation, with trends toward electric vehicles, autonomous driving, micro-mobility (e-bikes/e-scooters), and mobility as a service (Uber/Lyft) all converging and influencing each other. There’s never been such a disruptive time in the auto and transportation industry than now, and that’s probably why so many people were interested.
Conclusion
After the first book club meeting, I started to realize that I’d found my focus. Here was a topic that interested people across a variety of roles, not just other writers. There was a real reason for people to be drawn to it — they found the content relevant, so much so that 7-8 people had purchased the book and spent hours reading it, then devoted a whole hour to discuss it. (No one had even put forward two minutes of similar effort toward documentation.) And I was also drawn to the topic, despite having almost no background in the auto industry.
Approaching the topic from the book club angle allowed me to engage in the content without claiming any expertise. I could summarize and present the views expounded in books. I felt that I could contribute real value by first identifying relevant books in the domain, summarizing the main arguments, articulating the discussions, finding related news and resources, and more. This would give justification for an internally focused blog, which I would brand as a companion to the book club. With so few people reading books anymore, this was one area I could lead out in. Lots of people wanted to read these books, and my book club offered them an opportunity to do so in a more structured way.
It’s still early with the book club experiment — we’ve only had one real discussion meeting. But I feel like I hit a turning point with the effort and now understand the direction I need to go. My next plan involves building out more of the blog feature of the companion book club site, where I’ll post more book summaries, discussion notes, and related resources. Most importantly, I hope it gives me the space for my individual voice, where I can dig into topics with the depth and expansion I originally envisioned.
Images for this post come from Midjourney, an Art AI tool.
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.