Do You Need a Proprietary Martech Stack?

A proprietary (or first-party) martech stack is one a company builds, typically bespoke to its needs. This could be the entire martech stack or one specific application. For instance, a company might use internal resources to create its own database or CRM rather than subscribing to a third-party tool. 

Before the explosion of martech, these home-grown applications were very common. These types of proprietary applications are also popular among tech-savvy companies that are pushing the envelope when it comes to marketing and advertising, and they have not been able to identify any vendors to help them. 

say pleaseHow to Get Permission to Market the Names of Your Customers

Benefits of a Proprietary Martech Stack 

First, the functionality and features that your tool has can be fully customized and unique to the needs of your organization. For example, if you need a marketing tool to integrate and populate data in many other internal systems, you can create that from the start. 

Building martech internally also has the advantage of having full control of the future roadmap of the technology. If there are features that an organization needs in the future, rather than rely on a vendor to build the features according to their timeline, teams can align resources and prioritize these features. 

Another potential benefit is cost. Organizations can save money by building their own tools, especially if they have the development capacity to do so. Rather than pay an ongoing subscription fee, once an internal Martech tool is built, the only ongoing fee would be maintenance and server costs, which should be minimal. 

Finally (but importantly) is the potential benefit to security.  While many companies place high importance on data security, some vendors do not. In addition, your organization may have higher standards of data security than the typical martech vendor, and building an internal martech application offers more control around how data and customer information is protected. 

Challenges of a Proprietary Martech Stack

First, it typically takes long stretches of time to scope, plan, develop, and test new internal tools. While an internal application could take months, or even years to implement, subscribing to a third-party martech tool can take a few weeks (or even a few days for more agile organizations and for simple use cases). 

The next potential downfall is a lack of technical talent, as well as product and development resources to build applications internally. Development typically requires product managers and software engineers, as well as user experience and user interface resources to create. These resources are expensive, and can be particularly difficult to secure for smaller organizations. 

Another challenge with proprietary martech is technical debt. Technical debt has been described as “what results when development teams take actions to expedite the delivery of a piece of functionality or a project which later needs to be refactored.” In other words, it’s the result of prioritizing speedy delivery or perfect code.

This is a common problem because external products (those built for external, paying customers) tend to be prioritized over internal products. Development teams may not make every effort to build internal tools in a sustainable, scalable way, and what often results is technical debt. 

We also see lack of innovation from internal tools. Marketing teams may be tempted to scope internal services just according to their needs and pain points today, but may not be looking years into the future to see what they will need. Despite this, martech vendors typically excel in innovation, as new features and capabilities help them sell more subscriptions. 

Finally, a lack of integration is a problem with internal martech tools. While some internal development teams may build open-source platforms that can integrate with other applications, many teams will simply build an internal tool that meets an immediate need. This is a downside, especially compared to some of the mainstay martech platforms that have created marketplace offerings that connect to hundreds (sometimes thousands) of external applications. 

3 Elements of a Martech Stack 

These three tools are disproportionately important in a martech stack: the marketing automation platform (MAP), the customer data platform (CDP), and the customer relationship management system (CRM). 
 

Customer relationship management System (CRM)

The CRM is a key component of the martech stack because it holds prospect, customer, and revenue information. Though not a dedicated tool for the marketing team, the CRM is the starting place for many campaigns. The CRM enables marketers to target prospects and customers based on demographic and firmographic information as well as activity and buyer stage.
 

Marketing automation platform (MAP)

Many B2B companies considered the MAP to be the marketing system of record. This is because all of their prospect and customer data exists in the database of the MAP, and many of the digital interactions can be tracked and aggregated in the MAP. For example, many MAPs track website visits, landing page visits, email engagements, and more, and can tie campaigns to pipeline and revenue data in the CRM. Since many marketing campaigns involve the contact information and assets that exist in the MAP, many marketing teams heavily rely on this piece of technology in their martech stack. 
 

Customer data platform (CDP)

The CDP is becoming an increasingly popular marketing system of record. This is because the CDP extends the capabilities and data of a CRM and MAP and brings it into one unified system. 

One of the key benefits of the CDP is to take all the different customer data and touchpoints, particularly product usage and advertising data, into one system for better campaign targeting and activation. By starting with customer data, campaign targeting is greatly improved as well as driving customer insights.

More Martech Know-How5 Marketing Analytics Strategies for a Privacy-Driven World

Pitfalls of Building a Martech Stack 

While planning and building a marketing technology stack can be an exciting undertaking, there are many things that can go wrong along the way. Be wary of the following pitfalls when building your tech stack. 
 

Shiny object syndrome

Shiny object syndrome is when marketers are attracted to the latest tool, channel, or platform just because it is new. For example, this could be a new, untested social media channel, tactic, or in our case, a marketing application. Shiny object syndrome can lead your overall marketing strategy astray or completely derail what you are trying to accomplish.
 

Shelfware

Shelfware refers to technology that is not used and remains on the metaphorical shelf.  An example would be a new martech application that a single marketer purchased without getting buy-in from the larger team. Shelfware is a waste of money and can be demotivating as stakeholders will be reluctant to try new tech in the future, citing the previous shelfware example as precedent.
 

Lack of talent

Many business leaders don’t understand that martech requires expertise. The implementing and proper management of martech requires skill and due diligence. This is especially the case for some of the larger platforms like MAPs, CDPs, CRMs, and analytics tools, which require an experienced technology specialist. If a team is unable to secure this talent in-house, search out a consultant or agency to assist in martech implementation. 
 

underestimating timing for Martech implementation 

At the enterprise level, projects like these can take at minimum six months to complete. While more aggressive timelines can be met, the best implementations are well scoped and planned, with much input from stakeholders along the way. Moving too fast when it comes to martech leads to poor implementations, missed deliverables and technical debt.
 

Inconsistent and disparate data

One of the often-overlooked problems that martech managers face is inconsistent and disparate data. When data is not consistent across platforms, it can impact targeting (uncertainty around who to send/deliver to) and reporting (differing/unreliable cross-system metrics). Data inconsistency compounds over time, so have a plan to capture data in a consistent way, and to consistently make efforts to standardize the data.
 

Decentralized Martech

For larger companies, it is tempting to decentralize marketing technology, meaning that martech is owned by different groups and/or regional offices. Without centralized oversight into which martech tools a business is using, teams may buy duplicate tools that serve the same function. Decentralized martech can also lead to a poor customer experience because of disparate data.
 

Shadow IT

Shadow IT refers to when employees purchase technology that hasn’t been approved by IT. In martech, the same occurs when marketers (or sometimes salespeople) purchase martech without the knowledge of the team that is responsible for all the technology. While there is some overlap between this pitfall and the decentralized martech pitfall, shadow IT is especially tricky because the martech team may never know about the existence of tools, and may never have the opportunity to monitor for compliance, security, and customer experience impact. 

The sales technology space includes sales automation and cadence tools that allow salespeople to operate as mini marketers. Because these tools allow sales to reach many people at once, some might not see these tools as officially martech. Still, it is important that marketing manage these tools and touchpoints. 

The best option would be for the martech team to assume ownership of these tools, and to deploy many of the governance strategies outlined in this book. If this isn’t possible, marketing should partner with sales and sales operations to ensure customers receive a respectful, thoughtful customer experience regardless of the tools being used.

Excerpted from Chapter 4 of The Martech Handbook by Darrell Alfonso ©2022. Reproduced and adapted with permission from Kogan Page Ltd.