Off-the-Shelf or Off-Track
Should you buy MarTech tools off-the-shelf or look to build your own proprietary systems in-house? In most cases, you should be looking to build an integrated stack of off-the-shelf modular products and limit customisation as much as possible.
I remember hearing from a colleague that he had just come off a web call. He was excited and blown away by the call. He’d been talking to the Digital Analytics team. They had five specialists, all very good in their respective fields. The company sold a complicated monthly subscription service with long online forms and lots of competition, so a good online experience was paramount. To support this, the team had a radical plan for the enterprise –they were going to completely replace back-end systems, tag management systems, and web analytics tools with their own custom in-house solution. It promised to deliver everything you could ever want, and the team had already made a start.
Fast forward a year or two, and more sensible heads had prevailed. The new plan compromised with partial customisation of the data collection method (essentially, they could control and manage their own dataLayer) and a completely off-the-shelf stack, different to what was there previously but off-the-shelf nonetheless. Years down the line, the implementation is still in progress, and it will be for years to come, but they do have what they need right now.
Specialisation
In our highly competitive, interconnected world, to succeed in most endeavours now, you need to specialise. If you sell cars, get good at selling cars – not building a custom database because it has all the fields and features you want. If something is crucial to your project and your team has existing skills in that area, then try a small project building on that capability. However, know that their time will always be directed to the side project that only slightly enables the thing that you really want to be good at. You should also choose the best tool in your Solution Design for the job and for the Project Plan as a whole.
Integration and Modularity
You want a team of tools, not a family. Each tool must be a team player with other stacks. It must play nice with other tools, which means it needs to be able to connect and integrate easily through an API. I’ve lost count of the number of businesses I’ve worked with that are now burdened by legacy systems that don’t connect to anything and are no longer being adequately supported. For this, have a CDP that does the connections piece. They specialise in creating and maintaining hundreds of API connections. Your team will be unable to maintain connections without a substantial ongoing investment.
IT People Lock-in
Don’t build an engine that only a few mechanics can work on. If you do, your company is entirely beholden to those mechanics, and if you do need more mechanics, it’s going to be very difficult to find people who can work on your custom solution. Whether external or internal support, people must also be able to use what is in place. Is your interface really going to be better than that of a major SaaS provider with libraries of user guides and training? Do you want your organisation to be beholden to key people that become absolutely essential to running your entire infrastructure?
Vendor Lock-in
Just like we don’t want to be locked into key people, we don’t want to be completely locked into specific tools and vendors. If most of our stack comes from one provider, it could be costly to move on, and there can be a good reason to move on. What if they increase the cost of the tool? What if the tool’s effectiveness falls behind the market because they stop investing in product development? What if the tool does not actually perform as you expected? What if the tool becomes illegal to use because it breaches privacy laws?
