Tuesday, August 18, 2009
Is Social Media a Fad? Or Essential to your Business?
Watch this and then decide if you should be spending your marketing budget and hours on SEO optimization of your website and search based ad-word campaigns, or on building a community using Social Networks?
Friday, July 10, 2009
Rockets and Notebooks
As I mentioned over on my personal blog recently, I have been doing a lot of research into the history of the space program, and a few weekends ago took a trip to the New Mexico Space Museum. While I was there I got chatting to one of the museum volunteers who had worked in the astronauts’ office during the Apollo days. During the conversation he offered the observation that:
“There were things they did back then that we can’t do today.”
This reminded me of a conversation I’d had many years ago while visiting one of the NASA facilities where an engineer had told me that even though the Saturn V rockets on display at the Cape Kennedy launch site in Florida and the Johnson Space Center in Houston, TX (below) were fully functional, they could never be put back into service as no-one knows how to operate them. As the engineers from the Apollo projects dispersed or died off, and the focus shifted to Shuttle operations, the institutional knowledge needed to launch a Saturn V disappeared.
“There were things they did back then that we can’t do today.”
This reminded me of a conversation I’d had many years ago while visiting one of the NASA facilities where an engineer had told me that even though the Saturn V rockets on display at the Cape Kennedy launch site in Florida and the Johnson Space Center in Houston, TX (below) were fully functional, they could never be put back into service as no-one knows how to operate them. As the engineers from the Apollo projects dispersed or died off, and the focus shifted to Shuttle operations, the institutional knowledge needed to launch a Saturn V disappeared.
Recounting this story a few days ago prompted another memory. Several years ago, the consulting company I was working for was engaged to help identify just such a loss of institutional knowledge. During our time at the company we discovered that a tradition had developed among the people who worked on the assembly line to keep a small note-book in their overalls pocket. These notebooks were used to write down workaround steps, or take notations on how to improve the efficiency of the assembly process. Many of the notebooks had photocopies of pages from the company official assembly manuals pasted in with notations added. We also found out that the people with the longest service could assemble the product in about half the time the official process said it would take. The increase in efficiency was due to a combination of experience, and the tricks and short cuts they had written in those notebooks. The real problem came when the longest serving employees retired or moved on they took their notebooks with them. The institutional knowledge was lost. Each new person employed on the assembly process would start from zero with the official procedures and have to relearn all the tricks that their predecessor had developed.
Because the existence of the notebooks was never officially acknowledged, they were never included in any part of the company’s knowledge capture procedures. Our recommendation was to engage the people in the company who had the best skills for interviewing subject matter experts – the technical documentation group. From that point on a monthly review session was held where a technical writer would sit down with the assembly team and take notes on what the engineers had written down in their personal note books over the previous four weeks.
In fact in today’s economy where turnover of staff is high and a lot of valuable information is lost during layoffs etc., this is a great opportunity for a Technical Documentation team to showcase how their talents can be used and the real value they can bring to a company.
If someone who held a technical role is leaving the company, for whatever reason, don’t just conduct an exit interview with the HR department, but have them sit down with a technical communicator who is good at interviewing subject matter experts. Do a proper debrief and capture not only their notes, but the inherent knowledge and process tricks that are in their heads too.
Perhaps if NASA had done this, we might still be able to fly those Saturn Vs.
Monday, June 22, 2009
It's STC not STW
There’s been a lot written lately about the financial and operational crisis that the Society of Technical Communicators is facing.
A lot of people have posted some great ideas on Twitter (Identified by the #stcorg hashtag), and bloggers such as Sarah O’Keefe and Tom Johnson have outlined several ideas and observations that I agree with, and don’t intend to repeat here.
However there is an aspect of this institutional crisis that I believe needs a little more exposure, and one I’ve raised during several recent presentations at different regional STC events.
The third letter in our professional organization is C. C for communicators. It isn’t W for writers, yet that society is overwhelming sold to technical writers, its publications are aimed at writers, and not surprisingly the vast majority of its members are writers.
But what about the other “technical communicators”? Where are the technical illustrators, the animators, the graphic designers, the video producers, the script writers, the podcasters, etc.?
When I’ve mentioned this before the answer I’ve invariably received is “Oh we have SIGs for them.” – Special Interest Groups – really?
They aren’t a marginalized “special interest,” they are the future of the industry.
When I joined my first technical publications department in the mid 1980s the ratio of writers to illustrators was 2:1, add in other people who contributed to the production of the technical documentation and the number of writers was actually less than 50% of the total departmental head count.
In the opening decade of the 21st century when more people receive information visually than ever before a Society of Technical Communicators should be full of people who think, and deliver information, visually.
If the STC is to survive, it needs to attract and embrace the practitioners of the visual arts.
The same goes for those who are as comfortable working in the sound medium too – and the training folks who are developing interactive documentation, and – well the more you think about it the more the list grows.
As a writer, I would be delighted to see the day when the membership of the STC resembles that technical documentation department I joined over 20 years ago – where writers are actually in the minority.
Wednesday, June 17, 2009
Truth in Marketing is not an Oxymoron
“I’m a writer; I take the truth and give it scope.”
– Paul Bettany as Geoffrey Chaucer in A Knight’s Tale (2001)
If I have one underlying tenet that I try to live by, it’s to tell the truth. It’s a philosophy I also apply to my writing. Most of my published work to date has been non-fiction, and by its very nature involves a lot of research and fact checking to make sure that what you are presenting is the “truth.”
The problem with doing research based on historical events, and particularly in the case of biography, is that the “truth” is often what the person telling the story believes to be true. For that reason, as much as possible, I try and go back to original sources and documentation. The same thing applies when I’m writing fiction, I always try to stay truthful to the established rules of the fictional world I am working in. With a licensed property that also means doing a lot of research into the facts that other writers have established.
So what has this got to do with corporate communications?
Most of the corporate writing I do these days is marketing communications. From blog posts, to Twitter, white papers, product literature, websites, and press releases. And, as with my other writing, I always try to tell the truth. Sure, as the quote at the start of this post mentions, I sometimes take the truth and give it “scope.” Yes I’m perfectly happy saying that 10% is “double digit growth” or that 51% equates to “most,” or “the majority,” because beneath the spin they are still verifiable facts.
Where I have problems is with marketing spin that uses absolute terms like unique, best-ever, ultimate*, or first. if you want to use those terms, that’s fine – but do some research and some fact checking to make sure that you really are the “first to market”, or that what your product does really is “unique,” and if what you are offering really is the “ultimate,” are you really intending to never improve it.
This is even more important when you are marketing to an audience whose daily job revolves around words and the use of language. Say the wrong thing, use the wrong word and they will go check. If what you claim isn’t true – they will call you out on it. That will undermine every other marketing message you put out.
One perceived falsehood can undermine the credibility of everything else you do.
Oh, and one more little thing that drives me crazy, if in a press release, article, or whatever, you refer to another company by name, or one of their products – make sure you get the names right.
In this day and age, fact checking has never been easier, all it takes is a few clicks of the mouse.
There is no excuse for any marketing material not to tell the truth. Sure your readers may have to read between the lines, or decipher the spin, but the foundation of what you are saying should always be verifiable.
================================
* The misuse of the word “unique” is one of my all time pet-peeves. Every time my wife watches one of those house buying TV shows and I here the presenter talk about a “unique feature” that we’ve seen 100 times before, it makes me want to scream.
Monday, June 8, 2009
5 Ways to Make Executives Love the Publications Department
“Publications never gets any respect,” is a refrain I’ve heard over and over again during my time in the Technical Communications industry. In fact I’ve even said it myself a few times. The refrain is often followed by, “no one really understands what we do, or the value we provide.” The unfortunate thing is that in a lot of cases these refrains have some justification, but it needn’t be that way.
As an example over the years I’ve visited literally hundreds of publication teams in a variety of companies and industries, but one of my most striking memories is the sheer contrast between two publication departments at a couple of luxury car manufacturers.
At the first company, the documentation department had a nice modern office, in a new campus setting. They had all the latest computers and access to great technology. In the parking lot outside the publications office was a fleet of not only their own cars, but those of their nearest competitor. Any member of the publications team could use any of the cars, in exchange for filling in a small usability report. The publications team were a high profile part of the customer support organization and were considered by the marketing team as part of the product “life style” branding activities.
At the second company, the publications department was in an old hut (in fact it was an old coal bunker) at the back of the factory, far removed from the production line, engineering, or any other function it needed to interact with. Although cars were parked outside, the team had no access to them. They had only a handful of computers and their technology was at least five years behind their competitors. The sole mandate was to produce a small defined set of hardcopy manuals. And that’s all they did.
So why the difference? In short the team at the first company acted like they were part of the company and projected a positive image of their skills. As such they were recognized and rewarded. The team at the second company stuck to the “we are only tech writers,” approach. They were, in many ways, responsible for their own position.
So if you feel that your publications team is “in the coal bunker” – how do you change things so that you get the keys to the luxury cars?
The following presents a basic five point action plan to help you raise the profile of what you do and make your executives love the Publications Department.
1. Realize exactly what it is the Tech Doc team does. - Before you can raise your profile, you need to know what you have to offer. Chances are that most Publications teams have talents and skills that exist no where else in the organization, and I’m not just talking about the ability to write. Also most often the Publications team is the only place in a company where all the company’s intellectual property comes together. Publications isn’t about “producing user manuals,” it’s about managing your organization’s greatest asset - knowledge.
2. Tell a good story. – People react to stories on an instinctive level. It’s easier to remember stories than it is dry facts and figures. Publications is the natural bridge between the end user and the company design, engineering and production teams. Gather stories and tell them – repeatedly. Come up with your own stories that illustrate the importance, frequency and impact of your own work. Develop fun trivia about what Publications does that people will remember and repeat.
3. Offer your services for fun and profit – Develop an in-house user community, not just an external one. Look around for other functions that you could work with or offer your expertise to. Develop an entrepreneurial mind-set and you’ll find opportunities to transform publications from an overhead cost-center into a profitable contributor.
4. Hook an executive sponsor – Find an executive’s pet project that could need some creative input, e.g. a little wordsmithing, or some graphic design work, and get involved. While the work is progressing make sure to bring the executive into your environment, and show off what the publications team can achieve.
Over the coming weeks I’ll take a expand on each of these and provide some examples and suggested strategies.
Friday, April 24, 2009
2009 Conferences - Never mind the quantity, experience the quality.
In the current economic climate one of the first items that get cut in any budget squeeze is usually travel, and subsequent attendances at industry conferences. But, judging by my experiences at the two industry conferences I’ve attended so far this year, DocTrain West and WritersUA, this is a false economy. Yes attendance was down at both, due to aforementioned budget and travel restraints, but they were two of the best conferences I’ve attended in years.
Simply put, those people who were at the two events, were fully engaged in the conference. The conversations were compelling, interesting, relevant, and thought provoking. The speakers seemed to be of a higher quality and all the presentations were equally worthy of note and attention. The organizers of both conferences had put together excellent sessions with distinct themes. Most of the time I found myself attending one excellent session while at the same time wishing I could have been at a different concurrent session that sounded just as interesting. The most difficult aspect of these two conferences was scheduling your time.
Having spoken to several people who also attended either one, or in some cases both, of these conferences, it seems that I am not alone in these opinions.
So why in a time of economic belt-tightening are the conferences so much better?
Firstly I believe that the majority of people who at the conferences, speakers and attendees alike, most likely had to give a good justification for being there. While you should always have a good reason for attending any conference, having to justify the expense can be a great motivator and help you to determine a real need. Everyone who was there, was there to learn. And if I perceived one over riding sentiment from both conferences, it was that they were unparalleled opportunities to learn from industry experts and peers alike.
It was noticeable that attendance at sessions on the last day was just as high as those on the first day, and that conversations started over breakfast continued on into the evenings. Conference attendees put in much longer hours than they do in the office.
Secondly, the organizers and presenters have realized that sessions that are little more than thinly disguised marketing pitches very quickly lose you confidence and respect. The result is that most sessions today are highly focused on presenting real world results, or best practices based on experience.
Everyone I spoke to at both conferences also believed that by being in attendance they had given themselves, and their companies, a competitive advantage. Whether it was new technologies that they hadn’t considered before, like wikis; learning how to apply industry standards like DITA; or new techniques that could save time and money, such as the application of controlled languages, or a greater use of graphics; all had come away with something that more than justified the cost of attending.
In a couple of weeks I will be at the STC National Summit in Atlanta, and I will be interested to see if the trend towards increased quality and excellence continues.
[If you are at the STC Summit I'll be speaking on Tuesday 5th May at 1:30pm in the Hanover AB room, or you will be able to find me at Booth #109 for most of the show.]
NOTE: This blog entry was first published as part of my WebWorks blog
Simply put, those people who were at the two events, were fully engaged in the conference. The conversations were compelling, interesting, relevant, and thought provoking. The speakers seemed to be of a higher quality and all the presentations were equally worthy of note and attention. The organizers of both conferences had put together excellent sessions with distinct themes. Most of the time I found myself attending one excellent session while at the same time wishing I could have been at a different concurrent session that sounded just as interesting. The most difficult aspect of these two conferences was scheduling your time.
Having spoken to several people who also attended either one, or in some cases both, of these conferences, it seems that I am not alone in these opinions.
So why in a time of economic belt-tightening are the conferences so much better?
Firstly I believe that the majority of people who at the conferences, speakers and attendees alike, most likely had to give a good justification for being there. While you should always have a good reason for attending any conference, having to justify the expense can be a great motivator and help you to determine a real need. Everyone who was there, was there to learn. And if I perceived one over riding sentiment from both conferences, it was that they were unparalleled opportunities to learn from industry experts and peers alike.
It was noticeable that attendance at sessions on the last day was just as high as those on the first day, and that conversations started over breakfast continued on into the evenings. Conference attendees put in much longer hours than they do in the office.
Secondly, the organizers and presenters have realized that sessions that are little more than thinly disguised marketing pitches very quickly lose you confidence and respect. The result is that most sessions today are highly focused on presenting real world results, or best practices based on experience.
Everyone I spoke to at both conferences also believed that by being in attendance they had given themselves, and their companies, a competitive advantage. Whether it was new technologies that they hadn’t considered before, like wikis; learning how to apply industry standards like DITA; or new techniques that could save time and money, such as the application of controlled languages, or a greater use of graphics; all had come away with something that more than justified the cost of attending.
In a couple of weeks I will be at the STC National Summit in Atlanta, and I will be interested to see if the trend towards increased quality and excellence continues.
[If you are at the STC Summit I'll be speaking on Tuesday 5th May at 1:30pm in the Hanover AB room, or you will be able to find me at Booth #109 for most of the show.]
NOTE: This blog entry was first published as part of my WebWorks blog
Monday, April 20, 2009
The Future is Today
Back in December I posted an entry on this blog about how observing my daughter do a homework assignment had made me rethink the way we need to approach presenting information. In business we are still bound to the book paradigm that was created in the nineteenth century, and that we, as "adults," are more comfortable with because it's the way that we were taught to find and assimilate information.
My conclusion was that today's generation approaches information gathering and learning based on a different more chaotic model, where social interaction is more important than structure. In short to survive and prosper we should start designing information not for ourselves, but for the next generation.
Today I came across this video - which makes the point much better than I ever could - the video's focus may be education, but it applies just as well to the future of corporate communications.
My conclusion was that today's generation approaches information gathering and learning based on a different more chaotic model, where social interaction is more important than structure. In short to survive and prosper we should start designing information not for ourselves, but for the next generation.
Today I came across this video - which makes the point much better than I ever could - the video's focus may be education, but it applies just as well to the future of corporate communications.
Monday, April 13, 2009
Writing about Wiki - New Book Project
I mentioned this in passing on my Twitter account the other day, but as it was officially announced today, I thought I'd post a few more details.
WIKI: Grow Your Own for Fun and Profit
by Alan J. Porter
Looking for a way to increase team collaboration, manage your company’s knowledge? Do you need a way to manage projects with customers or suppliers outside your company firewall? Would you like your customers to provide feedback on the information you publish? Then a wiki might be just what you are looking for.
Perhaps you have already decided that you should use a wiki, but are not sure how to go about it. Maybe you have a wiki but would like to encourage more people to use it. Or you would just like to learn more about the practical applications for this fast growing technology.
Then this is the book for you.
WIKI: Grow Your Own for Fun and Profit will introduce the concept of wikis, and show why they are becoming the must-have communications and collaboration technology for businesses of any size.
The book will also include several case studies highlighting the ways that various companies are using wikis to solve differing business and communications issues, and the resulting benefits in terms of both efficiency and customer satisfaction.
WIKI: Grow Your Own for Fun and Profit will be available early next year, but we will keep you informed with excerpts and news along the way.
The official web site for the project is HERE, and it will be updated as the project progresses.
WIKI: Grow Your Own for Fun and Profit
by Alan J. Porter
Looking for a way to increase team collaboration, manage your company’s knowledge? Do you need a way to manage projects with customers or suppliers outside your company firewall? Would you like your customers to provide feedback on the information you publish? Then a wiki might be just what you are looking for.
Perhaps you have already decided that you should use a wiki, but are not sure how to go about it. Maybe you have a wiki but would like to encourage more people to use it. Or you would just like to learn more about the practical applications for this fast growing technology.
Then this is the book for you.
WIKI: Grow Your Own for Fun and Profit will introduce the concept of wikis, and show why they are becoming the must-have communications and collaboration technology for businesses of any size.
The book will also include several case studies highlighting the ways that various companies are using wikis to solve differing business and communications issues, and the resulting benefits in terms of both efficiency and customer satisfaction.
WIKI: Grow Your Own for Fun and Profit will be available early next year, but we will keep you informed with excerpts and news along the way.
The official web site for the project is HERE, and it will be updated as the project progresses.
Thursday, March 26, 2009
Why Technical Writers Shouldn't Be "Writers" - Slides
Technical writers love the written word. Perhaps, we love it a little too much? We need to ask ourselves is the written word the best thing for documentation? Is it the best thing for us as an industry, and is it the best thing for you as a content developer.
Over the last several months I've delivered a talk entitled Why Technical Writers Shouldn't Be "Writers" at several STC regional meetings and conferences (such as last week at DocTrain West)
The presentation was inspired by an earlier post on this blog, and takes a look at why we are so focused on the written word, and presents a few ideas about better ways for us to deliver our message to the end user in a way that increases customer satisfaction.
What can we as documentation professionals learn from just observing the world around us, and how people communicate? What is the impact of new Web2.0 technology and social networks, and how they will change the way we need to view documentation design, distribution and usage?
Several people have asked for copies of the slides I used, so here they are.
However the slides are not full of text and bulleted lists, in line with the central theme of the presentation, they are mainly graphics used to illustrate an idea or to serve as talking points. This is a "performance best seen live."
If anyone is interested in me delivering this presentation to their STC group, the writing team at their company, or a conference - then just send me an email, and let's chat.
Over the last several months I've delivered a talk entitled Why Technical Writers Shouldn't Be "Writers" at several STC regional meetings and conferences (such as last week at DocTrain West)
The presentation was inspired by an earlier post on this blog, and takes a look at why we are so focused on the written word, and presents a few ideas about better ways for us to deliver our message to the end user in a way that increases customer satisfaction.
What can we as documentation professionals learn from just observing the world around us, and how people communicate? What is the impact of new Web2.0 technology and social networks, and how they will change the way we need to view documentation design, distribution and usage?
Several people have asked for copies of the slides I used, so here they are.
However the slides are not full of text and bulleted lists, in line with the central theme of the presentation, they are mainly graphics used to illustrate an idea or to serve as talking points. This is a "performance best seen live."
If anyone is interested in me delivering this presentation to their STC group, the writing team at their company, or a conference - then just send me an email, and let's chat.
Why Technical Writers Shouldn't be "Writers"
View more presentations from 4JsGroup.
Friday, March 6, 2009
Should Customers Pay for the Manual?
Yesterday a friend of mine posted the following on his Twitter feed
OMG! (Company Name) actually charges for their owner's manuals! That's absurd.
Absurd? Really? Is that the common expectation - that all the manuals associated with a product should be "free"?
Over the years I have, at different times, worked with two companies that have almost directly identical competing product lines. In general they each have around 50% of their given market (although actual market leadership tends to fluctuate between them on a year to year basis). Yet they have two diametrically opposed philosophies when it comes to supplying documentation.
Company A has the philosophy that when you buy their product you get everything included to run, maintain and operate it (but not to repair it) so they include the cost of producing the documentation in their product pricing. They make their money on spare parts.
Company B has the philosophy that when you buy their product, you just buy the product and then pay extra for the bits and services you need, as you need them, so they have a lower product price and charge for their documentation (and their spares too).
The total cost of ownership for both products over the normal operating span turns out to be just about the same.
Let's take a look at the two scenarios in more detail.
COMPANY A - Documentation Included
This is perhaps considered the more traditional model. A content development team writes the various manuals , help sets etc. and publishes a complete suite of documentation. The whole suite is then delivered with the product. That suite can range from one small manual to literally (in the case of an aircraft) hundreds of large volumes. The cost of producing those manuals is covered in the product cost, and the customer perceives them as being "free."
That's how it should be. I've been amazed at the number of times that I've done consulting work for companies that don't even consider the cost of the documentation. They don't calculate it, they don't consider it a development cost and they don't cover it in the price of their products. Often companies like that consider documentation to be "a necessary evil" (a phrase I have heard more than once) and an uncontrolled overhead. As a result the content development is not considered an integral part of the design and production process and is poorly funded (if at all). The result is usually poor quality documentation. As a general rule of thumb, if you buy a low commodity priced product and it includes "everything," then there is a fair chance that the manuals will be next to useless. (I know this is a broad stroke statement, and there are always exceptions to it).
COMPANY B - Documentation Sold Separately
In this scenario the cost of producing and distributing the product documentation is usually well understood and managed. Most products in this case will ship with a small "free" documentation set that covers the basics of getting started, and simple opertaion (like the books in you car's glove box for instance) with the expectation that if customers want to know more they are prepared to spend money. Again think of the car analogy - most people who want to maintain and repair their own cars will go and buy a book on how to do it. There are whole companies who write and sell sepcialist manuals for car dealers and repair shops. The vast majority of customers will never access a full documentation suite, so why provide it to everyone? The manufacturer can focus on producing the documentation that 80% of its customers need, and the other 20% can be covered by a recognizable revenue stream from selling the specialist manuals.
One area of opportunity where I believe that the "pay as you need it" model breaks down is that currently most manuals you pay for (including the one that my friend was complaining about) are PDFs of traditional print manuals. You still end up buying the complete book even if you only want one or two sections of it. - If you have a pay to download the manual model, why not publish it based on topics (DITA?) and use a system of micro-payments. Instead of asking customers to pay $10 (the amount that outraged my friend), $15, or $20 - why not charge $0.99 a topic?
So which one is the right approach? I think they both are. Whether or not you charge for documentation is a product of many factors such as the business plan, the content development team's role in your organization, customer expectations, etc - but one underlying thing that applies is that the cost of documentation development should be correctly calculated and factored into the product development costs. You need to recoup that costs somewhere - it just becomes a matter of deciding where in the product life cycle and how.
BUT... if I had to favor one, I'd say go the separate charge route. - it gives more flexibility for delivery, it gives the customer choice, it lowers product prices, and it turns the content development team from being an overhead into a profit center.
On a personal note, when I switched one documentation department from being an overhead to being a revenue generator it completely changed the way the role of documentation, and the people who produced it, was perceived.
And the customers liked it too.
OMG! (Company Name) actually charges for their owner's manuals! That's absurd.
Absurd? Really? Is that the common expectation - that all the manuals associated with a product should be "free"?
Over the years I have, at different times, worked with two companies that have almost directly identical competing product lines. In general they each have around 50% of their given market (although actual market leadership tends to fluctuate between them on a year to year basis). Yet they have two diametrically opposed philosophies when it comes to supplying documentation.
Company A has the philosophy that when you buy their product you get everything included to run, maintain and operate it (but not to repair it) so they include the cost of producing the documentation in their product pricing. They make their money on spare parts.
Company B has the philosophy that when you buy their product, you just buy the product and then pay extra for the bits and services you need, as you need them, so they have a lower product price and charge for their documentation (and their spares too).
The total cost of ownership for both products over the normal operating span turns out to be just about the same.
Let's take a look at the two scenarios in more detail.
COMPANY A - Documentation Included
This is perhaps considered the more traditional model. A content development team writes the various manuals , help sets etc. and publishes a complete suite of documentation. The whole suite is then delivered with the product. That suite can range from one small manual to literally (in the case of an aircraft) hundreds of large volumes. The cost of producing those manuals is covered in the product cost, and the customer perceives them as being "free."
That's how it should be. I've been amazed at the number of times that I've done consulting work for companies that don't even consider the cost of the documentation. They don't calculate it, they don't consider it a development cost and they don't cover it in the price of their products. Often companies like that consider documentation to be "a necessary evil" (a phrase I have heard more than once) and an uncontrolled overhead. As a result the content development is not considered an integral part of the design and production process and is poorly funded (if at all). The result is usually poor quality documentation. As a general rule of thumb, if you buy a low commodity priced product and it includes "everything," then there is a fair chance that the manuals will be next to useless. (I know this is a broad stroke statement, and there are always exceptions to it).
COMPANY B - Documentation Sold Separately
In this scenario the cost of producing and distributing the product documentation is usually well understood and managed. Most products in this case will ship with a small "free" documentation set that covers the basics of getting started, and simple opertaion (like the books in you car's glove box for instance) with the expectation that if customers want to know more they are prepared to spend money. Again think of the car analogy - most people who want to maintain and repair their own cars will go and buy a book on how to do it. There are whole companies who write and sell sepcialist manuals for car dealers and repair shops. The vast majority of customers will never access a full documentation suite, so why provide it to everyone? The manufacturer can focus on producing the documentation that 80% of its customers need, and the other 20% can be covered by a recognizable revenue stream from selling the specialist manuals.
One area of opportunity where I believe that the "pay as you need it" model breaks down is that currently most manuals you pay for (including the one that my friend was complaining about) are PDFs of traditional print manuals. You still end up buying the complete book even if you only want one or two sections of it. - If you have a pay to download the manual model, why not publish it based on topics (DITA?) and use a system of micro-payments. Instead of asking customers to pay $10 (the amount that outraged my friend), $15, or $20 - why not charge $0.99 a topic?
So which one is the right approach? I think they both are. Whether or not you charge for documentation is a product of many factors such as the business plan, the content development team's role in your organization, customer expectations, etc - but one underlying thing that applies is that the cost of documentation development should be correctly calculated and factored into the product development costs. You need to recoup that costs somewhere - it just becomes a matter of deciding where in the product life cycle and how.
BUT... if I had to favor one, I'd say go the separate charge route. - it gives more flexibility for delivery, it gives the customer choice, it lowers product prices, and it turns the content development team from being an overhead into a profit center.
On a personal note, when I switched one documentation department from being an overhead to being a revenue generator it completely changed the way the role of documentation, and the people who produced it, was perceived.
And the customers liked it too.
Subscribe to:
Posts (Atom)
