Software Vendor vs. Software Implementer

Transcript

Note: The following is the transcription of the video produced by an automated transcription system.  All right. Welcome today, we have Ken, Mike and Matt answering my stupid questions. So today we're going to talk about software vendors as opposed to software implementers. Just to set the level playing straight software vendors are companies which provide products and services. Software implementers are the people who the agencies who take those pieces of software or product and then customize it to their clients needs. So let's start with a general question, right? So what are the challenges? A software vendor faces in the current market?

I'll go, so I think that when you're a software vendor from just the basic business point of view that you're creating basically one product, maybe you create a suite of products, but then you would be what we would almost term a monolith. Right. But I think when you are creating one product, it has to be really, really good and you're not very diversified. Whereas one bad release, you know, one bad piece of news can move customers onto the next solution and implementers in a very good position because they can choose the best of breed for any needs marketing, technology, automation, personalization and really be in a very good position to create combination innovation and tie them, tie them together for a solution that is hopefully better than the sum of some of the parts.

I'll tag on to that as well to say that with the vendors specifically, as you mentioned, the competitors tend to face tight timelines for getting their product to market and thus will maybe launch with bugs and issues and things that will obviously create issues that you know that the user might experience. And thus the software implementer now has to come in and kind of give some advice and some tips on how to fix those sort of things. And also having again, a broad spectrum of experience as a software implementer, you can actually bring that advice back to the vendor. So we have again, a team of experts or as a vendor or the implementer, you will have kind of a breadth of skill sets that can address issues that maybe are not in that vendor implementation or in that vendor organization so that they can't address those issues. So I think a software implementer has that ability to be more agile. And then again, have a breadth of experience that they can kind of mitigate some of those challenges that a vendor experiences trying to get their software to market faster than their competitor.

Well, we also have to consider the technical challenges that a vendor is facing is very different from an independent because the software vendor is tackling a very broad range of problems. And normally quite a generic level because they're trying to fulfill the requirements of hundreds of thousands of different customers and their competing needs. So you have to create a very sort of generalized platform that people can build on top of. So that means creating a solution that is very flexible, very intuitive and easy to use. But it's got that has the broadest appeal, whereas when you come to an implementing it, we as an experience ourselves, we focus on just solving the specific problems that our customers are having. So we take that very broad set of tools that are given to us by a software vendor. And then we hone them to what we need them to do to our specific use cases. So it's a very, very different challenges for the two sides to tackle, and they sort of complement each other as well at the same time.

We're from an implementation perspective, though, as implementers, we can't just do one piece of technology, right? You have to know the different systems because that's what you're offering. I think that's more of a challenge because you're having to learn different things. And the more you work on a specific technology, the more knowledge you get out of it. So I think that's kind of interesting. I also feel like an implementer is much closer to the customer than a vendor is. A vendor sells the product great, but I almost feel like there is a there's a little bit more of a separation between a vendor and a customer than an implementer and a customer. You're almost a little bit closer because you're working hand in hand to solve a problem. So if something goes wrong, it's the implementer who has to bear the brunt of it as opposed to the vendor. I feel anyways, that's just the way I think it is.

Do you guys think that maybe I'd ask even Akshay. Do you think it's dangerous when the vendor tries to be the implementer?

It's a double edged sword, I was going to be my next question. Some vendors do it, but that's not their business, right? So I think that's a very valid question. I wanted to ask who exactly has the better understanding of the software, like in my mind, the vendor absolutely does on paper, right? So the vendor built the software depending on the resources they have. They have the knowledge of how the system is supposed to function. But to be quite honest, using all these different systems, the implementer has the key piece of info because when you're implementing it, that's when you find issues you, the vendor cannot anticipate the different ways in which the system is going to get used. So you come up with these use cases. The implementer has an edge in terms of actually using the product. The vendor has an edge in terms of knowing what the product's thresholds are,

How it's being used in the marketplace. And you mentioned something at the beginning there, which was depending on the size of the team. So depending on the size of the vendor, I think we'll have a great impact on, you know, whether or not they're going to be able to deliver on, you know, solving problems for the end user. Whereas if you have a plethora of partners or software implementers, they're the ones that can handle each one of those individual customers with a more white glove, if you will, type of process.

Hopefully, your vendor is working hand in hand with its implementation partners, so it's getting that feedback from the real world of experience and building that back into it, back into the product to address Akshay's point of like, should the vendor be the implementer at the same time? Well, I mean, there's two things there's a business level, which is if the vendor is the implementer, then they will struggle to potentially create a partner network because they're directly competing with their partner network. But also it's about like, where's that separation coming from? Because if it's the same company, it can be very easy for the implementation side of the company to start requesting very specific features from the platform side of the company that are just that for their current client and the implementation they're doing. And that's then not in the vendors thing of the web now. Best interests, best interests. Yeah, because that then makes their platform their product too specific and they need to take this more overhead view and let the implementers like ourselves really deal with the specifics. So they need us to give us the tools so we can do the chiseling on the rock. They should be taking that high view across the entire platform. So I might even say something.

Yeah, no, I was going to say almost on the point of innovation is does innovation come more from the implementers often than the vendor? And then on the other end of it, we see a lot of decoupling of services, microservices, APIs that are product based and you pick them. This almost goes away from where you buy one system, it's all in one, and it does it all. That was almost an example of a vendor as implementer. So I don't know where to go with that innovation all in one, but kind of had me thinking there.

Well, I think, as you said, the sort of composable architectures that we're seeing now that brings in. More challenges to an implementer, because now you're not knowing one toolset before, you might have just been like, we're completely in this one technology ecosystem, that's all we need to know about. But now with the composable set up, you know you need to start needing to know about half a different payment providers, three different e-commerce systems, half a dozen different masses. So the challenge of the implementer is having this a range of tools. But at the same time, the advantage of that for the environment is you get this great exposure how to do things in different ways. Now your knowledge base, the way you learn how to implement things gets pushed and stretched. So when it comes to actually building a better product for the customer in the day, you have, you know, so many more options. You have so much more experience that you can actually give them a better view of what's out there and then pick the tools that work best for them because you just experience so much more and you're not tightly coupled to a rigid stack that's been given to you by a specific vendor.

Awesome. That was a good quick 10 minute video, guys, explaining the difference between a vendor and implement a thank you so much. No problem.

If you have any questions, please get in touch with me. @akshaysura13 on Twitter or on Slack.