drss

Here’s a free excerpt from the latest draft chapter of my upcoming data modeling book. Here, I cover some differences in selling in Enterpriseland and Productland, and some anti-patterns I’ve either personally committed, or observed firsthand. I feel it’s important for practitioners to know how to sell, so making this free for all.

Please leave a comment if you feel I’ve missed something important. And if there are grammatical or similar errors, please leave a note here.

Happy selling,

Joe

Practical Data Modeling is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

Now that you’ve got a lay of the land, you need to sell data modeling to stakeholders. This is notoriously difficult. Here’s the hard part - data modeling is often invisible work, and invisible work rarely gets funded. To secure buy-in, you need to effectively sell your idea. Not in a sleazy way, but translating your work into things that stakeholders value.

Selling a data modeling initiative requires a fundamentally different approach depending on the audience and the directness of the model’s connection to revenue. The closer the model can be tied to revenue and user impact, the easier it will be to get buy-in for data modeling. Conversely, if the value of data modeling is unclear, it will be harder for stakeholders to support the investment in modeling.

Given the importance of situational awareness, you need to understand the game you’re playing. Understanding the notion of playing offense or defense is crucial. Selling in Productland (offense) is different from selling in Enterpriseland (defense). Let’s go through each situation.

Selling in Productland

In Productland, the data model is not just a backend tool or nice-to-have. It IS the product, or at least a critical component of it. The end-users interact with an application powered by various data models. Think of recommendation engines on an e-commerce site, personalization features in a SaaS application, an LLM chatbot, an AI agent working on the user’s behalf, or the data fed to a customer-facing analytics dashboard. The link between the model and revenue is direct and measurable.

Here, you’re selling direct business impact in a few core areas - revenue growth, customer experience, or competitive advantage. You’re playing offense, and the name of the game is about growth. Every conversation should tie back to a key top-line metric, such as revenue growth, NPS, or CSAT scores. Data modeling is not a cost center; it’s a revenue-generating investment.

Here are a few key stakeholders to consider:

Product Managers. They are obsessed with user engagement, conversion rates, and feature adoption. Sell them on the new product capabilities that a better data model will unlock.
Chief Marketing Officer (CMO). Their goals are tied to customer acquisition, lifetime value (LTV), and churn reduction. A data model can help them with hyper-personalization and more effective targeting.
CEO/C-Suite/Board. To capture the interest of these individuals, emphasize innovation and the establishment of a robust, defensible market position through data. This is particularly relevant given the intense focus among C-Suite executives and boards on leveraging AI to enhance various business functions, a process in which data plays a central role.

When discussing data modeling with these stakeholders, focus on metrics and the timeline for success. Don’t say, “We need to refactor our data model.” Even if those words mean something to stakeholders, you’re not giving them a reason why they should invest in your initiative.

Instead, say something like, “By restructuring our user interaction data model, we can build a real-time recommendation engine. We project this feature will increase the average order value by 15% and lift user engagement by 10% within six months.” This statement is crisp and informative. It captures an expected return on investment (ROI) along with a timeline. And it’s a good sign if a stakeholder asks you, “Why not 2 months instead of 6?” This question is a buying signal. It means you have successfully shifted the conversation from “Should we do this?” to “How can we do this faster?” Your focus now moves from selling to managing expectations and negotiating resources.

Selling in Enterpriseland

Selling data modeling in Enterpriseland is about selling operational excellence. Here, the game is usually defense. You’re looking for ways to improve efficiency, mitigate risk, and save money. Your pitch should center on how a well-structured data model reduces internal friction and waste. The ROI is framed in terms of saved hours, reduced errors, and better, faster internal decision-making.

Here are some key stakeholders and their motivations:

IT/Technology Leaders. They manage the internal systems and applications that power the organization, focusing on reducing technical debt, enhancing system performance, and ensuring data governance and security. Sell them on a future of easier maintenance, scalability, and lower total cost of ownership (TCO).
Business Unit Leaders (e.g., Head of Finance, COO). These individuals are concerned with the speed and reliability of their reports and use this information to make informed decisions. You sell them on “trustworthy numbers” and reduce the time their analysts spend wrangling data instead of analyzing it.
Compliance and Risk Officers. Their world revolves around data governance and management, data lineage, privacy (like GDPR/CCPA), and auditability. An explainable and robust data model is a direct solution to their biggest headache, namely, avoiding regulatory issues.

When selling data modeling in Enterpriseland, avoid saying stuff like, “We need a canonical enterprise data model.” This sounds cryptic, and such efforts are notorious for being never-ending, death-slogging endeavors. Say something like, “An adjustment to our data model will eliminate the discrepancies we see in the quarterly sales and marketing reports, saving both teams an estimated 120 hours of manual reconciliation each quarter. Finance also relies on these reports, and has two full-time staff members spending 80 hours each quarter manually sifting through the data. A better data model also reduces our risk of misreporting financial results, which can lead to costly fines and penalties. We can deliver the core components of this data model within two months with one dedicated modeler.”

Here, your pitch is about turning invisible costs into visible savings by removing manual toil and freeing up valuable headcount for higher-level work. However, stakeholders in Enterpriseland are rightfully wary of projects that become “never-ending death slogs.”

