Why the three-team conversation almost never produces the right answer, and what the bad decisions look like up close. This is part 2 of the 3 part series.
What Maturity Actually Looks Like Across All Three Teams
The most functional MarTech decisions I have seen happen when all three teams have developed a specific kind of maturity. Not technical maturity alone, or commercial maturity alone, but an organizational maturity about how to evaluate tradeoffs honestly across disciplines.
Engineering maturity in this context means the team can look at a vendor CDP and say: we could build something equivalent, and here is what it would actually take. Not the sprint estimate. The real estimate, including the on-call rotation, the compliance layer, the edge cases in identity resolution, and the cost of maintaining it while also shipping the rest of the roadmap. It also means being honest about the things the vendor has already solved that the team genuinely does not want to solve. Delivery rate optimization for large-scale email sends. Consent management across jurisdictions. Real-time event processing at volume. Some of this is plumbing the team should own. A lot of it is infrastructure that already exists and is not a differentiator.
Product maturity means something different. It means being able to articulate what the business actually needs from a tool in twelve months, not just what it needs today. A journey orchestration platform that fits perfectly for a team of two marketing managers does not fit the same team at twenty. The data model that seemed flexible in the demo is often much more rigid in production. Mature product thinking includes the question of what migration looks like before the tool is selected, not after the contract is signed.
Marketing maturity is often the hardest to develop, because marketing teams are evaluated on campaign outcomes and speed, not on infrastructure quality. A mature marketing organization understands that asking engineering to build a bespoke personalization engine has a cost measured in other things that do not get built. It understands that vendor consolidation in the CDP and analytics space is real, and that a tool selected in 2022 may look very different in its capabilities, pricing, and roadmap by 2025. And it understands that the gap between what a vendor demo shows and what production actually delivers is almost always larger than expected.
When all three teams have this kind of maturity, the decision-making conversation changes character. It becomes less about advocacy and more about calibration. Engineering says: here is what we can realistically build and maintain, and here is what we should not. Product says: here is what the business needs in the near term and where the requirements will evolve. Marketing says: here is what we need to move at campaign speed, and here is the ceiling we will hit if the tool cannot grow with us. That conversation, held honestly, usually produces a reasonable answer. The problem is that it is rare.
The Things That Make It Hard
Even the most well-intentioned teams make bad decisions. Not because they are not aligned, but because the conditions under which they are making decisions are genuinely difficult.
The information asymmetry problem is real. Vendor sales teams are extremely good at their jobs. They know which features to demo based on the questions you ask. They know which competitors to preemptively address. They have case studies for every objection. On the other side of the table is a product manager or an engineering lead who has maybe evaluated two or three CDPs in their career, is relying heavily on G2 reviews and analyst reports that are six months out of date, and is trying to make a decision under time pressure. The information asymmetry in a mature vendor evaluation is enormous, and it is structural, not a failure of effort.
The requirements problem compounds this. MarTech requirements are almost never fully known at evaluation time. You know what you need today. You have a rough sense of what you will need in a year. Beyond that, you are guessing. Vendors know this and write contracts accordingly. The feature that closes the deal is available in the current tier. The feature you will need in eighteen months is in the enterprise tier, which is a different conversation entirely.
Internal alignment is its own challenge. Engineering has a technical preference. Product has a roadmap preference. Marketing has a timeline preference. Finance has a cost preference. None of these are unreasonable. All of them pull in different directions. In organizations where the MarTech evaluation does not have a clear owner with authority to make the final call, decisions get made by committee, which usually means the decision that produces the least internal friction rather than the one that serves the business best. The CDP that engineering hates but marketing loves and finance can justify gets bought, and engineering’s concerns go into a Confluence page that nobody reads again.
The migration aversion problem is subtle and expensive. Once a tool is in production, moving off it requires effort that competes with everything else on the roadmap. So teams stay longer than they should. A DAM that was the right call in 2021 is still running in 2024 because the migration is a six-month project and there is always something more urgent. The tool degrades in relative quality as the market moves and it does not. The cost of staying grows. And then the migration, when it finally happens, is more disruptive than it would have been two years earlier because the tool is now more deeply embedded.
The Anti-Patterns Nobody Warns You About
Most of the writing on build vs buy focuses on the decision itself. Less attention goes to the failure modes that follow a decision that was technically correct but executed poorly.
The Double Build. A marketing team buys a CDP. 12 months later, a frustrated engineer builds a lightweight customer data pipeline because the CDP’s API is too slow for real-time use cases and the contract does not allow the data export they need. Now there are two systems that both claim to be the source of truth for customer identity. The CDP has the consent and suppression data. The homegrown pipeline has the real-time behavioral events. Audience definitions built in the CDP do not match the audiences the engineering team is querying. Campaign performance looks different depending on which system you measure from. Nobody planned for this. It emerged from a series of individually reasonable decisions, each of which seemed fine in isolation.
The double build pattern usually appears when the bought tool is good enough for some use cases but not others, and the team lacks either the authority or the appetite to replace it. Instead of making a clean decision, they add around it. The homegrown layer starts small. It grows. And eventually the organization is maintaining both systems indefinitely, paying for the vendor and paying the engineering cost of the custom layer, with the additional hidden cost of reconciling data between them.
The Half-Migration. A team decides to move from one journey orchestration platform to another. The migration plan is clear: move all active journeys to the new platform, deprecate the old one, done. Six months in, eighty percent of the journeys have migrated. The remaining twenty percent are old, complex, and owned by a team that has since reorganized. Migrating them requires understanding campaign logic that was never properly documented. The old platform keeps running because shutting it down would break things nobody has fully mapped. The new platform is paying full licensing. The old platform is paying full licensing. Both are being actively used. The integration between them is a webhook nobody fully understands.
Half-migrations are more common than complete migrations in MarTech. They happen because migrations are scoped optimistically, resourcing gets pulled partway through, and the last twenty percent is always the hardest twenty percent. The teams that avoid them treat migration completion as a first-class deliverable with a deadline, not as something that will happen eventually when there is time. There is never time. You have to make time.
There is always a time and place for everything. Part three helps you understand what time and place are right to build-then-buy or buy-then-build. Stay tuned for the third part!
Leave a Reply