The Best Martech Stack Is The One That Fits Your Needs

Few quests are as hopeless as trying to restore the meaning of a term whose use has changed over time. I’m not talking (for once) about Customer Data Platforms, but the idea of a “martech stack”. Originally, the term was used in the same way as tech stacks in general: “the collection of tools, frameworks, programming languages, and platforms used to build and run a web or mobile application.”  Stacks were distinguished by their components: developers might choose a LAMP stack (Linux, Apache, MySQL, PHP), a MEAN stack (MongoDB, Express, Angular, Node.js), a WIMA stack (Windows, ISS, MSSQL, ASP), etc. Each had its strengths and weaknesses, and no doubt its fanatical advocates. But, while there was a general framework that defined the types of components in any stack (broadly described as infrastructure layer, database layer, application layer, and presentation layer), there was no particular sense of one stack being "correct".

Martech stacks were originally described in the same way: as the set of tools used by a particular company for its marketing systems. Thus, for example, the Stackie Awards introduced by Scott Brinker in 2015  asked companies to illustrate the tools that they used, with an emphasis on creative presentation. But, more recently, the guru-sphere has been featured any number of proposals for how “the” martech stack should be defined, each slightly different but generally featuring broad data, decision, and activation layers.  The differences are mostly in how the layers are named and how they are subdivided into smaller components. Some also list products in each category, some don’t.*

It would be uselessly pedantic to try to restore “martech stack” to its original meaning. But I do think it’s worth arguing that there is no one correct martech stack design today, and never will be. As any guru will freely acknowledge, the right stack for any given company depends on its unique situation. The value of model stack designs is they offer is a list of capabilities that must be delivered to support an effective marketing operation. Everyone needs data, everyone needs decisions about how to treat customers, and everyone needs activation tools to execute those decisions. Having detailed lists of requirements within each layer is extremely useful in finding gaps in your current toolkit. 

Where the idea of one “correct” stack design causes problems is when it specifies, directly or implicitly, how delivery of those capabilities should be organized. Should all data be loaded into a single warehouse, or should it be read directly from source systems, or should there be a mix of direct access and warehouse access (including, quelle horreur, multiple warehouses)? Actual practice will nearly always end up with the mixed solution but the ideal martech stack diagram won’t hint that’s a valid alternative. The danger is that taking the diagram literally could push companies to adopt a solution that is in fact sub-optimal.

Anyone with the slightest practical experience recognizes that a simple stack diagram can’t capture the nuances of the real world. But, beyond a pro forma warning that is easily ignored, what can model stack designers do drive home the point that alternative implementations are viable?

I suggest that instead of presenting a single stack diagram, they offer several designs that illustrate different options. All would still draw on the same underlying set of required capabilities; these are the layers of the stack framework that don’t change regardless of how the stack components are organized. The diagrams would differ in how the components are connected:

• Database centric: a stack with a single data platform that feeds multiple decision and activation engines.
• Decision centric: a stack with multiple data platforms feeding a single decision engine, which feeds multiple activation engines.
• Activation centric: a stack with multiple data platforms feeding multiple decision engines, which feed a unified activation system.
• Integrated: a stack with a one system that combines data, decision and activation.
• Network: a stack with multiple data, decision, and activation engines all exchanging data and workflows. (I’m skeptical that this will work but do see some people proposing it. My take:“It’s the stack of the future, and always will be.”)

More variations are possible if the layers are divided into smaller components. The point isn’t to come up with the optimal arrangement but to find the arrangement that best fits with a particular company’s current and planned systems. Another approach, closer to the original meaning of “tech stack,” would illustrate alternatives using real products, recognizing that different products provide different sets of capabilities and often cross the boundaries between stack layers. This would make it much easier for users to identify gaps in their existing stack, which is one of the main uses for a stack diagram.

In fact, the reason I’ve been thinking about this is I’m pondering the next generation of the CDP Institute RFP Generator and Vendor Selection tool(s). As I wrote in my last post, the current tools focus almost exclusively on system features, making the implicit assumption that the architectures supporting those features are all roughly the same. Since that’s clearly no longer the case, we need to define alternative architectures and the system attributes that differentiate them, so we can collect those attributes from vendors and match them against user requirements. The scope of capabilities provided by a system is clearly one set of attributes to consider. Types of integration standards supported (specific APIs, MCP, etc.) is probably another although I’m not (yet) sure how to capture them. Compatibility with specific platforms (Salesforce, Adobe, Snowflake, etc.) may also be an option although I’ve always avoided that because the answers change so quickly. I suspect there are others, so am open to suggestion if anyone reading this has any ideas.

In any event, putting my personal needs aside, I think we'd all benefit from an industry discussion that focuses less on creating the perfect martech stack diagram and more on how users can build the stack that best fits their needs. 

___________________________________________________________________________

* Conveniently illustrating my point, the Stackie competition itself ended in 2025. It was replaced with a State of Your Stack Survey that seeks to “benchmark” common stack components rather than illustrate individual stacks. QED. 

System Selection Isn't About Features Anymore

I recently explored rebuilding the CDP Institute’s venerable RFP Generator with a vibe coding platform. The project was a success – Replit* took about one hour** to build and deploy an attractive, bug-free system that is significantly more capable than the original.***

