I am a marketing graduate, and I work in the field of technical communication. Therefore, it is natural for me to relate what I learned (about a decade back) with what I learn or do every day. I see that the rule of four Ps is very popular in the field of marketing. And, this post is about the two Ps that apply to technical communication as well.
Let us start from the start. What are those 4 Ps? The Ps – Product, Place, Price, and Packaging – deal with the basics of marketing. Product, I’ve learned, is about what you have on offer. Place is about the para-language, ergonomics, and conditions prevailing at the point of your contact with the customer.
Price, in marketing, is extremely important. I recall having told that the easiest way to sell/resell a product is to either increase its value or decrease its price. I wonder if this still holds true, because I don’t find things getting either cheaper or free. In fact, it is quite the opposite. Packaging, which is the last P, is about answering the “what’s-in-in-for-me” question.
The two Ps that I find are common between marketing and technical communication are: Product and Packaging.
The most important (perhaps, the most basic) thing in technical communication is to write about products. But, that’s only half-true. In case you recall one of my posts, I’ve said that I don’t really get paid to write about my company’s products, but I get paid to write about how you could get benefitted by using the “core offering.”
We follow a three-step review cycle for our documentation projects. We write the first pass when the first internal release is out. And, normally, we sprint a lap behind the test department just to be sure that by the time we get to test the initial releases of the product, the critical issues in test cases are resolved. Eventually, that’s what makes our jobs easier, because a lot of features change with time. On a lot of occasions, our developers add a few capabilities to the listed features. We must test those features before we write about those in our documentation. That’s because I am not writing only about the product, but also about its features.
In one of the earlier posts on my blog, I said that I do a lot of stuff that my colleagues from the other departments do. I do a bit of testing, a bit of marketing, and a bit of support. That doesn’t change what I do (or am expected to do); but, that adds to the effectiveness of my documentation. It is because I focus on the application of the product’s features.
I think it is standard to abridge the product’s feature with the customer’s needs. I connect my product’s features to the customer’s requirements. And, as long as I don’t promote my product, I think I am good to go. But, that doesn’t mean I do not package my documentation well. This may sound like a diversion, but promotion is a lot different from packaging.
They say that it doesn’t take a lot to make a book a bestseller: You just have to put a girl on the cover and put not-that-much cover on the girl. But, the truth (in this case) isn’t even close. The “bareness”, here, lies not in sensationalizing things, but in making sense. I write about the application of my product’s features; and I connect my readers’ issues with respective solutions/workarounds. That still doesn’t complete the cycle, though.
One of my objectives is to help readers take intended actions. So, communicating about what or where the problem is, is not enough. I must also show them how to resolve their issues. And, that’s exactly where the “packaging” part comes into picture. Whenever and wherever I link, refer, or combine related information, I create a “package.” This package helps my readers locate their required information easily.
Ever since I began working on the current product line, I’ve been creating numerous such packages. Actually, I see that my documentation is nothing but a meaningful bunch of such feature packages. The knowledge and information gathered during graduation helps me conceptualize the design and delivery of information. It also helps me create and deliver flows of interrelated topics that can help my customers comprehend and use the products better.
Irrespective of what forms of documentation you use, do even you deliver in feature-specific packages? How business-driven is your user documentation? I am curious.