Tool or trap? Find the problem, then the platform

Tempted to jump straight to a new tool to solve your content problems? In this episode, Alan Pringle and Bill Swallow share real-world stories that show how premature solutioning without proper analysis can lead to costly misalignment, poor adoption, and missed opportunities for company-wide operational improvement.

Bill Swallow: On paper, it looked like a perfect solution. But everyone, including the people who greenlit the project, hated it. Absolutely hated it. Why? It was difficult to use, very slow, and very buggy. Sometimes it would crash and leave processes running, so you couldn’t relaunch it. There was no easy way to use it. So everyone bypassed using it at every opportunity.

Alan Pringle: It sounds to me like there was a bit of a fixation. This product checked all the boxes without actually doing any in-depth analysis of what was needed, much less actually thinking about what users needed and how that product could fill those needs.

Related links:

• How humans drive content operations (recorded webinar & transcript)
• Brewing a better content strategy through single sourcing (podcast)
• The Scriptorium approach to content strategy
• Get monthly insights on structured content, futureproof content operations, and more with our Illuminations newsletter

LinkedIn:

• Alan Pringle
• Bill Swallow

Transcript:

Introduction with ambient background music

Christine Cuellar: From Scriptorium, this is Content Operations, a show that delivers industry-leading insights for global organizations.

Bill Swallow: In the end, you have a unified experience so that people aren’t relearning how to engage with your content in every context you produce it.

Sarah O’Keefe: Change is perceived as being risky, you have to convince me that making the change is less risky than not making the change.

Alan Pringle: And at some point, you are going to have tools, technology, and process that no longer support your needs, so if you think about that ahead of time, you’re going to be much better off.

End of introduction

Bill Swallow: Hi, I’m Bill Swallow

Alan Pringle: And I’m Alan Pringle.

BS: And in this episode we’re going to talk about the pitfalls of putting solutioning before doing proper analysis. And Alan, I’m going to kick this right off to you. Why should you not put solutioning before doing proper analysis?

AP: Well, it’s very shortsighted and oftentimes it means you’re not going to get the funding that you need to do the project to solve the problems that you have. And with that, we can wrap this podcast up because there’s not a whole lot more to talk about here, really. But no, seriously, we do need to dive into this. It is very easy to fall into the trap of taking a tool’s first point of view. You’ve got a problem, it’s really weighing on you. So it’s not unusual for a mind to go, this tool will fix this problem, but it’s really not the way to go. You need to go back many steps, shut that part of your brain off and start doing analysis. And Bill, you’ve got an example, I believe, of how taking a tool’s first point of view didn’t help back in a previous job you had.

BS: I do, and I’m not going to bury the lead here, but they didn’t do their homework upfront to see how people would use the system. So I worked for a company many, many, many years ago that decided to roll out and I will name the product. They rolled out Lotus Notes.

AP: You’re killing me. That’s also very old, but we won’t discuss that angle.

BS: But they did so because it checked every single box, every single box on the needs list, it did email, it had calendar entries, it did messaging, notes, documents, linking, sharing, robust permissions, and you even had the ability to create mini portals for different departments and projects. So on paper, it looked like a perfect solution. And everyone, including the people who greenlit the implementation of Lotus Notes, hated it. Absolutely hated it. Why did they hate it? It was difficult to use. It was very slow. It was very buggy. Sometimes it would crash and leave processes running, so you couldn’t relaunch it. There was no easy way to use it. Back at that point, we had PDAs, personal digital assistants, and very soon after that we had the birth of the smartphone. There was no easy way to use it in these mobile devices except for maybe hooking up to email. It didn’t fit how we were working at all. While it shouldn’t count, it really wasn’t very pretty to look at either. So everyone bypassed using it at every opportunity. They would set up a Wiki instead of using the Lotus Notes document or notes portal that they had. They would use other messaging services. This is back during Yahoo Messenger and ICQ. But yes, we had that going on and in the end it was discontinued after its initial three-year maintenance period ended because nobody liked it.

AP: Yeah, so sounds to me like there was a bit of a fixation. This product checks all the boxes without actually doing any in-depth analysis of what you needed, much less actually thinking about what users needed and how that product could fill those needs. And I think it’s worth noting too, think about this from an IT department point of view, because they’re often a partner on any kind of technology project, especially if new software is going to be involved because they’re going to be the ones a lot of times that say yay or nay, this tool is a duplicate of what we already have. Or no, you have some special requirements and we do need to buy a new system. So if I as an IT person, the person who vets tools hears from someone, and let’s get back into the content world, I need a way to do content management and I need to have a single source of truth and I need to be able to take the content that is my single source of truth and then publish to a bunch of different formats. This is a very common use case. I would be more interested as an IT person in hearing that than hearing I have to have a component content management system. There’s a subtle difference there. And I think, and this is possibly unfair and grouchy of me, but that is me, grouchy and unfair. If I hear someone come to me, I need this tool instead of I have these issues and I have these requirements. It sounds selfish and half-baked.

BS: It does.

AP: And again, I am thinking about this from the receiving end of these queries, of these requests, but I also want to step back into the shoes of the person making a request. You can be so frustrated by your inefficiency and your problems, you latch onto the tools. So I completely understand why you want to do that, but you are basically punching yourself in the face when you go and make a request that is, I need this tool instead of I have these issues, these requirements, and I need to address these things. It’s subtle, but it’s different.

BS: It’s very different. And also if you do take that approach of looking at your needs, you find that there’s more to uncover than just fixing the technological problem itself.

AP: Yes.

BS: There might be a workflow problem in your company that you may acknowledge, you may not know it’s quite there. Once you start looking at the requirements and looking at the flow of how you need to work, and how you need any type of new system to work, you start seeing where the holes are in your organization. Who does what? What does a handoff look like? Is it recorded? What does the review process look like? When does it go out for formal review? What does the translation workflow look like? And you start seeing that there may be a lot of ad hoc processes in place currently that could be fixed as well.

AP: True. And I also think when you’re talking about solving problems and developing your requirements from that problem solving, you are potentially opening up the solution to more than just your department, your group. It can possibly be a wider situation there, too. And also by presenting it as a set of problems and requirements to address those problems, there may be already a tool in-house at your company that you don’t know about or there may be part of a suite of tools, and if you add another component to it will address your problem instead of just buying something completely outright. And we’ve seen this before, where it turned out there was an incumbent vendor that had some related tools already at the company, and that company also had a tool that could solve the problems that our client had or our prospect had. We’ve had both prospects and clients have this issue, so it doesn’t make sense, therefore, to go and say, I need this tool, which is essentially a competitor of what’s already in place. You’re going to have a very uphill battle trying to get that in place. It is also very easy, as someone who has already done a content ops improvement project, to understand this tool is good. It saves me at this company, but you’ve got to be careful of thinking just because it helped you over at company A. Now you’re at company B, it may not be a fit for company B culturally, there may be already something in-house. So you’ve got to let go of those preconceived notions. I am not saying that the tool you used