Editor’s note: To introduce the concepts and potential speakers for our new ContentTECH Summit, we’re sharing some tech-focused talks from the most recent Intelligent Content Conference. Tony Byrne, founder of buy-side tech analyst firm Real Story Group, offered tips on a new way to sort through the many content technology options to find the best fit for you. Watch the video of his complete talk or read the edited transcript below.
Traditional approaches to choosing technology don’t always yield the best results. For a modern alternative, look to design thinking for an adaptive, hands-on process that should help you make the right choice for your teams.
This title seems a little bit obnoxious. Usually as an analyst you’re saying, “Well, it depends – maybe this, maybe that.” But, on this one, I feel really passionate that we’ve been doing this the wrong way for a long time.
I feel really strongly that there is a right way. I want to share with you a methodology that you can use for any technology, including content technology.
Content technology is so important because it has to work for the people authoring and editing, as well as the people consuming the content. It’s sometimes more complex than selecting other types of technology.
Let’s start with a couple of questions. The first one: Why do half of all IT projects fail?
This has been the consistent data over the last 30 years, that half of all IT projects fail to meet their objectives or fail outright.
Why does that happen? Answers (volunteered by audience members) include:
Here’s a separate question, and I’m going to put these two together in a second: What is design thinking when it comes to digital?
This is a hot term right now in the creative space and in marketing as well. Does anybody know it?
Audience answers include:
Good. So, the traditional technology selection has been made using a waterfall approach. This is a very old-fashioned approach, where you try to get all the requirements perfect, and then – boom – pick a tool.
Design thinking teaches us a much more agile and iterative approach from the design world that we’re to apply to technology selection.
It took us a long time as an analyst firm to learn this lesson. I founded Real Story Group originally as CMS Watch about 17 years ago. We wanted to create a different kind of analyst firm, something that was customer-focused and focused on analyzing the strengths and weaknesses of different vendors.
We didn’t feel that there was a really proper Consumer Reports-type firm out there. That’s what we do today, we provide this research and subscription to companies who are considering selecting these tools. We only work with buyers. We never advise or consult with vendors, and that gives us the independence to be arguably the hardest hitting, most critical critics of this technology out there.
We cover a variety of different technologies. The light blue line on this map is web content and experience management. The light pink line is digital asset management; purple is marketing automation and campaigns; orange is customer relationship management.
You see that there are some vendors (Microsoft, Salesforce, Oracle) that have a whole panoply of different solutions across all of these different lines. And then you’ve got these best-of-breed type solutions as well.
Where do you think most of the innovation is happening? At the center, or at the periphery? The periphery. These are highly fragmented markets, which, in a more human wording, means you have a heck of a lot of choices when you want to select a digital asset management or web content management system.
Choice in general is good, right? As a customer advocate, I say the more choices you have, the better. You just need a framework for filtering that down.
What’s the right framework? There’s something produced by Gartner called the Magic Quadrant. Forrester has something similar and so does IDC. This is where the analyst firms rank all the vendors. You want to be in the top right quadrant, which shows the best vendors.
For a long time that’s how people picked tools. I remember actually trying to implement some of these tools that were in the upper right-hand quadrant and wondering how these things that are completely messed up got there.
Over the years, we learned that there was a better way to select technology – not just focusing on who’s in the upper right quadrant, but what’s the best fit. My colleague Jarrod Gingras and I finally sat down and wrote a book about it, called The Right Way to Select Technology.
This book was in reaction to these wrong ways of selecting technology:
Sometimes the results of using something in a way it wasn’t intended can be catastrophic. Usually it’s just more of a pain, but it also shows, in a way, a lack of respect for your peers. You say, “Okay, we already have this, so I’m just going to say that it’s the right thing for you, rather than actually giving you a chance to use it.”
Applying design thinking is a way of getting outside of this waterfall approach and being more agile. We like this particular definition:
A human-centered approach to innovation that draws from the designer’s toolkit to integrate the needs of people, the possibilities of technology, and the requirements for business success.
According to David Kelley, it has these five steps: empathize, define, ideate, prototype, and test.
It turns out that these are very similar to the five steps that we’ve learned to take people through when they’re selecting technology.
The first thing you need to do is make it human-centered. Our subscribers get to call us and ask us questions to help them through these challenges. The first question we ask back is, “What does your selection team look like?” Sometimes they’ll go, “Selection team, what’s that? I’ve just been tasked with doing this.” Or, “We’re just doing this ourselves in this little marketing group.” Or sometimes, even worse: “Oh, IT is picking this for us” or “There are three people working on this.”
You want an interdisciplinary selection team that’s led by a business person and includes IT and other stakeholders, depending on the type of technology. It should be a diverse set of interested stakeholders, and it’s really critical that this team not be too senior. The methodology that we’re going to show you is pretty intensive and pretty hands-on. It has to be people who actually have the time, know what they’re talking about, and would be using this stuff.
So let’s take those five steps of design thinking and apply them to a technology selection methodology.
First, we empathize. You create narrative stories. You can call them user journeys or you can call them scenarios. It doesn’t matter what you call them. There are a lot of different methodologies for this out in the design-thinking world. Just pick one and do it. The key thing is it is a narrative journey. It represents different stakeholders who could be customers, authors, editors, developers, designers, or whatever.
You want to describe a “to-be” state, not prescribe that you want the button in the upper right corner. It’s more like this: “Marsha is a content author working from her house, who has to collaborate with these others. This is how we want to create content.” Get rid of your spreadsheets and checklists. Vendors have seen them and they can check all the boxes. Typically, the differentiators among tools is not what they do, but how they do it.
If you have a “what” question, turn it around and put a “how” in front of it. Let’s say you’re doing structured authoring and you want to ask “Do you support DITA?” Instead, what you say is “How do you support DITA?”
Let’s say you’re looking at a content marketing system, and you need to export these components into Sitecore once you’re done with them. Don’t ask “Can you output them into Sitecore?” Every vendor’s going to say, “Yes, of course we can.” The more interesting question to ask is how.
It’s okay to ask questions, but again it’s more around a narrative. If that narrative is important to you, put it in one of your user stories.
Developing stories is part science, part art. We have a particular structure that we like. You may find some other structure. The point is there are real people here.
There is this guy Ben, and he works with his boss Louise, and they’re in a public university that has 40 to 50 new public-private partnerships every year.
They have to have a microsite for each one. They want to have a cloning machine that stamps those out and allows them to configure it and add some new content along with some existing legacy content. This is how we’re going to describe how Ben and Louise and their partner from this financial services company, Bill, are going to do this. That’s what the vendor responds to in its proposal with screenshots and in its demo. Then, in your proof of concept, you actually get Ben and Louise to try it out.
Now, as content people, this is great. You should be really awesome at this; you’re already creating stories. It’s just that you’re doing them for other people. You understand content. This is a content approach to selecting technology, except instead of talking about how people may use your product and service, you’re talking about internal processes.
I’m guessing you already know how to do this, you just haven’t gotten the chance to do this in the context of selecting tools.
The heart and soul of the RFP you’ll create are these narratives, with a few additional “how” questions. Then you want to get a short list of vendors to which you’ll send the RFP.
There are a lot of different ways to do your research. One thing to avoid are these static quadrants. We have a tool called RealQuadrant (you can try it out for free).
If you’re looking at portals, for example, and have a certain set of use cases and considerations, you can see in the quadrant on the left (below) there are two vendors in the winners quadrant and one in the losers quadrant.
Then, in the quadrant on the right, it’s completely reversed. The vendor that was a loser is now in the winners quadrant. Why is that?
The use case was different. One case was internal collaboration, and they were really concerned about cost. In the other case, what they really wanted were dashboards; they needed to work with a vendor that had a lot of external consultants who could help them build it because they didn’t have the internal capabilities to do that.
The point is to develop a short list of vendors that works for you. It isn’t something that somebody else gave you. It’s unique to your particular circumstances with respect to geography, price, the level of maturity you have, and how mission-critical the application is for you.
Now you get a set of proposals back. Since they’re created against your user stories, you’re going to learn a lot. The answers may be telling you that there’s something unusual about one story – maybe you didn’t explain it quite right.
Or, maybe the vendor has suggested a different way of doing things. Maybe all of the vendors can handle one of your stories, so you don’t really need to worry about that one going forward. Maybe the answers are telling you there’s a critical story you haven’t told.
The point, then, is to adapt. You use this step to filter the number of vendors you want to invite in to do demos. But you also change your demo script based on what you learned.
You don’t have to be perfect in your RFP, you just have to be good enough to start a conversation based on real human journeys.
Then, you get to the demos, which are almost like prototypes. Remember, they should be based on your scripts, not the vendors’ scripts. It’s a little bit more work for them, but we find that 99% of the time vendors like this. It feels more real to them, and they get a better chance to show you how good a fit they are.
I sit in on probably 30 day-long vendor demos a year. It can be totally deadening. But if it’s highly structured, you set a fast pace, and the heart of it is this two hours of demonstration of the scenarios in the middle, then it becomes much more relevant.
Make sure you have a break and a private caucus. Then you can figure out what you don’t like about this tool and what questions you have. Then, bring the vendor back in and really have a structured conversation.
You’re going to learn a lot in the demos about the tools, about what’s possible, including things you didn’t think about. So, then, what do you do with your narrative stories? You edit them, you adapt them, you iterate them for the next round where you’re selecting two vendors back for the POC.
The POC stage uses real scenarios, real content, real people, in a real environment. It’s like the demos, except it’s hands-on. You may need to commit the first day to two days to user and developer training. At least enough to impersonate some of these personas and actually play with this technology.
How long do these bake-offs have to be? For most solutions, you need at least two days. If it’s important, we typically say you need a week. A week gives you time to do a development sprint with the vendor. Then you can see how quick it is for them to reconfigure the tool.
One of our subscribers did this for three weeks for something really mission-critical. They were going to be spending more than $10 million. Another subscriber recently went through this process in one week, with two different vendors. It was a major web content management package for a major media company. They ended up preferring one but asked them to come back again to prove out some scalability and architectural issues. They iterated one more time.
You’re allowed to do that. You’re the one buying the tools, so you want to take the time to get comfortable. What if your boss says, “We don’t have the time or resources to do this?” Then you can explain that they’re asking you to buy the car without actually test driving it. You’re going to watch the salesperson drive this new car around the parking lot and then decide whether it’s right for us. That’s what it means to select tools without actually testing them yourself.
In the end, you’re trying to find the best fit. It’s pretty rare to find the perfect fit, so conversations become about managing trade-offs. Hopefully, the whole process has been so human-centered and transparent that it’s clear what those trade-offs are. Then it’s easier for reasonable people to come to a consensus.
We tend to argue that functional fit and partner fit should predominate. Those have to work. Ideally, there’s also technology fit and value or cost fit.
If you work in IT, you may consider technology fit very, very important. Sometimes we see disagreements. Someone will say, “This is just not a good technical fit,” and then you have to work that out. Or, it may not be a good cost fit, and you’ve got to work that out as well. There are no easy answers here, but you’ve now had the opportunity and the time and the ability to iterate, to surface, and be very clear about these trade-offs.
If you decide to go with a content technology because it’s the right business and partner fit, but it’s not the right technical fit, then go to your IT team and say, “What can we do to ameliorate this?” Maybe you need more resources to bring in developers to make this a better technology fit. You accommodate the people for whom this is going to be more of a problem. You have a very concrete and candid discussion.
Okay, if you remember nothing else, this is the main theme of the day. Iterate: Start with light requirements that are story-based, then refine them through a process where you’re learning all the way through.
This is applying design thinking to selecting technology.
Want to check out ContentTECH in person? Sign up to be notified when ContentTECH Summit registration opens.
Cover image by Joseph Kalinowski/Content Marketing Institute