Data modeling in Enterpriseland suffers from baggage that it’s slow, time-consuming, and invisible. This is where you show how things are different now. Especially with modern AI-assisted tooling, the two-month timeframe can likely be substantially reduced. Whenever possible, leverage AI to accelerate the modeling process and deliver value and visible wins iteratively. This directly counters their fears and reinforces the “Show, don’t tell” principle. By delivering the first set of wins for your stakeholders in weeks, not years, you build the trust and momentum needed for the broader initiative. This might sound like an aggressive timeline, but it’s better than the alternative, where stakeholders lose patience and interest.

Anti-patterns for Selling Data Modeling

The root cause of most failed sales efforts is nobody cares. Too many data modelers focus on the technical aspects of the data model rather than the business outcomes it enables. Yawn. Good selling is often about knowing what NOT to do. Unfortunately, technical practitioners usually struggle to communicate effectively with non-technical individuals. Understanding the anti-patterns is just as critical as knowing the best practices. These are the common traps that cause data modeling initiatives to stall, get rejected, or fail to deliver value even if approved.

Leading with the “What” and “How,” Not the “Why”

The fastest way to lose your audience is to present them with a barrage of implementation details that exceed their understanding. Sadly, this is a classic trap many practitioners have fallen into. They might walk into a meeting with stakeholders and immediately present a complex model diagram, throw out terms like normalization, primary keys, or specific data modeling techniques. This is the “how” and “what” of data modeling, but not the “why.” The practitioners care about this, but trust me, nobody else does. Stakeholders are concerned about the problems the data model will address for them.

Never start with technical or implementation details. Start with the business problem or opportunity, stated in the stakeholder’s language. Only after you understand the problem or opportunity from the stakeholder’s perspective should you start work on the model. And when you present your progress and updates to stakeholders, always frame things in terms they understand.

The One-Size-Fits-All Pitch

Here, you use your Productland pitch in Enterpriseland, or vice-versa. For example, you might pitch a model’s impact on customer LTV (offense) to a CFO whose primary goal for the quarter is reducing operational overhead (defense). This shows a complete lack of situational awareness. The pitch doesn’t align with the audience’s immediate priorities or incentive structures. Again, know the game you’re playing. Before any meeting, know if you’re selling to an offense- or defense-minded stakeholder and tailor every talking point to that worldview.

Selling “Data Quality” or “Single Source of Truth” as the End Goal

“We need to model data to improve data quality” seems like a great thing. The problem is that “data quality” is an abstract concept that even hardcore data practitioners cannot always agree on. And “single source of truth” sounds great in theory, but what exactly does that mean, and is it achievable? Both of these are still technical means to an end. For a business leader hearing these phrases, they’re likely thinking, “So what?” Poor data quality isn’t their problem. The consequences of poor data quality are their problem.

The antidote is constantly connecting the improvement to a tangible outcome. Instead of “this model will improve data quality,” say “this model will eliminate data discrepancies that caused us to miscalculate our inventory last quarter, saving us an estimated $500k in carrying costs.” Any reasonable business person hearing this will immediately see the value in modeling.

The Ivory Tower Model

The Ivory Tower Model describes a scenario where a modeler creates a theoretically perfect model in isolation. This design process typically occurs without input from outside stakeholders. But hey, it’s “perfect.” This approach frequently fails because the resulting model is impractical or impossible to build given existing system constraints. Or, nobody understands what the model is supposed to convey because they weren’t involved in shaping the model’s meaning or direction. Furthermore, these Ivory Tower Models can become overly complex and unusable for business users, leading to low adoption rates.

To counteract this, data modeling should be treated as a collaborative effort, with full participation and input from all stakeholders. The modeler and stakeholders - “the business,” software and data engineers, data scientists, and analysts - should all be involved from the project’s inception. This model strikes a flexible balance between theoretical ideals and pragmatic reality.

The “Field of Dreams” Fallacy

The “Field of Dreams” Fallacy is “build it and they will come.” In data modeling, this occurs when a project is initiated without a specific, committed downstream consumer or application. This means building a data model based on anticipated, rather than explicit, business needs. This approach often fails because, without a clear use case, the project lacks urgency and a definition of success. Consequently, the resulting model may not be needed or may not adequately fit the use cases that eventually emerge.

To avoid this pitfall, find a “launch partner.” This involves identifying a business team with a specific project and a deadline, and then collaboratively building the data model to serve their immediate needs explicitly. This ensures a clear purpose, defined success metrics, and a guaranteed consumer for the data model.

Data Modeling Without Executive Support

Many data modeling efforts fail due to a lack of stakeholder support and sponsorship. Here, there is an attempt to launch a data modeling initiative as a purely grassroots, IT-led effort, lacking a senior business sponsor with a vested interest in its success. This approach often fails because data modeling initiatives are fundamentally about change management. They inherently cross departmental silos and challenge existing processes and structures.

Without the crucial backing of an executive sponsor, such initiatives become entangled in political disputes and turf wars. An executive sponsor provides the necessary “air cover” to break down these political barriers and effectively advocate for the project’s value. Without this support, the initiative will inevitably get bogged down and eventually cease to exist.

To counter this, the most crucial step is to secure a business leader who actively experiences the problems of the current state. This individual should become the champion of the initiative. Their business case for change will always be more compelling and powerful than any purely technical justification, ensuring the project gains the necessary traction and support to succeed.

Let’s next look at how to make sure your data model endures. Let’s next look at model ownership, change management, and evolution.