Is Buying MarTech Too Easy?

Developing software is easy. Anybody can do it if they have the requisite coding skills. Developing good software is hard, because it requires more than just talented developers. As any successful app vendor would tell you, the most important part of any development project is the design process not the actual coding. That's not to denigrate the efforts of software developers, it's just that the process of building and maintaining a software product is so complex that a comprehensive plan is required to do it properly. Success comes as much from defining what an app shouldn't do as compared to what it should.

Buying software is also easy. It's not in anyone's interests to make it difficult, although some vendors do manage to do it with arcane and complex price lists intended to give sales reps the maximum scope to set prices according to the buyer's budget. Yet the key to being a successful technology buyer is to make the buying process difficult, by introducing many of the same planning strategies that make developers successful.

In software development, the coding is only a small part of the overall process. The same applies to buying technology. The purchasing decision is only a small part of the overall journey, and is also by far the easiest bit. Everyone knows the challenges of implementation. Understanding a technology you just brought takes time and effort that you might not have. Decisions need to be made, but few buyers know enough about what they've brought to know their impact. The roll-out of any enterprise technology is always a complex and frustrating process that always takes longer than you originally thought. There is almost always some limitation in the software that you didn't account for in your original planning. A good implementation consultant will help with this, but an external advisor can only do so much. Ultimately, it is the responsibility of the buyer to make configuration and usage decisions, the consultant is there to guide them to the right decision. Following best practice is important, but there are always exceptions. What the correct decision actually is, will frequently depend on the customer's specific requirements.

The can only happen if the buyer understands what those requirements are. It's surprising how frequently this isn't the case. Scoping what a particular piece of technology is supposed to do and selecting the right application for that requirement is a surprisingly difficult job that requires rigour and an objective decision-making process. This applies as much for a single purpose application such as a webinar platform as it does for a highly customisable CRM system or Marketing Automation Platform. There are five common mistakes made when collecting requirements for a technology purchase:

Ignoring the Existing Tech Stack

Whatever problem you're trying to solve, there is already a solution for it inside the business. The question is whether that solution is fit for purpose. Buying in new technology isn't always the answer, because that existing solution may work absolutely fine even if it isn't necessarily best practice. Even if you don't, there's probably an existing tool in place that can do what you want. Anything can be developed in house if you have enough time and resources, but sooner or later the cost of developing a fancy new predictive AI outweighs the benefits of a bespoke solution. The core sales & marketing tech stack is already fairly flexible, so make sure to consider what it can do before deciding buy in something new.

The Impulse Purchase

A typical enterprise with change control processes and multiple approval levels doesn't suffer from impulse purchases, because management or procurement will stop any attempt to buy technology without justification. Instead, what you get is one group or individual driving the buying decision to fit a vague theory of a possible business need, without actually validating with all the relevant stakeholders whether that need actually exists in the business. Internal politics is often the cause of this, but the end result is always major problems further down the line. It is essential that all stakeholders in a decision are identified, and their feedback properly considered. Write up a list of everyone's needs and concerns and make sure they're considered in the decision. These needs don't need to have equal priority, but collectively agreeing what the priorities are up-front avoids a lot of wasted time and bruised egos later on.

The All in One Solution

Every technology has trade-offs, so it's important to know what the key priorities are what is nice to have. It's good to have a comprehensive list of requirements, but at the same time, not all of them will be fulfiled by the chosen solution. Don't look for a platform which does everything, because it doesn't exist. Instead, decide what the core purpose of the technology you're looking for will be. It could have multiple purposes, but if that's case be prepared to search for multiple tools which integrate. Many of the items on your priority list will be wish list items intended to make life easier rather than solutions to a genuine business challenge. A new solution should solve some of those wish list items, but it won't be able to solve all of them. Always remain focused on the major problems that you're trying to address and avoid getting distracted by secondary concerns. Otherwise, you may find yourself implementing a solution that doesn't actually address the original business requirement.

Ignore the Technical Stuff

Integrations are never the ideal solution, but they do work and are frequently a necessity. Yet technical requirements such as administration options, API maturity and native integrations are often overlooked in the buying process. Don't make assumptions about these things because they're often incorrect. If you're relying on a specific feature being available make sure to check it actually exists before pulling the trigger on the deal. More importantly, make sure to find out how this essential feature works because there will always be limitations. Security is another thing people ignore, primarily because IT can be overly strict about it. However, if the required security or compliance checks have been glossed over or bypassed, then the relevant departments will find out later. The vendor will hate you for it, but it's worth asking the right questions up front before IT even need to get involved.

Trusting the Sales Guy

Sales won't lie outright when closing the deal, but you can you be sure there are things they're not telling you. There's a reason why customer references are a standard part of any buying decision, but even that can't be trusted. Vendors get to chose their happiest customers to provide the reference, when what you really need to know is the problems that unhappy customers have. Seeing the platform when you don't have the vendors Sales teams guiding you is important. Proof of concepts are frequently too late for this, because the decision will effectively have been made at this point. Too many people are too invested in the success of a purchase for a POC to fail, unless there is a good reason. To this end, always consider what the failure conditions for a piece of technology, what should it do and what should it absolutely not do. Then make sure these are possible before making a commitment.