Corey and Deane discuss what clients should look for when selecting an implementation partner.
Then, Tony Byrne, co-author of The Right Way to Select Technology and President of Real Story Group, joins to talk through the implementation partner selection process, including common mistakes, the value of domain knowledge, and how most projects should focus on technology first.
The Web Project Guide podcast is sponsored by Blend Interactive, a web strategy, design, and development firm dedicated to guiding teams through complicated web and content problems, from content strategy and design to CMS implementation and support.
Show Notes and Further Discussion:
- Tony Byrne (@TonyByrne)
- The Right Way to Select Technology
- Real Story Group
- Episode 16: Select a Content Management System (w/Cathy McKnight)
Hello, this is the Web Project Guide podcast and this is episode 18. Select an integration partner. I'm Corey Vilhauer, director of strategy at Blend Interactive and co-author of The Web Project Guide. Later we'll be joined by Tony Byrne, who's president at Real Story Group. But first, I'm joined by the other co-author of the web project guide, Deane Barker. Hi, Deane.
How are you doing on this fine day?
It's not a fine day actually. The weather right now is a little miserable. So last Wednesday, Wednesday yesterday, it was like 32 degrees, and next Wednesday it's supposed to be 77 degrees, which is spring in the Midwest.
Yeah. I got my haircut today and every single person who was there was talking about the change in the weather over the next week. It is the only topic of conversation across the Sioux Falls, the Siouxland region.
I love the Midwest. That's what we do, talk about the weather.
Deane, we are talking about selecting an integration partner. We spoke with Cathy McKnight two episodes ago about selecting the technology vendor and now we're talking about the sort of other side of it, who's going to actually put that together. And before we dive into the interview with Tony, I want to I guess highlight that you're one of the few people who, you're definitely one of the few people I know who have been on every side of the selection process. You've been an integration partner, you've been a technology vendor, and you've helped clients select both technology vendors and integration partners. So the big question I guess is when you were in your role as sales for an integration partner, what's that question that you wished potential partners had asked? What's that nugget of information that clients should know but never thought to ask?
I think it is very important for a customer to know how, and I don't know how to phrase this without sounding weird, but how important they are to the service vendor, meaning are you going to be their biggest client or are you going to be their smaller client or are you going to be somewhere in the middle? And the reason why this matters is because bigger's not always better. You might have customers wanting to go with some massive like Accenture or Capgemini. Well, you're a rounding error to them. You're going to get the B team and you're not going to be that important.
Where if customer's with a smaller firm, and I use Blend as an example, you would be a very, very important strategic client, like you would be Blend's year, for example. And there are two sides to that. You don't want to be the smallest vendor. Being the biggest, you just want to make sure you're not too big and you're not going to overwhelm them because I've seen that happen too. But everyone thinks bigger's better, bigger's better. Not so much. You get them too big and Blend actually, in my history at Blend, I can think of several clients that Blend picked up because they were with much larger service providers and they said, "We're just too small for them. They're not paying attention to us. We're not getting the team members we want. We're not getting the time. We're not getting the attention."
And they came to Blend and everyone I can think of is still a Blend client because Blend is smaller and can offer a much higher kind of what it would call a standard of care. But again, you want to make sure you're not too big so that you overwhelm them. But that's the biggest thing.
And it's hard to approach that because if you ask a service provider, "How will we be relative to you?" They don't know what you're looking for. They don't know how to answer it. They don't want to seem too small. So they might want to try to overstate your importance, but then they don't want to make you feel too small. And this just goes back to the fact that the selection process is a dance of the dishonest. I hate to say that because it's not dishonesty, but there's a lot of times when we were looking at Blend, when we were evaluating RFPs, where I looked at them and sometimes I would say this out loud, "Whoever lies the most is going to win this."
We were honest to a fault at Blend sometimes and other firms sometimes are not, and they will specifically tell you exactly what you want to hear. I segue a bit off of that, but figure out where you stack up.
And I think even when you think about the idea of small, there are different levels of what small means. Small may be because you are new, small may be because you're just spinning up a new company or you're small for whatever reason. Small may be a business decision. You may be working with a firm that purposely is staying small in order to provide whatever work you're doing. And the opposite. You have organizations that are big because they have been very successful and have systems in place that allow them to be big and then you have organizations that are big because they hired a bunch of people and are hoping to fill in that work.
It is. It's like, I was going to say speed dating, but there's no speed involved whatsoever. It's like the slowest speed dating possible.
Right, right, right.
All right. Well we will talk to Tony Byrne here in a second. He's founder and president of Real Story Group, which is the only exclusive buy side technology analyst firm in the world, which means he focuses on the client side exclusively. And he's also co-author of The Right Way To Select Technology, which helps organizations understand the landscape of technology selection.
But first, the Web Project Guide podcast is sponsored by Blend Interactive, a web strategy design and development shop dedicated to guiding teams through complicated web and content problems. Blend's been building great websites for over 18 years, and we are always looking for our next partnership. So visit us at blendinteractive.com.
Hey, before we go onto this interview, I just want to say some things about Tony. Tony's been a very, very good friend to me since very, very early in my career. I've had a great career in this industry, I've been doing this for a long time. But if there's anybody I can look at in this industry and say was a mentor to me, it was Tony Byrne.
When I wrote my first book, I wrote the O'Reilly book in Web Content Management in 2016. I went to Tony to ask him to write the forward because there was really nobody else I could imagine writing it. And Tony has been incredibly influential in my career. I owe a lot of my career to Tony. And it was an interesting situation because Tony, as I'm sure we'll talk to him about, managed several selection processes in which Blend was competing.
And so Tony was this great kind of avuncular character in my life. And at the same time, I would go into these selection processes and Tony could be ruthless. And when I say ruthless, I mean that in the best possible way. Tony represents customers only. And we would go into these selection processes and Tony is just the most friendly guy in the world personally. But when he would interrogate you in front of a customer, it was like testifying before Congress. He takes his job very, very seriously.
And there was kind of two sides to him. There was Tony, my mentor and my friend, and then there was Tony, the selection process analyst, which frankly scared the hell out of me many times. Tony's organization, Real Story Group, probably brought Blend into seven or maybe eight selection processes. I want to say we won half of them. So we had a decent track record. Tony's really good at matching opportunities with vendors, trying to bring in the right vendor mix. And he wouldn't bring us into a lot of opportunities where we didn't fit. But I'm excited to talk to Tony today. He's been a good friend of mine through the years. Very, very gracious, and he's been a pillar of this industry for a long time.
Here's the bumper music and then we'll go in.
All right, let's welcome our guest, Tony Byrne. Hey, Tony.
Hey Corey. How's it going?
It's good, it's good. I heard you walked into work today, which is funny. I walked upstairs.
I walked downstairs.
Some days I do that too.
I think we need to set this up by saying that Tony and I go way back and to the point where Tony wrote the forward for my first book. So I'm assuming he likes me a little bit and this will go well. But what I'm going to do is, Tony is, I don't know if this industry has legends, but if it has legends, Tony would probably be one of them. You've been around for a long time, you've done a lot of things. I'm going to let Tony introduce himself and just give us a little background on what he does. So Tony, take it away.
Yeah, so I'm the founder of an analyst firm. Originally, it was called CMS Watch and we evaluated web content management systems, which I have had the joy and misery of using and playing with for the last 25 years. But we started expanding our coverage to other related areas like digital asset management, email marketing, now customer data platforms, personalization, all the things you might find across a MarTech or DX stack. We evaluate the vendors and we advise our subscribers who are primarily large enterprises in which vendors might make most sense for them, how should they manage their stack, so on and so forth. So we advise typically large enterprises in their MarTech decision making.
So it's fair to say you fit into, would you put yourself into the category of analysts?
Yeah, we're an analyst firm, so we advise firms in their decisions. We don't go in, and aside from helping an enterprise select a technology or perhaps evaluating their MarTech stack, we don't actually go in and do business consulting or implementation work. That's a whole different array of firms, and in fact, we advise enterprises on which firms might be a good fit for them.
So our history, obviously Corey and I used to work together at Blend, and our history is Tony, you actually brought us in on several selection processes, some of which we won, some of which we did not. Why don't you just give us an idea, Tony. If you were to engage with a customer, say I'm a big enterprise and I'm looking to redo my website and say I've already found a technology vendor. We talked to Kathy McKnight a couple of months ago about the process of finding a CMS platform. I found that, I need somebody to integrate it. Can you just give us some insight to whatever extent you're comfortable on what kind of process we would go through for that?
Yeah. So we're really big believers in a kind of an agile selection process. In fact, we wrote a book about it called The Right Way To Select Technology, and to be sure that was really around selecting the platform. But one of the chapters in the book was around how to select a service provider. And you want to do this, what we would say is use some of the same kind of agile methodologies or agile-ish methodologies that you would apply towards selecting a platform towards also selecting the right service provider. That means being a team-based, agile, iterative, not do a kind of waterfall where you build a bunch of requirements and then make a really rapid decision. So we recommend actually putting them through their paces, like maybe doing an actual simulation. Just the same way that you test the software, you should test a service provider with maybe a day long simulation where they gather some requirements and make some recommendations or something like that where you actually get a hands-on way of feeling what it's going to be like to work with them.
The other thing too is to do maybe just bring them on initially for a pilot project. In other words, they of course, want to sign up for the whole banana. But I think for you, your interest maybe is sort of a little bit of try before you buy. Really, if you're a service provider, maybe you don't love this advice, but our recommendation is not necessarily to always make a long-term commitment because the types of things that you're going to need from a service provider might be very different. At first, it might be really heavy technical implementation or maybe it's the opposite, you need a lot of business consulting around data content and processes. And so at you may need different firms at different times. There are certain key things you may want to insource, so you really want to keep the light on your feet and give yourself options going forward.
Tony, you talked about finding a service provider who can match the technology, but do you find that there is any benefit in selecting a service provider first or is it always make sense to have the technology selected first?
So we're really biased here, I would say, in selecting the technology first with maybe one exception, and I'll get to that in a minute. But it's a really interesting point because in many cases, even with a SaaS platform, you may be spending more on services than you do on the actual platform itself. And so this leads people to believe, well, shouldn't I spend more time? Since I'm spending more money there, shouldn't I spend more time and effort? And here's the thing, there's 50 ways to leave your service provider, there's only one way to leave your platform and it's almost always very, very ugly. So the platform is really the strategic choice that you're making. And so you really want to put a lot of thought into that. Ideally, you do that first and then you pick from among valid partners who match against the kinds of capabilities that you're looking for.
We have done so-called... We've kind of mentored what we call combo selection projects, combination, where you're evaluating both the platform and the service provider at the same time, which can accelerate things. There are risks in that approach that are pretty obvious, in terms of the complexity of the decision making that's involved there. But it is possible to do them both together.
Now the one exception is those I would say fairly rare cases where you are trying to implement a variety of different tools at one time. And so what you do is you go to typically a major systems integrator and you say, "I want a personalization platform, a customer data platform, a web content management system, and an analytics package, and they all need to work together. Here's what I'm trying to accomplish. You find the vendor partners and go and put together essentially a package for me." We don't see that too often, but it's a legitimate use case where you might want to essentially hire a general contractor who then makes the decisions on what are the windows going to look like and what plumbing goes in and all of that kind of thing.
When you look at a service provider, when you look at a team you're going to work with over time, there are what I would call very tangible kind of markers of what you're looking for like, do they know your technology? Can they fit your project in? Does the price look good? But let's talk about intangibles. If you're staring down a long-term relationship with a service provider, what are some of the subtle things you're looking to match on that aren't as obvious as price or schedule?
Cultural fit matters. I think people sometimes overweight this a little bit, but they need to understand the way that you work and the way that you like to make decisions. And as people who support decision making in large enterprises, I can tell you there's a lot of different ways that a company even in the same industry will make decisions. Some are very hierarchical, some are more consensus based. There are issues around how you make decisions at a global company that may be different. And so having a service provider that's really empathic there. Or maybe you're a high acting financial services company and you need to move very quickly and you don't want to be bothered with details, that maybe is a different type of service provider or a different team that's going to work with you.
So I think there is something to be said, sometimes even for geographic proximity, although again, you can overweight that as well. But I think that probably the biggest thing is the fit not just of the individuals but of the company, that company is comfortable working with an enterprise your size, whether because you're smaller or because you're larger, these things match up. You don't want to be that service provider's smallest client, but you don't want to be their largest either.
Okay. You just hit on something there that triggered me a little bit because you talked about physical location. Now, Corey and I both used to work at Blend Interactive, which is based in Sioux Falls, South Dakota, which is a bit out of the way now. Tony, we've been in a lot of your selection processes. I remember one in particular that took place at the top of a very tall building, right on the Chicago River. It was a process that we went through with you that we did not win. And I believe that the customer ended up picking a firm right across the river from them, in the loop. So I'm not saying I was bitter about that, Tony. But we looked at a situation like that and like at Glen, we looked at a situation, we're very out of the way and we're a smaller firm. Let's talk about location. In this world of Zoom meetings and remote collaboration, is there a benefit to having someone in the same town with you?
Not really. By location, I mean more a certain vibe. My perception of Blend is you had kind of a Midwestern vibe. You're nice people, you overcommunicate, you can edit this later, but maybe not the kind of polish and slickness that some firms look for.
I don't think we should edit that out. I'll take that. We were very authentic.
And by the way, this matters internationally as well. If you work with a large enterprise that's global, you're going to work with a lot of different local cultures as well. And so cultural fit does matter. My recollection of that particular selection was that they were looking for a very particular technology and somebody who was deep on that technology. And so that was one of those kind of combo selections where I think the technology won the day. But you're right that in the era of Zoom, one of the positive things is that I think geographic proximity itself isn't necessarily all that critical. It's still worth being able to meet in person from time to time. And it's more I think around cultural fit and how well that index is to geography as a topic, I'll leave alone.
This reminds me also of sort of another element that I will always steadfastly completely belief that good design, good IA, good content, is good design, good IA, good content, good development is good development, that you don't necessarily need to, for instance, find a vendor that specializes in municipalities in order to build a municipality website. You don't need somebody who specializes in university content to always build a higher ed website. And you can be completely honest. Am I wrong?
I think you're half right. So let's start, first of all, with the platforms themselves, is that some technology sectors are very horizontal, which means that the technologies spans across nearly all verticals. And some technologies tend to be very vertical. In our experience, systems that are very process oriented are often highly verticalized. So things like ERP and workflow and other systems, you'll often have a partner or even a reseller who's very specialized to that vertical. And so in that case you probably do. But things like web content management, certainly the platforms are typically not vertically specific or segment specific.
And then does the implementer need to know your space? I think it's mostly no, but there's a little bit of yes there that particularly in certain segments like media where content is your product, higher ed and public sector, which have their own particularities certainly, although some of that is just dealing with really long sales cycles and your patience to do that. So there is a little bit, but I think the key there is that as a firm, if you're really empathic and you can understand what it's like to be in that person's shoes. And if you'll accept a little diversion here, I'll maybe answer a question you didn't ask or you asked it and I forgot to talk about it. And that is what we look for when we're advising an enterprise about a service provider is which side of the table are they on? Are they on the vendor side of the table or are they on your side of the table?
And this is really important because resellers are of course, almost always on the vendor side of the table. Systems integrators often have close partnerships with vendors. But there's going to come a time when they're going to have to say something or do something that the vendor's not going to like or they're going to have to say, "Look, I know you loved this workflow system in the demo, but I'll tell you that the real story is that it's complete shit," and you don't want to implement it. And you have to have the service provider be on your side of the table. And so when I'm talking about empathy, it's not just being a good listener, but really taking sides with that customer as the customer as always working in their best interest. And as an enterprise, you can often detect this pretty early on, where the service provider is coming from. And always remember there's a really big difference between a reseller and an implementer, even if the implementer has very close relationships with the software vendor.
I know we've won projects because Deane was brutally honest about the systems he was selling.
I tended to be honest, sometimes to a fault. As long as we're going down memory lane here Tony, I'm going to take you back to another selection process we did with you for a large healthcare provider in Denver. And I remember in that particular process, something interesting happened at the tail end of that, but I'd just kind of like you to comment on. You came back to us and you said they were very impressed with Blend for your technical expertise, but they're concerned that you won't have empathy for them as users. They felt like we were just too technical. And we went back to them and we proposed Corey actually, my co-host on this call, and Corey was, we positioned him as kind of a customer advocate. And so that kind of segues into a conversation of somebody can be wildly technically competent, but completely fail at things like empathy and customer service. Do you see that quite a bit?
Yeah. And that's why services companies have different roles. A good account exec is not just managing the invoices and doing quarterly business reviews. A good account exec is really listening hard and making sure that the team is aware of this. But that's also, it's the role of business analysts and project managers. It's true, that I think it's maybe unrealistic and unfair to ask people who are deeply versed in coding to also then get out of that mindset. Now, I'm not trying to be too stereotypical and say that all coders are not capable of this kind of listening and empathy or that people who are really good at gleaning requirements and understanding the business contexts can't code. It's just that they are very different jobs. And there's those rare people who are good at both jobs, but you know need to bring it in.
And actually I think it's unfortunate that sometimes people make this distinction between so-called soft skills and hard skills because actually, they're both hard. And more often than not, we see among our enterprise is that when they go to an outside firm, it's because they need a lot of help in requirements gathering, they need a lot of help in data and content analysis, they need a lot of help in getting the whole thing running before anyone lays down a line of code. The coding they can typically find. They can even get that from the vendor's professional services arm because our vendor professional services are very good at implementing and standing up their platforms. So they tend not to be good at is longer engagements where you have to really meld a little bit with the customer and do some of the more business oriented consulting, which again, those are not soft skills at all. They are hard skills.
You mentioned something else that kind of opened the door to a topic is that a lot of vendors do have expert professional services, outfits. Some vendors, the software's almost a loss leader for them and they make money on the implementation work that they do. Other vendors, like Optimizely, a vendor I work for, as a disclaimer, we do have professional services because some of our customers demand professional services from the vendor. We don't really advertise that, we don't compete against our partners. We very rarely do full implementations. We normally just do expert consulting. As a customer, if I have selected a CMS and the vendor says, "Oh, we can implement it for you too," comment on that a bit. Should I be concerned about that? Is it something I should entertain?
Well, sometimes vendors have to say that. As you say, some of their customers want that. And in some cases it's legit. If I've got a number of other things or I already have a partner who's handling a lot of my prep work and migration and things like that, maybe I do just need... Or maybe I'm building up a large internal team and I just need the vendor to advise me. So it's a legit use case. And I don't know whether I'd be totally suspicious about a vendor. We do know that the model of software as a loft leader for consulting, that's a very risky and perishable model. Wall Street doesn't like it. Wall Street likes to see profits coming from products and investors in general.
So when they look at the services business, which tends to be a lower margin business, although high volume, that's a very different type of company. Sometimes vendors say this because their software is so complicated and it's such a toolkit that they're the only ones who probably could have, and we see that from time to time. And that may just be the reality of it. And you need to understand that, that you're buying a toolkit and there's secret handshakes and a kind of guild around who can actually manage that toolkit. And if that's what you want to do, that's fine. But don't imagine that you're getting packaged software. Typically, what we see a really big crossing of the chasm of a startup software vendor is when they start actually leaning on implementation partners because that means the platform has been sufficiently abstracted, that they can train other people to do it.
So this segues into another conversation that you and I have had over the years is back when Blend was the very first partner of Episerver back in 2008, and I would evangelize Episerver to you constantly. And you would always talk about how, how many people are implementing it. And I would get frustrated. I'd be like, "It doesn't matter how many people, we're implementing it and it's awesome." Talk about partner networks.
And this comes to light because I did a consulting engagement with a customer once and I recommended to them, this was back when I worked at Blend and I wasn't an employee of my company now, but I recommended to them a smaller market CMS. And a year later they came back to me and they said, well, that's CMS we were using a professional services, we've overwhelmed it. We need you to find as a third party partner. And so I went looking and I could only find three that claimed to be a partner of this vendor. And I called all of them up and all of them and was like, "Well, we did one project like five years ago, but we haven't really done anything since." And at that moment, Tony, I will tell you that I thought, this is what Tony was talking about.
Super proprietary platforms, that should be a red flag that it's so proprietary that I can't find anyone else to implement. And this is why the platforms that really emerged from the open source wars of the '90s and 2000s, like WordPress and Drupal, whatever their are many obvious disadvantages, one thing you won't lack is finding people who actually know how to implement it. Now, they may disagree vehemently on how to implement it, but there's certainly no lack of support out there in the world.
Let's talk about ongoing relationships. So I've selected my service provider. Let's say a year, 12, 18 months down the road, everything falls apart and I have to go find another one. In your experience, Tony, why did it fall apart? What are the big reasons for a breakdown between a customer and a service provider?
Well, it's like any relationship. It may have been a mismatch from the beginning in terms of you were headed in different directions. It could be that you're going more into maintenance mode rather than enhancement mode, and the service provider has downgraded you and maybe not giving you the attention you need. Or conversely, the platform has become more of an anchor for you. And by which I mean like an anchor store in a mall. It's really foundational to you and you're not getting what you need from the vendors, just too unsophisticated for you or doesn't have the skills and capabilities. I think the most common thing is a mismatch on the commercial side. Either you're not getting the value that you needed or you've become less important to that vendor and that service provider and they're not billing as much or they're not transitioning to maintenance mode and things are falling apart.
I think the other thing that's often related to that is many service providers have substantial staff to turnover. This happens everywhere. In the digital world, there's a lot of staff turnover. And so it can be a challenge for them, on their side, to sustain relationships. And sometimes things go bad that way that. You had a project manager or an account exec and they left and the new ones are not catching onto your business and you are not getting the support that you need. And so you start looking for something else.
I guess what I'm saying is this is not an abnormal thing. It's not necessarily that somebody did something wrong. Companies evolve, their needs evolve, service providers evolve. They suffer some of the same turbulence that our enterprise clients suffer. And so this is why you need to be able to be light on your feet and to be able to switch from time to time, for perfectly good reasons. And that's why the switching costs for a service provider are much lighter than the switching costs for the platform itself. So that's why the platform, it's so important that you get that right.
At Blend, one of the most challenging things that we would run into is this concept of co-development. And we did well at this at Blend, we've always done really well at this. But we would see situations where the company would like, "Well, we want to do some of the development." Either they want to lower costs or they were just freaked out about handing it all over. They were worried about knowledge transfer. Does co-development work? And if it doesn't, can it be made to work? I've always thought these situations were just fraught with peril. But give me some your feedback on that.
Yeah, I'm not surprised that you found it fraught with peril because it's high risk for the service provider, not the least your expectations, margins, pacing, scheduling, everything, right? Service providers, they have their methodology, they have their teams, they have their deadlines, they have their utilization rates, and they want to come in and really control the situation. So I recognize that.
But when I'm sitting on the customer side of the table, which is 100% of the time, I'm like, I don't want this thing to be a black box. I want to know how it was made. If it's really important, again, a foundational anchor in my stack, I need to be able to manage this on my own at some level. I want to turn to my own developers to do minor tweaks and maybe an external provider to do major enhancements. And so this whole, don't worry your little self, we've got a methodology, we'll come in here and we'll deliver on time is not always very comforting for them.
We do encourage our customers, particularly those that have some expectation that they will be taking over this platform, at least to some extent, that they try to do some co-development. But then they also have to recognize that in some ways this actually could cost a little bit more rather than less. And in particular, it may impact schedule. Because you're training people, you may have to be correcting their work. And so if schedule's really important to you may need to leave your own people out. But if you're willing to exchange a few extra weeks on the schedule for your team to be deeply immersed, most of the time, I think that would be worth it.
Last question I have is something that you've alluded to a couple times in this conversation. It's that you are always on the customer side of the table. And Real Story Group has famously never done vendor side consulting. So you never work for vendors, you always work for customers who are seeking vendors or seeking service providers. And I know, Tony, that you are wildly anal-retentive about neutrality to the point where if you and I have ever been in a social situation, I have never been allowed to pay for your meal, I believe. We've broken bread together several times, you've never let me pay. Either you paid yourself or you paid for the entire meal. As a customer, if I'm looking for an analyst, aside from hiring Real Story Group, what's the trick to make sure my analyst isn't working both sides of the fence?
There is no trick. I respect my analyst peers who usually try to fight their corner pretty hard and they will, over beers, they may tell you the real story. The problem is that they put a lot of noise into the market in terms of static quadrants and other things where their analysis is very dated and I think it has a negative, sometimes even toxic impact. So my problem isn't with individual analysts, my problem is with this system of analyst relations and the analyst world, which is highly conflicted. This wouldn't be allowed in the financial services world where they make a really definitive break between, a so-called firewall between buy side analysis and sell side analysis. Doesn't mean that people don't violate that and the SEC comes and finds them, all that good stuff.
Have no SEC in our business.
Yeah, we're not important enough to have an SEC or anything like that. So you're kind of on your own. And I think that it's a little bit of a buyer beware type situation. The big thing that we see, the major bias is towards legacy vendors. So if you have been on this analyst firm's radar for a long time, you get a little bit of extra push out there. In the CMS space, Gartner and Forrester were pushing interwoven 10 years after its sell by date, literally 10 years after the system was useless. So that was just sheer so-called analyst relations and inertia. Analyst relations is not like public relations. Analyst relations, money is a used to influence. It's basically lobbying. And so I've been on this high horse forever, I'm going to get off it now and just say that, you want to establish trust with whatever advisor you know have. And sometimes that takes time. But trust is the real critical element here.
Tony, I suspect there are people who are listening to this who have stumbled across this podcast. So they've stumbled across the chapter and they are going through this process for the first time, they've decided they need to select an integration partner. We've talked about a lot of the things to look for, but what do you think is maybe the biggest mistake a first timer might make?
Don't just fall for a pitch. Everybody's good at pitching. Most service providers are good at pitching. Particularly if it's more of a consulting firm and less of a systems in integrator. And they all have case studies and they generally have references. You really want to try before you buy. And a lot of people don't even know that they can. Do a one day simulation, do a one week sprint, we love one week sprints. You may have to pay a little bit for that, but you'll learn a lot about yourself, about whether your requirements are realistic, about how much all this will cost. You have the time and the opportunity to take a more agile, empirical approach to this, whether it's a software vendor or a service provider. And you should take that opportunity to test drive the car.
Great. Tony, is there anything you want to plug other than your book? The book was published in 2017. Yeah, it's excellent. It's Rosenfeld, right?
Yeah, Rosenfeld Media.
Well, Tony, thank you very much. We appreciate your time.
All right, good chatting with you guys.
Take care. Bye now.
All right, Deane, we are back. That was Tony. I feel like we got friend and mentor Tony today, and not ruthless Tony.
We did, we did. Love Tony to death. He has forgotten more about vendor and service provider selection than most people will ever know. And Tony possesses this just incredible wealth of kind of tacit knowledge and experience about what to look for and what to not. And I've been on the other side of friend Tony. I have been competing in selection deals where ruthless Tony showed up to play. And yeah, he takes his job really seriously. It's just so exciting to talk to him and hear his experience. So great conversation.
Great. Well that wraps it up for us. A huge thanks to our guest, co-author of The Right Way To Select Technology with Jarrod Gingras, who I believe was a Now What? speaker back in the day.
He was. He was a Now What? speaker at one of our very early events.
Yeah. Now What?, of course, being a conference that Blend put on for many years until we realized that putting on events is very hard and we don't want to do it anymore.
You can pick up that book from Rosenfeld Media and we'll make sure to have a link to that in the show notes. The Web Project Guide is a product of Blend Interactive, a web strategy design and development shop that builds websites and guides teams through complicated web and content problems. We're dedicated to making great things for the web, and this is one of those things.
This is episode 18 of the Web Project Guide, which corresponds with chapter 18 of the book, which is Select an Integration partner. You can read the full text of this chapter at webproject.guide/select-partner. If you like what you hear and you want to turn this experience into about 400 pages of words, you can order The Web Project Guide for yourself at order.webproject.guide. You can get a physical copy, which is great, you can get a digital copy, which is great, you can get socks, which are great.
And if you like what you hear, leave us a review, five stars in your podcatcher or a positive review on Amazon. We appreciate it. It feeds our need for validation. And with that, thank you for joining us this month. Subscribe, share, and we'll be back next month to talk front end development with our friend Ethan Murcott. Until then, go do amazing things.