RSS
TwitterThe role of TechComm in reaching the Holy Grail
Introduction
Last year, my development department held a series of meetings to discuss ways in which we could help significantly increase the sales of the products we make. This year, we’ve put a lot of what we discussed into practice, and the Technical Communication team has played a key role.
Our department believes we make excellent products, and we have the customers to back this claim up. As a development lab though, we do not sell our products. This is the job of sales people in our company’s subsidiaries around the world, and among our partners. We know our products can sell, but can we make sales sell more?
The Holy Grail
I like to think of the Holy Grail as giving subsidiaries and partners the “magic power” to sell, implement, and support our products better, and more independently from the development lab. However, it’s not really magic, it’s about giving them the skills and knowledge found within the development lab itself.
How can the Holy Grail be achieved?
This is what we have achieved this year:
- Fully-featured demo systems
Pre-configured, with sample data, and complete with full instructions. Great for sales and pre-sales meetings, as well as instructor-led training courses. - Detailed sales presentations and other material
- Comprehensive best practices
Initially created as a package to sell the most effective solutions and implement them in the shortest amount of time, best practices also help educate people about the product in general. - Copious amounts of helpful documentation
Documentation that not only explains the technical nitty-gritty, but that contains quick start and general topics for those new. The documentation doesn’t answer every question, but it covers the basics well. - Training material
Lots of presentations that can be used to give instructor-led trainings. - A video library
Yes! Is there anyone who doesn’t now believe in the power of videos? When you want to refresh your knowledge on something, would you rather browse help topics, try your luck by experimenting in the software/hardware, or sit back and watch a 5min video explain everything? I have a big demand now for more videos, from people who realise their value. - We have attended courses to improve our business process knowledge and the environment in which our products are used.
- An easy-to-use, but powerful intranet presence, which encapsulates all of the above. Sales and technical staff can dig into our resources, find what they want fast, and learn as much about our products as they want, in all kinds of different ways.
Conclusion
We can’t attend every sales meeting, workshop, or implementation around the world. We have a division of labour and we think this labour power can now be utilised to the maximum, thanks in no small part to the efforts of our technical communicators (but also to our developers, solution managers, and support staff). The next time you think about what a technical writer does, or should or can do, consider the bigger picture and the Holy Grail.
You say that it’s about giving skills and knowledge to subsidiaries and partners. What about the end users of your products? Isn’t it at least possible that your products are easier to sell if word gets out that their documentation empowers end users? Conversely, isn’t it possible that poor documentation will make even the finest products harder to sell?
A while back I too wrote about the technical writer’s holy grail. But instead of enabling subsidiaries and partners, my emphasis was on pleasing the end users. I still think that this is the best perspective to have.
Hi Larry,
For the software we produce, our main end users are our subsidiaries and partners, specifically, their pre-sales staff and consultants. Arguably the most important work our company does is the design of the project specifications, the project implementation, and the subsequent support after the go-live. And this is reflected in our documentation, which is mostly devoted to configuration topics. The documentation we produce to cover the “classical” end users—those who use the software, is not our most significant or largest (although of course still important). In our case, the software is designed to be very easy to use, and people can feel comfortable using it with minimal training and reading. My article just assumed this, so thanks for asking your question and allowing me to clarify what we do.
But to come to the point: When you write that documentation that empowers end users makes products easier to sell, this is exactly what I mean too. Only that we are talking about slightly different end users. In my company’s case, I see the role of the TechComm team in helping to provide the full package of materials that will enable subsidiaries and partners to better sell, implement and support our products.
I wasn’t aware of your earlier blog post (and your reference to the “Holy Grail”—good that we’ve both got ideals!) Yes, I agree documentation should please every user. I would add that it should also please every type of user: sales, pre-sales, consultants, and the standard “end users.” Sometimes you need different documents to cater for different audiences, but often one document is used by everyone.
Regards, Jason
Thanks for clarifying, Jason. While you might be a tenor and I might be a bass, it certainly sounds like we’re singing from the same songbook.
Yes, it sounds like it. :-)
Hallo Jason
Great post! It sounds as if you have had a very busy year indeed, with so much achieved. I think you are 100% right, when you encourage people to think about the bigger picture when considering what a technical writer can do. Of course, this extends to thinking about the value of the documentation and other technical communication deliverables.
I also like this point in your post: “We have attended courses to improve our business process knowledge and the environment in which our products are used”. Our own team has found it very useful to attend user group meetings and other get togethers where the customers congregate, to find out more about the ways they are using our products as well as our documentation.
Cheers, Sarah
Hallo again Jason
I hinted at this on Twitter a while ago, but now I’m just letting you know in more detail, that I’ve referred to this post in my upcoming book, Confluence, Tech Comm, Chocolate: A wiki as platform extraordinaire for technical communication.
The book also refers to your post called “Social media and trends in software user assistance: Twitter and rich media” (November 2010).
The book will be published in February 2012. There’s news about it on my blog, and also at the publisher’s site: http://xmlpress.net/publications/chocolate/
Thanks for all the great blog posts. :)
Cheers, Sarah