Content classification and findability no image

Published on October 23rd, 2009 | by Rahel Bailie

6

Naming the “other” type of content strategy

    A while back, I started a thread on the STC Content Strategy SIG to get some consensus around what to call “our” type of content strategy. This was in response to having a couple of content strategy books in the marketplace that don’t really cover the breadth and depth of what we do for our clients and organizations.

    The issue with “Content strategy for the Web” is that for me, the Web a single output format.  What happens when I put the some content out on the Web, and send it to Training to incorporate into their training materials, and share it with the Customer Support group, so they can incorporate it into the knowledge base for service reps, and send it out to a PDF so it can be printed as a manual? My mandate is obviously bigger than “the Web,” but more importantly, the framing shouldn’t be by output channel.

    While the term “content strategy for the Web” doesn’t say this explicitly, there are several implicit connotations: the content is marketing content, and the Web is where content consumers go to read it. The differences between content for the [marketing] Web and [marketing] print material has to do with length, look, keywords, search engine optimization, and so on.

    Ann Rockley gave her earlier book, Managing Enterprise Content, the subtitle of “a unified content strategy” but the concept of “unified” is not well understood by our audiences. Unifying what and what:  Web and not-Web? Marketing and technical? When the questions I get asked start with “what do you mean by the word content?” the whole idea of unification becomes a hurdle that sometimes my audiences never get to. The type of content strategy I provide isn’t the normal definition of enterprise-wide. It doesn’t include email and ediscovery, or records management for HR, or ERP data, or any of the stuff that information-management gurus look at as enterprise content management.

    Yet we know that the power to name what we do can define expectations – not to mention make search terms so much more effective! So what do we do? In an effort to frame our focus, I looked at our activities, deliverables, and scope of content, and realized that there are a couple of basic common denominators:

  • The content is on the critical path. We’re not talking about email or HR records. We’re talking critical-path product content. The content is related to the product being sold or service being provided. This means product content that gets used in multiple contexts: technical documentation, training, and customer support, and marketing, as well as content that gets turned into product content, such as engineering specifications, product-related user-generated content, and content used in a social media context.
  • The content either supports pre-sales purchasing decisions, or it supports the post-sales relationship between you and your customers. The content may not always be customer-facing, but it is used to build the customer relationship. Why both of these stages are important is because the pre-sales stage is like dating; and the post-sales stage is like marriage. Consumers, and perhaps more importantly, industry analysts, look to see what the relationship will be like once you’re hitched, and they do that during the dating stage. So the content we’re concerned with is, essentially, relationship content.

Joe Gollner calls it “content in the context of forming persistent business relationships.” I like this definition because it defines the content by its function rather than by its output mechanism. However, someone might posit that email exchanges between staff and customers also serve the purpose of forming or maintain persistent business relationships.

I then (re)turned to Karen Donoghue’s book, Built for Use: Driving Profitability Through the User Experience, wherein she makes it clear that every successful transaction that a user has with a website has the effect of taking a step closer to a trust relationship; every unsuccessful transaction send the user a step (or two or ten steps) away from that relationship, and in some cases, irreparably damages the relationship.

Given that part of my mantra is cross-silo consistency – your content should be consistent on your site, in your print documents, in your PDFs, on your product packaging, in your service agreements, in the software interface, and wherever else it appears, AND throughout the entire lifecycle of the content – then the logical conclusion I draw is to connect my type of content strategy to the user experience. User experience helps form and retain persistent business relationships; content is a critical component of a user experience.

Then, do I call this user relationship content? I can just see the look on the face of an executive as he mutters something under his breath to the effect that his company doesn’t have a dating site. As a good content strategist, I realize the importance of crafting content to be effective for my audience. So who is my audience: the practitioners who want a technically accurate description of the craft, or the decisions-makers who are potential clients for my services?

In this case, I have to admit that I’m leaning toward a client audience, and hence the designation of content strategies for the product life cycle. Product life cycle is a term that resonates with product managers, program managers, and other mid-level to executive-level management, and all the content related to the product lifecycle – soup to nuts, so to speak, of the content lifecycle – is what is at stake in my type of content strategy. When I use this phrase to describe this to potential project sponsors, will they understand it? Will we do our field of practice justice by calling my work product life cycle content strategies? Let the debate begin!


Share this post:
These icons link to social bookmarking sites where readers can share and discover new web pages.

  • del.icio.us
  • StumbleUpon
  • email
  • Facebook
  • LinkedIn
  • TwitThis


About the Author

Rahel Anne Bailie is a synthesizer of content strategy, requirements analysis, information architecture, and content management to increase the ROI of content. She has consulted for clients in a range of industries, and on several continents, whose aim is to better leverage their content as business assets. Founder of Intentional Design, she is now the Chief Knowledge Officer of London-based Scroll. She is a Fellow of the Society for Technical Communication, she has worked in the content business for over two decades. She is co-author of Content Strategy: Connecting the dots between business, brand, and benefits, and co-editor of The Language of Content Strategy, and is working on her third content strategy book,