But looking closely at the RFP Generator – which has been running with virtually no maintenance for six years – also raised the obvious question of how it should be updated. The current focus of the system is features: users specify their target use cases and the system returns a list of the features those cases require; it then suggests vendors based on how many of those features the vendors provide. That made sense when most systems were largely self-contained bundles of capabilities. Features were the main differentiators and collecting information on each system’s features was the main task of a vendor selection project. Even hands-on evaluation tools like pilot projects and bake-offs, which have to some extent replaced or at least supplemented the traditional Request for Proposal, are still largely aimed at understanding system features more clearly.

But systems today are anything but self-contained. They are components of a larger architecture, more-or-less-fluidly exchanging data and participating in workflows that span different systems, departments and even companies. Any new software has to fit into this larger ecosystem.  

This shifts the focus of the purchase process to integration and compatibility. Understanding those is important because different systems are built to play different roles: some are designed to be a company’s primary platform (such as a data warehouse or marketing suite), some are designed to supplement a specific other platform (such as applications on a vendor’s app exchange or an optional module in a platform system), and still others are designed to work with any system that supports the same integration methods.

This means that delivering the right features is no longer enough. Systems must deliver the right features in a way that fits with the company’s larger system architecture. Compatibility with that architecture is the first screen that must be applied to any potential vendor list. In fact, since new tools often make it practical for users to add their own features to a purchased system, finding exactly the right set of features is considerably less important than it used to be.

The CDP Institute’s existing tools already accommodate this change to some extent. We capture whether a particular CDP works with its own database or connects to an external warehouse, which is one of the key architectural differentiators. We also ask whether a system can be installed on-premises, which is an important consideration for some buyers. The vendor selection portion of the new RFP Generator allows users to filter systems on those options. But we could surely do more to understand the different architectural options and the markers that indicate which systems are compatible with which options, and to collect and expose that information.

It's also important to recognize that new architectural options will continue to emerge. The AI-powered transformation of marketing technology is still in that early stage where the industry is trying many alternatives before settling on a standard approach. (Or several standards.) Once the industry coalesces around a few standards, it will be much easier for buyers to identify systems that match their company standard.  But it will be at least several years before the winners are clear.  This means buyers will struggle for some time to figure out which systems are compatible with their company's chosen approach.

Of course, technology isn’t the only factor that matters when selecting a system. Pricing, industry experience, professional services, typical client size, and local presence are all important considerations. The CDP Institute already captures those in its vendor data and the old RFP Generator already asks the user about them. But it would be helpful to find a way to identify some of the less concrete variables, such as cultural fit, ease of use, and skill requirements.

Ideally, a vendor selection tool would also include a user readiness assessment, to help buyers understand what types of systems are best for them, what kinds of problems they are likely to face, and maybe even what they should do avoid those problems. This is important because -- as I’ve pointed out many times in the past -- by far the most common causes of failure with new systems lie within the purchasing organization, not in the systems themselves.****

In short, finding the right system today is less about finding features and more about architectural and organizational fit. The buying process needs to adjust.  Vendor selection tools should – and I’m confident will – adjust along with it.

_______________________________________________________________________ 

* Lovable also worked very well. Botpress, not so much.

** This was after I spent a day and half prepping the data and writing detailed design instructions. It would have taken much longer if I wasn’t working with materials already assembled for the old system. Still, it would have a taken a conventional developer weeks if not months to deliver a system after they were handed those inputs. Replit cost me $20 in processing credits; conventional developer costs would surely have been in the thousands.

*** You’ll have to trust me that the system is ready to go. There’s no point to releasing it until we make additional changes in the data collected. The same goes for our Vendor Comparison report, which uses the same vendor information as the RFP Generator. Replit built an interactive version of that in just a few minutes. Woot!

****The CDP Institute does have an existing Readiness Assessment tool, although it's limited and not connected with the RFP Generator. 

Can AI Break the Hype Cycle?

Generative AI and its agentic offspring may be foundational technologies, but they are still following the normal technology hype cycle: excitement at the potential, followed by news of failed deployments, followed by a more mature understanding of what’s required for success. The third stage generally comes down to a realization that the main obstacles are organizational, not technical: projects fail due to poor internal alignment, change management, reward systems, and so on. Similarly, when it comes to customer data (and all other business data), there’s a dawning recognition that whether the data resides in a CDP, cloud warehouse, or marketing platform, the real challenge is still transforming raw data into usable information through quality management, unification, and mapping. 

We’re just beginning to see the third-stage insights from the industry’s more advanced thinkers. It's true that they’re important: the only way people will be convinced to address these issues is by seeing real data and hearing about actual experience. But they are also utterly predictable. 

What’s less predictable is that AI has the potential to remove those barriers. If AI radically changes how work gets done, then the organizational structures designed for existing business processes (and blocking progress) will change as well. For data, AI could – at least in theory – handle preparation tasks that have always been the main roadblocks to deployment. 

These are not subtle ideas and I don’t consider them particularly brilliant insights. But I also don’t see them being discussed (at least explicitly). Instead, most of the AI conversation is still about using AI to replace individual tasks within existing workflows or about creating AI-based workflows within existing organizational structures. What I’m suggesting is a clearer focus on using AI to remove the traditional roadblocks to technology deployment: in addition to redesigning organizations around AI capabilities (with a particular focus on accommodating future change), this might also mean developing AI coaches to help existing organizations with change management. For data management, it means developing AI tools to automate end-to-end data preparation. 

I will somewhat airily leave the details to people who make their living helping organizations with technology management; they will no doubt have many more and better ideas than I can offer here. My goal is simply to convince them to adopt roadblock removal as a conscious objective in their work. This is what will empower AI to deliver the fundamental changes that we all see as its potential.