A CDP Premortem: 10 Lessons Learned Before Implementing a Customer Data Platform.

A formal definition presents a Customer Data Platform (CDP) as a tool that centralizes and unifies customer data from multiple sources to offer a complete and coherent view of the customer.

In most conversations, however, the definition offered is more like "a cocktail shaker where you pour in all the customer data and serve each team what they want to drink." This lack of precision isn't due to ignorance on anyone's part; it stems from the importance of creating a shared understanding or vision. Because when it comes to implementation, the problems aren't so much about the data itself, but everything else surrounding it.

Using metaphors in technical implementations helps all teams communicate objectives, obstacles, implications, and dependencies, which is especially crucial in projects with such a cross-functional scope.

As the project advances and work teams are formed, the value of metaphors gives way to the specifics of deliverables. However, they become important again during check-in sessions or cross-departmental demos.

First lesson from the premortem: Failing to make an effort to communicate inclusively can leave out key players.

A major challenge when creating a team for a CDP assessment is inherited from the very structure of the work team itself. Teams from technology, business, legal, or customer service will have different approaches to the opportunities and challenges of implementing a CDP, as well as varying amounts of time, knowledge, and short-term needs.

This is no different from any other highly complex project implementation; it requires a sponsor, an outcome, an owner, the voices of different departments, and a timebox to define the first phase of the project.

The outcome of this phase is to explain the potential impact to the various stakeholders, outline dependencies, highlight opportunities, and provide the "peace of mind" that no final decisions are being made yet. Within this phase, a RACI matrix is a good tool to assure all team members that any future decisions will be endorsed by them, even if they've been disconnected for a while.

A timebox for this process is important to avoid getting lost in the details or bogged down in overly specific requirement gathering.

The stakeholders who will be part of the project should be identified by the end of this phase.

Second lesson: Collect all internal pains from stakeholders at the very beginning of the project and establish processes for keeping them informed and consulted.

You´ll thank me for this later. 😉

Third lesson: The project owner must have a very clear understanding of their role in managing those pains.

With the team formed and project objectives identified, different paths emerge depending on which teams have led the initiative. Frequently, technical teams tend to approach the process by inventorying data sources, while teams that identify with business and data keep the focus on the outcome, which is materialized in use cases and a prioritization matrix.

Each path has different limitations. The process that starts with inventorying data sources often simplifies a proof of concept. In contrast, the process designed from business cases creates more traction and buy-in among stakeholders, leads to higher-value use cases, but requires a greater capacity for abstraction and trust in the company's commitment and technical capabilities.

In cases where an extended kick-off has been held with the different area managers, working in parallel is very efficient, although it is highly recommended to manage the data source inventory with a template that facilitates later integration.

Fourth lesson: Communication regarding planning, deliverables, and decisions must be established from day one.

The project's outcome is never just to implement a technology or launch a campaign. The success metric usually has an economic aspect, broken down into customer metrics (NPS, churn, upsell), acquisition metrics (CTR, CPA, CAC), or efficiency metrics (Time to Purchase or other SLAs). This reflection is fundamental before you start exploring technologies, as there are often simpler and certainly more economical ways to achieve those goals.

Fifth lesson: Don't fall in love with the solution; you might be making a mistake. A CDP may not be what you need.

Once you're pursuing the outcome (and this also applies to the various alternatives to CDPs), it is essential to understand the information flows your company will activate and the different integration points.

• For brick-and-mortar businesses, solutions like Wapping can help project multi-distributor attribution in a sales process (enabling multi-distributor loyalty systems).
• For banks or platforms where controlling information flows is critical, Tealium offers various control solutions through its different tag management systems.
• For organizations with smaller teams that want to run propensity models directly on the platform, Treasure Data is a good solution.
• In cases where the company has developed a centralized and governed datamart, a Census or Hightouch can facilitate integration, accelerating the time to value.

Each platform has a unique value proposition and scale based on different parameters (POS, Events, Integrations, modules)... and to all that, you have to add the commissioning models of the different implementers. A projection of fixed and variable costs at this point can simplify the decision.

Sixth lesson: Understanding the rules of implementation, cost, and future maintenance is fundamental.

At this stage, it's common for technology vendors to introduce you to their implementation partners in each country. Often, you've just introduced another sales agent into your decision-making process instead of a partner who will help you choose. And even if they mention different technologies they work with, their commission model will ensure they don't stray from the one that generated the initial lead.

(The one and only sales pitch: At Paradigma, we don’t charge a fee/commission on our agreements with CDPs / Reverse ETLs, as we want to ensure the decision is customer-focused and not altered by escalations.)

Seventh lesson: The timing of when you talk to a consultant will have a huge impact on the relevance of the solution. You don't bite the hand that feeds you.

The development or refinement of use cases happens during the final phase of the pre-sale. This is when time, impact, development costs, opportunity cost, team availability, return on use cases, future projections, and collision with strategic projects begin to materialize. It's a very common point for projects to die if there isn't prior alignment. Any new sponsor who joins at this stage is more likely to become an antagonist.

Similarly, all initial stakeholders will see the project getting closer and the need for their commitment. Make sure any new impediments are shared.

Eighth lesson: Traction among key stakeholders is the greatest asset to maintain and the hardest to recover.

Just as a very high percentage of projects end in failure, new challenges in ingestion, integrations, event persistence, new regulatory changes, people leaving the project... can jeopardize success or diminish the scope. Regular status checks during implementation will help address these challenges and maintain control of the project.

"Good stories happen to those who can tell them" (Paul Auster, writer), and in the case of process and analytics implementations, this holds even more weight. A demo with hypotheses, actions, and results is always necessary because, even if the results aren't what was initially expected, they frequently show that control over the process has improved.

Ninth lesson: A customer demo with KPIs is always a positive, regardless of the outcome.

After the first delivery of use cases, teams from customer service, marketing, and operations tend to identify new needs, impacting prioritization, budget allocation, and timelines. If the ground rules were set correctly from the start, it's easier to "projectize the BAU" (Business as Usual).

Tenth lesson: The day after is when the real project begins.

The development to implement a centralized customer solution is not so much a technical project as a change management project. As such, the challenges come less from the technical side and more from the human side.

It's never a "few months" project. Even in the world of reverse ETL, the project always entails a BAU.

The way and time you choose an implementation partner will heavily influence the technological decisions for an outcome that is never "implementing a technology."