6 Responses to Naming the “other” type of content strategy

  1. We seem to have an obsession with chopping up our knowledge work by artifact, unceremoniously cleaving through any connections which may occur betwixt.

    I wonder how much it matters as well to separate the content into that which is expository, or rhetorical, or written with enterprise buyers in mind, or implementers, or end users. I wonder also how much it makes sense to delineate heavily between documents and structured data.

    When we go to author a document, we typically begin with a blank screen. We rely on external sources (read: meatware) to inform us of elements like our intended audiences and metadata (meat-data?). But, for instance, when we write anything affirmative, we’re either stating a fact or making an assertion (hopefully based on facts), which tend to arrange into a well-defined data structure, otherwise known as structured argumentation. I often wonder why the mainstream seems largely blind to the notion that computers can actually be doing this work for us.

    For all our wealth of information management tools, in my opinion they and their contents are still treated as disparate entities. What I’d like to see is a type of unified model that will enable people within an organization to connect and manipulate all types of information, from data to content to controls.

  2. “Content lifecycle” is appropriate term for an ambitious idea. It’s not only about the content, but also about guiding the many hands and heads that touch (re-use/re-purpose) the content.

    If you’re in a corporate environment where they’re doing content management right—meaning they have dedicated people to identify and manage the content as well as train and manage the people who re-use/repurpose the content—then they already have the dedicated people who can take the next step toward content-lifecycle management.

    Imagine the benefits of consistent, re-purposed content across your site, print docs, PDFs, packaging, service agreements, software interface (I think this may be the most difficult one), and wherever else it appears, throughout the entire lifecycle of the content. Well, I guess you have imagined it, which is why you’re proposing this definition.

  3. Tom Johnson says:

    I find your term “relationship content” an interesting way of looking at the content. You’re right that much of the content is responsible for the relationship that we’re creating with the customer, yet proj. mgrs rarely look at help material this way. I like that perspective, rather than just analyzing content for brand and messaging.

    Your mantra of “cross-silo consistency” is also intriguing. I realize that this is the backbone behind content strategy (or at least a major part of it). In my own job, though, silos and communication walls between depts are ever-present. I’m not sure how one breaks down these walls and ensures consistency or even ensures relationships, but it’s a good goal to have. Part of the problem is that there isn’t any one single person in charge of all the content (unlike what Halverson recommends).

    Your post prompted me to push for a wiki version of help I’m creating simply because the message a wiki sends may build more of a trust relationship than static content.

  4. seamus walsh says:

    Ann Rockley got it right, albeit backwards with “Managing Enterprise Content,” I think if she led with “A unified content strategy” this discussion would be past tense.

    You mention content needs to be on a critical path, but in your example, exclude HR: For B2B, HR is on the critical path, a person’s subject matter expertise needs to be inventoried in case they need to be part of a sales process, or perhaps, excess absenteeism due to the xy2 flu rendered work in process to a snails pace at your shop in AZ. How does that effect customer orders?

    You too end up cross-siloing and segmenting content towards a client audience. I think for B2B, for content to be unified it has to, has to, has to follow critical path.

    For this discussion, the art of UX does not apply, but the science of content should have rules. Before we get into the debate of the other content, do you want unified content?

  5. Rahel Bailie says:

    Seamus, while I think you’ve got some good points in here, and I think that Ann Rockley did hit it right on the head (though in her book, there is no mention of HR records or email management) but I think this has gone off on a tangent. I’ve never seen an RFP looking for a “unified content strategy” – that doesn’t resonate with clients – and in smaller companies, there is no need for automated management of, say, HR records. There could be 20 developers and a couple of support staff, yet they pump out a complex product with lots of pages of product-related content, and it’s the product-related content that the customers care about.

    My concern is that if we continue to bury product lifecycle content under “enterprise,” it will never get the attention it deserves because historical we’ve seen how that goes, and if we lump it in with “Web,” we lose the multi-channel publishing aspect, where the corporate website is a single aspect of three or four output channels. Content at the output stage does need to be segmented – different audiences have different needs. But that content should come from a single source and be consistent across the output channels, whether that output channel is documentation, training, or text strings in the software.

  6. Joe Gollner says:

    Product Life Cycle is a phrase that resonates with me although it does so in a way that takes me very much done the “enterprise content management” path – writ large. Having just returned from the S1000D User Forum (product life cycle management for very large things – think ships and other more menacing systems), product life cycle content becomes about as technical, as heavy-wieght and as unwieldly as can be imagined.

    Now this is not such a bad association in that it stresses that all aspects of the content life cycle are interconnected. The user experience becomes a problem report that feeds into an engineering change that becomes a work order that is implemented over a period of years across an unfathomably large fleet of deployed systems…. In all such scenarios, the user experience can ultimately entail things like the emails exchanged, chat transcripts, voice messages and so on. And you can feel the weight of “records management” breathing down your neck as you realize that these transactions come with potential legal liabilities – sometimes small and sometimes not so small.

    So now that I have shaken the hornet’s nest a little, I will say that there are at least a couple of key perspectives on content and that these perspectives, however interconnected ultimately, do align with domains of responsibility and expertise that tend to make us package them as different or special.

    I think that one of these perspectives is the user experience of the content. This is not an area where I normally operate although I recognize the contributions of those who do and admire their unique skills. Perhaps we could call this domain “Integrated Content User Experience” or ICU Experience, or slightly less attractively ICUX.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Back to Top ↑