I have sold data modeling in Productland and Enterpriseland and you described it well. Product - you sell the opportunity (be aware - much more delivery pressure beyond data model), Enterprise - you sell the better use of resources (easier to prove).
There is one trick I used in Productland - hijacking a business initiative. Let's say there is a push for a specific new marketing initiative like the renaissance of account-based marketing that requires a different dataset. This is your opportunity to provide the dataset, but with the time and maybe project budget it allows to work on the data model for this as first implementation and then use it to expand to other areas.
This was very helpful, Joe. I appreciated the framing of talking points for both the Enterprise-land and Product-land groups, as well as being aware of which group I am speaking to.
In the last several months, I've led a push to begin treating our domain semantic models as data products to allow engineers as well as BAs to move closer to the business problems, while also inviting the business leaders into our limited resources, given the business domains we support. This includes our first-ever cross-domain prioritization to ensure the business was aligned on the problems that would solve the biggest pain points (Product-land).
That being said, your content, along with bits and pieces I've gained from other resources, has been helpful.
Yet, I'm wondering if there are any other resources specific to treating domain semantic models as products that might be helpful?
A post well curated, I’ve learnt a lot too as an upcoming engineer.. Data is indeed an asset and should be modeled well to avoid future problems and technical depths… “Designing Data Intensive Applications” also made justice to data models…
Joe - This is a good description of the practical problems faced by Data Processing groups. A sizeable chunk of my career has been spent on data migration, often within the scope of mergers and acquisitions.
A recurring problem is that of funding efforts that focus on data. Although everyone at the C-level will accept the proposition that data is valuable, very few occupants of mahogany row consider treating data as an asset that should be funded as a capital investment. Data quality improvement and reorganization are tossed into the annual budgeting melee along with shiny desktop objects that advertise claims of "productivity gains of over sixty percent".
On one project for a telephone company, we took the time to calculate the value of a critical data store - the Line Information Data Base (LIDB). We hunted down the difference in hours spent in configuring the switches at central offices and connections in the field, including rework to correct problems, before the LIDB was set up electronically and the time spent during recent years when the configuration management system was operational. We broke the expense down to a per-line basis, and computed annual savings for the company. The configuration management system is primarily a data storage and retrieval mechanism, like a ledger in a bank. We took the savings and then calculated the value of a money market account that would yield the amount of savings year to year. The money market account needed to be over fifty million dollars.
Calculating the value of the data you have is not an inexpensive proposition, but the benefit of doing it far outweighs the cost.
Your framing of data modeling under Enterpriseland and Productland been very “memorable” for demonstrating “adaptable context” to both data practitioners and their stakeholders.
When a data practitioner can reiterate the stakeholders’ problem or opportunity, makes sense would be easier to pitch (aka: sell).
Selling is a nuanced dance worth learning, adapting because well…a life skill as long as used for good, not evil 🤔.
This is great stuff! The 'crispness' in several of your recommended selling statements is critical. I would add that even with such crisp statements on the business outcomes, audience skeptics sometimes challenge you with the validity of the means to verify stated outcomes. Its a complex world with many moving parts and the classic 'correlation vs. causation' discussion can come up with the challenge to prove other projects (automation, new AI agents, consultants, process re-engineering) were not the cause of the beneficial outcomes!
I have sold data modeling in Productland and Enterpriseland and you described it well. Product - you sell the opportunity (be aware - much more delivery pressure beyond data model), Enterprise - you sell the better use of resources (easier to prove).
There is one trick I used in Productland - hijacking a business initiative. Let's say there is a push for a specific new marketing initiative like the renaissance of account-based marketing that requires a different dataset. This is your opportunity to provide the dataset, but with the time and maybe project budget it allows to work on the data model for this as first implementation and then use it to expand to other areas.
This was very helpful, Joe. I appreciated the framing of talking points for both the Enterprise-land and Product-land groups, as well as being aware of which group I am speaking to.
In the last several months, I've led a push to begin treating our domain semantic models as data products to allow engineers as well as BAs to move closer to the business problems, while also inviting the business leaders into our limited resources, given the business domains we support. This includes our first-ever cross-domain prioritization to ensure the business was aligned on the problems that would solve the biggest pain points (Product-land).
That being said, your content, along with bits and pieces I've gained from other resources, has been helpful.
Yet, I'm wondering if there are any other resources specific to treating domain semantic models as products that might be helpful?
Stay tuned
A post well curated, I’ve learnt a lot too as an upcoming engineer.. Data is indeed an asset and should be modeled well to avoid future problems and technical depths… “Designing Data Intensive Applications” also made justice to data models…
Joe - This is a good description of the practical problems faced by Data Processing groups. A sizeable chunk of my career has been spent on data migration, often within the scope of mergers and acquisitions.
A recurring problem is that of funding efforts that focus on data. Although everyone at the C-level will accept the proposition that data is valuable, very few occupants of mahogany row consider treating data as an asset that should be funded as a capital investment. Data quality improvement and reorganization are tossed into the annual budgeting melee along with shiny desktop objects that advertise claims of "productivity gains of over sixty percent".
On one project for a telephone company, we took the time to calculate the value of a critical data store - the Line Information Data Base (LIDB). We hunted down the difference in hours spent in configuring the switches at central offices and connections in the field, including rework to correct problems, before the LIDB was set up electronically and the time spent during recent years when the configuration management system was operational. We broke the expense down to a per-line basis, and computed annual savings for the company. The configuration management system is primarily a data storage and retrieval mechanism, like a ledger in a bank. We took the savings and then calculated the value of a money market account that would yield the amount of savings year to year. The money market account needed to be over fifty million dollars.
Calculating the value of the data you have is not an inexpensive proposition, but the benefit of doing it far outweighs the cost.
Great.
Your framing of data modeling under Enterpriseland and Productland been very “memorable” for demonstrating “adaptable context” to both data practitioners and their stakeholders.
When a data practitioner can reiterate the stakeholders’ problem or opportunity, makes sense would be easier to pitch (aka: sell).
Selling is a nuanced dance worth learning, adapting because well…a life skill as long as used for good, not evil 🤔.
This is great stuff! The 'crispness' in several of your recommended selling statements is critical. I would add that even with such crisp statements on the business outcomes, audience skeptics sometimes challenge you with the validity of the means to verify stated outcomes. Its a complex world with many moving parts and the classic 'correlation vs. causation' discussion can come up with the challenge to prove other projects (automation, new AI agents, consultants, process re-engineering) were not the cause of the beneficial outcomes!
Taking the DE course on coursera, when i combine that with these substack writings it is really gooooddd, Thanks!
And thank you!