Marcom and tech comm
- What is tech comm and marcom?
- Why I embraced tech comm and marcom
- Why I abandoned tech comm and marcom
- Current status
- Takeaway
- Next post
What is tech comm and marcom?
Tech comm and marcom (marketing communication) refers to using tech comm content with marcom campaigns. The idea is that documentation can be used for more than just product instructions. Documentation can be leveraged as a full-fledged marketing asset, repurposed into white papers and other collateral to give more visibility to a company’s products and services. After all, documentation is information rich, keyword dense, and of high value to users. Why not use documentation to help increase awareness and sales of the product? Why not use documentation to help build relationships with customers?
In fact, in The History of Content According to Sarah O’Keefe - Pt 3, a Content Components podcast, Sarah says that around 80% of people who are researching consumer products read technical documentation (for example, specs, configuration, and operation) before they buy. They want to know whether the product product is compabitible for their use cases and expected experiences (see the 5-6 minute mark in the podcast). When customers see documentation, they get a sense of the complexity of a product, the time for implementation, requirements, and more. Documentation isn’t just a post-sales artifact — it’s also pre-sales. And as a pre-sales artifact, there’s a space and rationale for using docs into the marketing domain.
Why I embraced tech comm and marcom
As someone who writes regularly on a blog, I thought that extending my writing talents into marcom domains would be a logical fit. I could bring my product knowledge to the marcom writing scenarios and communicate complex concepts (in blog posts, ebooks, white papers, or other marketing collateral) with clarity and precision.
Additionally, from my experiences working in developer docs, I knew that most developers preferred to have more information-rich content anyway, not high-level promises in slick-looking PDFs. Everything pointed to me getting more involved in marcom.
Why I abandoned tech comm and marcom
Although contemporary marketing theories seem to embrace the development of helpful, story-rich content of interest to customers (rather than more traditional sales-oriented literature), I’ve yet to work with a marketing group that actually does this. The marketing groups I worked with rarely ventured beyond highly sanitized, happy-path topics to address actual frictions and issues that might be engaging to customers. Transparency and storytelling weren’t emphasized to the degree that I wanted. My experience in the blogosphere taught me that transparency and storytelling were key elements for success, and I brought similar assumptions about the essentiality of these elements to marcom scenarios.
I remember working on a blog post for Fire TV that turned out to be particularly frustrating. I wanted to address one of the most pressing issues we were facing — the fact that some apps had voice interactivity and others didn’t, which was creating inconsistency in the user experience. After raising this issue, I then explored solutions for how users could more easily voice-enable their apps. Except that the marketing group wouldn’t let me explain the issue and how the lack of some voice-enabled apps were leading to inconsistent user experiences on Fire TV. I could only write about the solution, so the article (which you can read here) ended up mostly being a tech tip, not too different from the documentation overview for the feature.
Whenever I tried to write anything that addressed an issue or friction, it was cut out so that only the tech how-to remained. If you try to create a story-shaped blog post without mentioning any issues or frictions, you’ll find that it doesn’t work. After a few rounds of this, I grew uninterested in copying/pasting docs into marketing blog systems. Additionally, I felt that any docs that I put into marketing blog posts would go out of date and not be maintained after the day it was published. I decided to just stick with docs, where I felt I could be more transparent. (However, even transparency in docs was sometimes an issue — see my post Transparency in documentation: dealing with limits about what you can and cannot say).
Despite my frustrations in writing marketing collateral, this isn’t to say that docs weren’t used in marketing scenarios. The most popular documentation I worked on at Amazon was the Fire TV device specifications, which were regularly referenced in device product announcements (such as this most recent one).
Additionally, some marketing collateral, such as this ebook about publishing on the appstore, could have clearly benefitted from content re-use strategies. The marketing writer pulled from [copied and pasted] a lot of documentation into sections of the ebook. This content quickly went out of date. Also problematic was the fact that the ebook was written in InDesign (I think), and there was no easy way to single-source the content. A content re-use strategy for ebook creation would have been a much better partnership with marketing than trying to write blog posts.
At one point, the marketing team even adopted Adobe Experience Manager (an expensive CMS), which has an XML documentation component that I described in a sponsored post. I thought this CMS would allow us to re-use documentation in marketing assets, but apparently you could only embed docs in certain regions in templates, not freely mix docs with marketing content. At any rate, we didn’t want to migrate all content to XML and manage it in that system anyway, so the team never invested in the actual XML documentation component required for this collaboration.
Sadly, even in a scenario where tech docs and marketing were on the same team, we struggled to blend tech comm and marcom in harmonious ways. One reason for our lack of success was simply bandwidth. As tech writers, we always had our hands full with documentation needs, and had little time to collaborate on marketing assets. Marketers and tech writers still mostly operated in separate silos.
Current status
The prevailing strategies with marketing are to nurture customer relationships through content marketing, not to just push sales literature to customers. The most effective strategies for this will involve reusing documentation in marketing assets, not in having tech writers start creating marketing materials.
In some ways, I miscalculated the way tech comm could interact with marketing. Perhaps it’s not a matter of using tech comm in marcomm materials, but rather using tech comm as marketing materials. Do companies really need ebooks, white papers, and blog posts? Or do they just need to make their documentation visible and online? It’s probably less of the former and more of the latter.
Takeaway
Marcom depends on tech comm for relevant content, but re-using documentation content within marketing materials (instead of just linking to the docs) doesn’t work well due to differences between marcom and tech comm related to mindset, tools, styles, openness and transparency, and content lifecycles.
Next post
Continue to the next post in this series: Every page is page one.
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.