Companies can significantly shorten the duration of implementation when data is treated like a product. “Data as a Product” means that we give the internal customers of data (analysts, engineers, and data scientists) the same level of user experiences that we give our external customers when they use a product. Because internal teams utilize data products to build other data products, having a high-functioning “Data UX” is critical. This will enable teams to make better decisions, have the information they need at a higher quality, execute on getting the dashboards and insights they need faster, and put their data to work. 

The Data Problem

Product managers, business leaders, and business intelligence analysts often struggle with the time it takes to get the insights they need to make informed decisions and present findings. Quite often, the solution presented is that additional headcount is needed, but that doesn’t address the fundamental source of the problem and may, in fact, add more complexity and cost with little to no ROI. 

The root of this problem is that without semantic management and integration of data modeling at the point data is generated, we are merely throwing data over a wall in siloes, reducing data engineers to operate in a service model with ever-growing backlogs. When interviewing business leaders, I ask them to describe their model of how their business works, request models from employees, and then, going deeper, I talk to designers, data engineers, and data scientists. Quite often, each has entirely different pictures or languages to describe fundamental, core, and critical concepts to their business. This alone creates massive discrepancies. This is why semantic management is critical. There are many strategies to employ, from centralized, to de-centralized, federated, and computational, when designing semantic systems.  

Data engineers and data scientists often inherit legacy systems that haven’t invested in proper semantic management for well-designed schemas, taxonomies, and ontologies that align to business goals, UX design frameworks, and software development standards. Instead of driving insights and leading organizations into next-generation innovation, they’re playing detective for why data is of poor quality and how to fix it. The majority of their time isn’t on gaining insights, but rather cleaning up data that yields poor value compared to what they know is possible if they were resourced properly and followed the ‘right’ way to do things.  

Unfortunately, architecting, implementing, and maintaining pristine data is a massive up-front investment before businesses see an ROI, and leaders often want “quick wins.” There’s a cost to short-term thinking. 

Utilizing Data UX to Move Forward with Data as a Product

Incorporating principles of “Data UX” is imperative to move toward “Data as a Product.” Data UX is the user experience for those who create, consume, and engineer data, and this means that the same quality, reliability, and experience design that we expect in consumer products should also be applied to data across the organization. 

By thinking of data as a product, we can begin to think of how we evaluate data products as we would commercial products. We can rate our data experiences from different teams in order to design features and systems that maximize the value of our data and reduce friction between teams in order to drive value.  

“…the Data Warehouse (Swamp) is a monolith. Because it was never designed from the beginning with semantics at its core, the number of dependencies taken by downstream tables explodes into an unscalable monstrosity as new business concepts are welded on haphazardly. Even if a well-meaning analyst documents a new table/query, it doesn’t do much good if the upstream still has hundreds or thousands of undocumented rules no one understands.” – Chad Sanderson, Head of Data @Convoy 

The silos between software engineers and the data quality that they produce creates an incredible amount of work for the data engineers and architects who are responsible for modeling and infrastructure. Software engineering teams are separated from analytics and ML teams, as are product managers and experience design teams.  

Thinking of Data as a Product 

Thinking about how to treat data as a product and creating a paradigm that supports cross-functional semantic architecture will enable your teams to unlock tremendous value. The cost of course is organizational change, but I assure you, the ROI is worth it.

For support in shifting to a “Data as a Product” approach, visit our data consulting services page to learn more.