I’m no longer publishing daily data contract tips, but I am still writing! Check out my new weekly newsletter.
David Jayatillake published an interesting post recently titled “We don’t need data contracts”. The title was enough to ensure it caught plenty of attention… but the subtitle more accurately describes what David is arguing for: “We need data to be part of product engineering”.
If you want your users to use the tools you are building or onboarding, it’s important to implement them exactly where they expect them to be.
The definition and evolution of the data contract should be a collaboration between the data producers and the data consumers.
Someone reached out to me and asked me to present on data contracts to their organisation after they had a data quality issue that directly resulted in multi-million dollars of lost revenue.
In the absence of set expectations users tend to be overly optimistic about the quality, reliability or dependability of the data.
The reason we talk so much about data quality is because we see the impact of it every day.
I had a couple of nice responses and follow-up discussion to yesterdays post on applying product thinking to data, one of which asked if we should be applying the discipline of product management (people, processes, etc) to data products.
I quite liked this article by Francie Kastl on the 6 Reasons Why Applying Product Thinking to Data Makes Sense.
It can be tempting to view data contracts as a large program that requires support from the top of the organisation to be successful.
An article that has stayed with me since it was published back in 2015 is Dan McKinley’s Choose Boring Technology.