Alan Pringle: Welcome to the Content Strategy Experts podcast brought to you by Scriptorium. Since 1997 Scriptorium has helped companies manage, structure, organize and distribute content in an efficient way. In episode 25 we begin an occasional series on content strategy pitfalls. What are the traps, snares and dangers that the intrepid content strategist will encounter? What’s the best way to avoid danger, injury and even project death? In this episode we’ll focus on software and tool problems.
Alan: Hi everyone, I’m Alan Pringle, I am COO at Scriptorium Publishing and today I have Bill Swallow and Sarah O’Keefe with me.
Bill Swallow: Hello.
Sarah O’Keefe: Hello.
Alan: Hey there. Today we are going to talk about, well we’re going to start a discussion actually and I’m hoping it’s going to turn into a series on content strategy pitfalls. What are the things that you need to be looking out for when you are considering and even implementing a content strategy project? The first aspect of these pitfalls that we wanted to talk about were tools and software. What are the kind of challenges and problems that you may face when you are selecting tools, implementing tools as part of a content strategy? Oftentimes people will buy a tool and assume that the strategy will just take care of itself. But why is that a bad assumption? Bill you have some thoughts on that?
Bill: Yeah, well one tools don’t take into account specific needs. They take into account rather general needs to satisfy a wide variety of customers. So a lot of times although you might have features in place they may not necessarily be tailored to exactly what your specific needs are. For example, you may have a need to target content to various different audiences. But your tool may not out of the gate be able to flag every single one of those audiences on their own. You may have very specific types of audiences that you need to address where they may have a more general list that you may or may not be able to easily adapt.
Sarah: And I think it’s actually worse than that because if you go out and you buy a tool first and I understand that it’s tempting because the tools are so nice and concrete and they promise to solve all your problems and they’re going to be awesome and it’s just going to be fantastic and the sun is shining and there will be unicorns. But what actually happens is when you buy a tool, you’ve put yourself inside the box of what that specific tool is capable of doing and doing well. The burning question is, is the strategy that you need to put in place in your organization, does it fall inside that box? If you haven’t done the work to think about what’s my strategy? What am I trying to accomplish? The types of things that you’re talking about Bill, what kinds of variants do I need? Or what kind of complex deliverables do I need? Or what does my authoring look like? If the tool that you’ve already purchased doesn’t accommodate those things then you’ve got a big problem.
Alan: So you really need to look at requirements. It’s not that much different than say drawing up specs for a product, hardware, software. You need to figure out what are things that you actually need. What you want this system or tool to do? List those things out and see if the contenders stack up against that list of requirements.
Sarah: Yeah, and that’s a good example if you talk about any product of any product development or software development. Once you pick a programming language, there’s things that language does well and things it does not so well. So that puts you in a specific kind of box for how you’re going to do your programming. Or if you pick a certain kind of database structure. There are all these things that are essentially constraints on the tools that you choose so when you choose an authoring workflow, a publishing workflow, a storage system, then that shapes what you’re going to be able to do with those tools. Now you might look at the case studies on a website and say, “Hey this tool has case studies that really resemble what I’m trying to do so it might be sensible to just go for that tool.” But if you’re not sure, if you’re not sure what you need to accomplish and what your requirements are and what your goals are then how can you possibly choose the right tool?
Bill: Right. And those case studies generally won’t get into the nitty gritty of exactly what the situation was before implementing that tool. So you may have on its face a very similar situation but when you get down into the weeds of what you’re existing situation is and where you ultimately need to be, those fine details might be very different.
Alan: Yeah, I think case studies can be very helpful to put you in the general ballpark but you should not rely upon them as to be the end all be all to find a perfect system for you because like you’re saying, your requirements may be completely different at a very molecular level. When you really start getting into the details versus what the original case study, what their problem was. And a lot time those case studies can be a little flashy and glossy too and kind of seductive. They draw you in. But you do need to look really deeper under the covers to figure out if it is indeed a good fit for you.
Sarah: Yeah. I think that the strategy that we’ve used to deal with this is to do very specific… partly requirements but also these use case scenarios where you say, “Here is the type of thing that we need to do. This is what our review workflow looks like. This is what our publishing requirements look like. These are the kinds of connections that we need to make amongst the content and the data.” Write those out pretty specifically and then talk to the tool vendors and say, “Can you meet these requirements? What does this use case look like in your system?” And you can learn awful lot from a vendor doing a demo showing you how they would implement a complex variants in their system. Do they do it easily? Or does it look kind of weird and wacky and twisty? That tells you right off the bat that might not work well in their system but you have to… you can’t just go to them and say, “Can you do variants?” Because they’re going to say, “Yes, we’re awesome at variants.”
Alan: But you have to do it their way which may not be a good fit for your way.
Sarah: But can you do these kinds of variants? Can you do this intersection of variants? Can you handle variants when they are done in this way? Because the answer to must do variants is always going to be, “Yes, of course.” That’s like saying, “Must do version control.” Most, all of your CCMSs and going to say, “Yes we can do version control, check that off.” Your goal with requirements is to develop requirements that actually do differentiate. That are specific enough that you can look at a tool and say, “That’s not actually going to work. It doesn’t do it the way we need it to.”
Alan: You don’t want to present requirements as a list of binary yes no kinds of things. You want use cases kind of like Sarah’s been talking about where you say, “Here is an example.” And you have a little story essentially and you say to the vendors, “How does your system or tool support this particular story, this use case?” And then that way it forces them to do a demo to show you exactly how it’s going to support your strategy’s requirements.
Sarah: Yeah, “We have lots and lots of authors that are going to be creating content that are non-experts. Show me what it looks like to work in your authoring interface.” That kind of thing. And to be clear, that doesn’t, if the tool’s not a fit, that doesn’t make it a bad tool, it just makes it a bad fit for that project.
Alan: Right, right. I think a lot of times what is considered a good fit can be colored by people’s preconceptions or likes and dislikes of certain kinds of tools and you get from being objective to a more subjective point of view and I want to talk about that challenge a little bit because people’s perceptions of a tool and past experiences can color an evaluation of tools in both positive and negatives ways I think.
Bill: One of the big ones is what I think is people being hung up on WYSIWYG authoring. In that they like a particular tool because it allows them to actually see what they’re producing in a particular format. But you run into problems especially if you have multiple formats that you need to address. And if you’re spending all of your time tailoring content to whatever the WYSIWYG looks like on the authoring side, you’re potentially not addressing all of the needs of the various outputs that you might have on the other side.
Sarah: Yeah, now we hear a lot of, “Well, we’re going to mobile first.” Okay, fine but is that the only deliverable? Are there other deliverables? Are there other formats? Are there other screens that people are going to be looking at your stuff on and can we support those as well?
Alan: And something that hasn’t even been created yet. How extensible is this system or tool? How will it help you five years down the road to support some kind of display for example you don’t even know exists right now? Those are the kinds of questions you also need to find out. How flexible and extensible is that tool going to be? Especially when you’re doing a huge shift from say more of print PDF world to an online mobile world. And I think too, it’s very easy to get hung up in this loop. “I’m an expert in this tool because I’ve used it for 10 years and know all the ins and outs. I’m a power user. I really have that depth of knowledge and I don’t want to give that up to use another tool even though it may be a better fit for the company overall.” So there’s this whole fight, or—I don’t know if fight’s the right word—but there’s this tension between what’s good for the company and then the individual content contributor system admins or whatever who are not comfortable with the idea of changing.
Sarah: “You’ll pry this tool from my cold, dead hands.” I’m afraid all of us have said that at one point or another. What it means really is I’m productive in this tool, I know how to use it, I went through the learning curve, I’m not in the mood to go through the learning curve again for a different tool. And that’s actually reasonable. To say, “I’m very, very productive and I’ve got a lot of work and I can get that work done very efficiently in tool X.” Is a fair statement.
Sarah: But the question is, is there another tool out there that is a better fit for the company’s current requirements and is it worth the pain that you as the expert will suffer in moving from being expert on tool X to beginner on tool Y? But then you’ll come up to speed on tool Y and at that point are you going to be in a better situation for the content that you’re creating? If the answer is yes, you should probably make the shift. If the answer is no, “It’s just a stupid new tool, doesn’t really buy me anything,” then okay, yeah, I agree, stay with the old one.
Alan: It’s also easy to think, oh everybody’s moving to this particular tool or this way of doing things, I have to do it too. Doesn’t make sense to go through all those painful changes if you don’t have a good business for your own company to do that. “I’m going to go use this XML standard because all the cool kids are doing it.” That is not a business case. Not remotely.
Sarah: Yeah, and tied to your point about I like my current tool, there’s also in evaluating this stuff you see this sort of mentality of, “If it doesn’t have this feature that my current tool has, I refuse to consider it.” Well is that an important feature? I know you like the feature, but is it important?
Bill: Right. And is there a comparable feature that maybe does something slightly differently?
Alan: Right. There are a lot of cases where you can adapt your skills or your way of thinking and say, “Oh, this tool does it this way but it’s the same kind of principle.” So it’s kind of like a mapping thing that you have to do mentally. I’m not going to say that’s easy, we all have muscle memory in regard to our tools. There’s certain keystrokes with a certain desktop publishing tool I will not name, to this day they still pop into my head. I understand the whole muscle memory problem and not wanting to change. But you can’t, you cannot let your personal likes and dislikes in your skillset drive your company’s content strategy. It is the company’s content strategy not your personal content strategy.
Sarah: Yeah. It’s totally fair to say, “Hey that new thing that we’re looking at doesn’t actually do what we need it to.” But now we’re back to requirements. Okay, so you have a requirement to do like you said, mobile content. And oh this tool that you’re looking at doesn’t actually do that. Maybe we should rule it out. But that’s totally different from uncomfortable and I don’t want to make a change.
Alan: Yeah, so whatever tool you’re using now it can very easy to use it as the benchmark for your requirements but you can’t do that. You can say, “Yeah it does things well in this particular arena but is that as important moving forward?” You can’t always assume the way you’ve done things with that current tool is how it’s going to be moving forward. So you have to be really careful with those comparisons and the benchmarking when you’re coming up with your new systems requirements.
Bill: Right. And it’s important to have those requirements be pretty solid and pretty detailed as well because then you also run the risk of putting together some high level requirements that say, “Hey, we need a component content management system to manage our content better.” And then you could be faced with pushback from management or IT saying, “Well we already have a tool that does that. We have this web CMS or we have SharePoint or we have this other tool, why can’t you just use that?”
Alan: Right. And that’s a very important point. We’re not talking… it’s not just necessarily personal likes and dislikes of content creators. Not necessarily. Even though content creators are often the focus of these tools, you’ve got to look at the people behind the scenes. You’re right Bill, management, IT. They are also going to have very specific reasons why certain systems can’t be supported. And one I can think of in particular in regard to IT, sometimes companies do not like using hosted tools, sometimes they prefer on premise installed tools for security reasons for example.
Sarah: Sometimes vice versa.
Alan: And vice versa too. Sometimes you don’t, an IT department simply does not have the bandwidth, the resources to help you set up a content management system or whatever content tool you’re talking about. So you’ve got to be sure that you know what the IT department can and cannot do, will and will not support. It’s just not a matter of, “Yeah, this works for us as content creators.” What about behind the scenes? The people that are going to have to support and maintain the tool… What can they and what can they not do in regard to selecting and maintaining those tools?
Sarah: Yeah, and I think that’s really one of the biggest headaches is that the document management systems that tend to be put in place by IT don’t do component content management and explaining why those things are different, why they are not the same and why the in place enterprise content management system is not in fact the same thing as the component content management system. We’re four letter into the acronym. That is way down in the weeds and it really, really annoys the enterprise IT architecture people. And I don’t blame them because they’re saying, “Guys, we have like four content management systems, what is your problem?” “Well, we’re special. We need another one and this is why.” That’s a hard conversation.
Alan: Especially when you already have three systems in house, like you said.
Sarah: Yeah, and their job is to… From an IT point of view, every new system that you introduce introduces cost and maintenance and overhead.
Sarah: Connectivity problems and risk, absolutely. So you have to if you’re going to try and justify it, you have to justify it on the grounds that it provides value that you can’t get out of the other systems.
Alan: Absolutely. And to touch back on the risk thing, part of any kind of tool assessment from my point of view should include an exit strategy. Just because you’re thinking about moving it to a new tool doesn’t mean you have to think about importing and converting. You need to think about the back end five, 10 years down the road. How are you going to switch tools after you move into the new one? That should always be in the back of your head. And that is a risk and a pitfall I think people really overlook and too often.
Bill: If I buy a cookie jar, I’d better well be able to grab a cookie out of that jar.
Sarah O’Keefe: And refill it.
Alan: Or glue the lid down so I can’t get to it at all. That’s my problem. Anyways, so much about cookies. Before we wrap up though, I also want to talk about vendors and working with vendors a little bit and the tool vendors and assessing what they say their tools can and cannot do and would like to get input from both of you on that. Because I certainly have some opinions on the subject.
Bill: We talked a little bit about that already when you’re asking for demos and such, you should have your own user stories ready for them to address ahead of time so they can plan and actually show you how that would work in their system. But a lot of it comes down to not being, don’t just take their word for what the system can and can’t do. If there’s ever a question or if there’s a high level need that they gloss over with, “Yes our system supports that completely.” Have them show you how it works.
Sarah: A long time ago, I learned from somebody that the best definition of marketing is that marketing is the process of framing the question in such a way that your product—the thing you’re selling—is the only possible answer. If you’re a buyer then your job is to watch for that framing and avoid it. And make sure that you’re asking the right questions. You’re not asking the question in such a way that the answer is framed to favor a particular product or a particular vendor. You want to ask the question that you actually need to ask. One of the most common things—this isn’t just marketing; this is marketing and politics and everything else—is that you ask one question and the person selling to you and trying to get your vote, actually answers a different question. Again, pay attention to what your requirements are and make sure that you’re asking the right questions of the vendor and getting those questions answered.
Alan: Right. And I’ve mentioned this several times in presentations and different speaking engagements and maybe even this podcast… if you ever feel kind of uncomfortable about what you’re hearing when you’re talking to vendor and what they’re telling you about what their product can do, why are you going to give them money? There’s a very good likelihood if you’re kind of uncomfortable during the sales process, you’re going to be probably uncomfortable after they’ve got your money. They probably maybe do not fully support what you need. Kind of pay attention to what your gut tells you because sometimes that can be a very good barometer of the situation when you’re dealing with vendors and their claims.
Sarah: I guess the flip side of that is, if you find a vendor who does answer your questions and does work with you and does pay attention there’s a lot of value in somebody that will actually work with you and will support you and provide the customer support and all the rest of it. Kind of flipping that around into the positive, it’s important to find, especially for the kinds of tools that we’re talking about, it’s important to find a vendor that you can work with. That you can work well with and have good working relationship with.
Alan: You start that relationship in the sales process, during discovery. I agree with that. Notice how she turns things on the positive side and I tend not to do that. I’m good at the negative side. I excel at that.
Sarah O’Keefe: I got positive side today.
Alan: Well I think we’re about out of time so I want to wrap up but before I do, I do want to kind of ask our audience, if there are other kinds of areas where you have concerns about content strategy, where you’ve run up against challenges of falling into a pitfall, let us know those kinds of general subject areas. We would love to talk about it and a later podcast. Do drop us a line. If you’re looking on our website you can do it through our contact form or you can drop us an email at email@example.com. And with that I want to wrap up and thank you Bill and Sarah for talking with us today.
Bill: Thank you.
Alan: Thank you for listening to the Content Strategy Experts podcast brought to you by Scriptorium. For more information, please visit scriptorium.com or check the show notes for relevant links.