EVERYTHING YOU THINK YOU KNOW ABOUT DATA MANAGEMENT IS… probably correct, actually.

Instead, we focus on management of the TO VALUE part of DATA TO VALUE—and how to productise it. Because productisation holds the key to more effective ways of working with data that allow you to scale as you grow.

A product offers a way of working—design products that offer new ways of doing data work

Companies need to turn data into value—boosting business decision-making and productivity by serving insights. That’s why Data Management (DM) exists. Thing is, companies already have a vehicle for turning things into value and boosting productivity: products. Now, not all products are created equal—some being down-right shoddy—so we’ll quickly qualify that to well-designed products.

While DM, for the most part, does exactly what it says on the tin—managing data as an asset—DM is no stranger to products. There’s Self-Service Data plus Self-Service Analytics—it’s downstream sibling, and Data as a Service. With Data Mesh came Data as a Product and Data Product. However, these concepts all try to make products out of the DATA part—not out of the TO VALUE part. Which isn’t surprising, really—DM is about data, not product design. For most data managers, engineers, and scientists, product design and Design Thinking are unfamiliar or even foreign practices. This should change.

A well-designed product offers a way of doing things, of getting things done. Data makes for sub-par products. Instead, make products out of the ways data workers do their things—offer data workers new and effective ways of doing data work. That’s what allows you to scale as you grow.

In a nutshell, we argue that some part of your company must start forming cross-functional teams that design, develop, and deploy data work products with and for company’s data workers to stay competitive. It doesn’t have to be the DM function—but it should be. Business units may know the data they have and use, but they tend not to know how to work their data effectively. They need help by autonomous data management teams to grow into Business Domains—and by that we really mean cross-functional biz-data-tech productisation teams.

Summary of the full story

The following bullets serve as both a table of content and a summary of the full story.

  • TO VALUE centers on consumption of data work, transforming it into solutions, decisions, and actions
  • DATA TO is a mindset that risks focussing data worker attention on merely managing their data instead of doing data work: ‘consumables’ useful to the consumers and usable in their bounded contexts
  • Stop making products out of data and start co-creating self-services with and for data workers, offering them new ways of doing data work—because data work products are what enables Business Domains to form and to scale as they grow
  • It takes cross-functional and autonomous data management teams to get shit done—it’s the only way to breach the silos that’s holding us back
  • Data Management can save the day—the switch from data-driven to adoption-centered data work is spelled autonomous data management teams instituting new ways of doing data work
  • You can only change culture by instituting new practices, not by decree or with motivational posters—the agents of change are productisation teams that institutionalise new behaviors and that change innovation from being a buzz-word into a practice

TO VALUE is about data work

If we zoom in on the data-to-value transformation, we see nothing but people busy doing their jobs—solving problems, making decisions, or taking actions for some outcome they are reaching for. All of them curate some sets of inputs and transform them in big or small ways using other inputs—for others to use as one of the inputs for their jobs. Data work is no different; it is only ever part of the input stage of some other work—which could be data work in its own right, serving some other purpose.

Data work exists to be consumed

Data work is a subset of knowledge work, distinguished by its dependency on sociotechnical systems and its methodical treatment of inputs. Science is data work—with strong validation and replication ambitions. Data is really just an abstraction for the sets of inputs that data workers curate and transform. That data is generally someone else’s data work—taken as input. Data engineers do data work—consumed by data scientists doing their own data work to be consumed by others. DATA TO VALUE may be seen as a chain, but it is really a collection of individual data-to-value transformations.

Consumption is transformative

When you take our work as input for your work, you transform it. You make it yours—to serve the purpose of the work that you do. Consumption is the end of the line for any input—because whatever is going out is not the same. It has been transformed precisely because it now serves a new purpose—being input in some other bounded context.

The data-to-value transformation isn’t really about what data workers do to their data. It’s about digesting content from one bounded context and creating content that makes sense in another. Much like the ‘knowledge work’ you are currently reading—it tries very hard to make inputs from product design, multi-agent systems, and organisation theory make sense in the realm of data management.

The point of data work is VALUE-IN-USE for those who consume it

The fundamental VALUE part of work in general consists of the value-in-use people enjoy—enabled by the work of others. The TO VALUE part is workers explicitly boosting others with respect to the outcomes they are reaching for—specifically, boosting the producitivity of the ‘reachers’ with regards to their utility by improving their ways of working. It definitely helps if the ‘booster’ and the ‘reachers’ have a shared and agreed-upon understanding of each other—a trade language of sorts or a feedback loop that creates an interface between their respective bounded contexts.

To be frank, we claim that DATA TO VALUE goes in the wrong direction. The TO VALUE part starts with a use case. That determines the data work needed. This, in turn, determines what counts as data and what does not. In short, the data-to-value transformation becomes much more effective if you read it USE CASE TO DATA WORK TO DATA.

‘Reachers’ are more than consumers of data work

For the rest of the article, we’ll be using reacher as the term for someone—be they persons, teams, or units—who consumes or uses anything, not just data work. While you may find it aggravating that people keep pushing new terms and concepts at you, there’s a solid upside to switching from consumer to reacher.

Labelling people consumers puts our focus on what they are consuming and not on why they would ever do that. To put it boldly, thinking of them as ‘consumers or users of data’ is non-productive. It’s bad semantics that block DM from being effective. When you think of them as reachers, you are forced to consider what they are reaching for. This mindset leads you to look at the ways in which they are doing things and at the outcomes they are reaching for. If you don’t look, you will have trouble offering them new ways of doing things.

A mindset of DATA TO can block effective and scalable ways of doing data work

We realise the shock value of the next statement, but bear with us. We argue that a preoccupation with the DATA TO part of DATA TO VALUE is largely a blocker to scalability.

A DATA TO mindset steals the attention from productising new ‘ways of working with data’, meaning new ways of doing data work. It blinds us to the need for investing in productisation capabilities. The title for this article is nothing but an attempt at highlighting this blind spot. Which is important, because the prospects of doing data work successfully with a DATA TO mindset are not good.

The reality of doing data data work is… messy

Lots of people are very busy trying to turn data into value—furiously battling the volatile, uncertain, complex, and ambiguous (VUCA) reality of doing data work. Data workers and the reachers they serve are operating in different bounded contexts with their own semantics—making their interactions rife with misunderstanding and flush with frustration. It gets really messy when different bounded systems, architecture, infrastructure, and platform contexts clash—forcing data workers to carefully thread point solutions through the mess to get anything done. And they can unwittingly sabotage each other—one data worker committing changes to some shared input can easily break the workflows of others.

Turn the data work mess into a mesh of data work products

It’s in everyone’s interest that the reachers can get some value-in-use out of data work, and that data workers can do their jobs effectively. To be blunt, decomposing and refactoringthis mess into something that works cannot be championed on data worker level. It must be championed on manager level.

Someone has to organise, govern, and manage who does what parts of which specific transformations for whom. This is no small thing. We argue that productising ways of doing data work into a mesh of data work products is the shortest path to real improvement. Product Thinking means thinking Service Mesh and Data Mesh.

Data is like wheat—not iron

Many data workers are stuck in the DATA TO part of DATA TO VALUE precisely because they are disconnected from actual reachers. Instead, they do data work ‘in a vacuum’ without purpose-giving use cases—the absence of which reduces them to mere custodians of data.

Data is commonly managed as an asset or a resource to be refined. Like iron—a natural resource that we humans can find, mine, and extract. We blithely assume that there is a hierarchy of value-adding steps that elevates raw data to source data to information to knowledge to understanding, wisdom, or truth. This belief is a dangerous fallacy, because data is not like iron. We cannot work data as if it were a natural resource—it’s wholly man-made, crafted from scratch to serve human purposes.

Consider wheat cultivation

Wheat conjures up images of bread-baking and pasta-making. But wheat is useful in all its forms—not just when milled to various types of flour. The same is true for data. Sprouted wheat grains can used as-is for salads, sandwiches, or health drinks. The grains can be boiled for salads, soups, or stews. They can be shredded or flaked for cereals or cracked for bulgur. A lot of the wheat produced go straight to livestock feed. Wheat husks can be used as filler material in plastics or for biofuel. Wheat straw can be used as construction material (straw bales) or for making paper or cardboard. Or it can be used as mulch and even a substrate for growing mushrooms.

Think of data work as wheat work. At no point in its life cycle can wheat be considered raw. Furthermore, every step of every way of processing what is productised. And new ways of doing wheat work can be productised—even new ways of growing new type of wheat.

The data-to-value chain is a distracting abstraction

Above, we urged you to view data work as a consumable. Taken seriously, it decomposes the data-to-value chain into individual TO VALUE transformations—distinct and discrete interfaces and feedback loops with actual data workers doing actual data work on one side and actual reachers actually consuming their work on the other. Data is just an abstraction for the input stage of data work which is the input stage of consumption. Data work transforms data to a consumable. Consumption transforms data work to something that enables value-in-use in another bounded context—solving problems, making decisions, taking actions, such as doing business or other data work.

There is no data-to-value chain. There is just an organically grown array of individual ‘links’ coupled into a confusing weave of point solutions. And that weave doesn’t allow for scaling as you grow.

Stop making products out of data—start offering new ways of doing data work

A well-designed product offers a way of doing things, of getting things done. In design-speak, it affordsusages. Productisation, then, looks at what people are doing and how they do their things to decouple a general use-case from those doings. The point is to offer the people a new way of doing things or even new things to do.

A product should not try to solve the problem for the problem-havers. That’s what a point solution does, and that doesn’t scale. If it tries to solve many problems for many reachers, it becomes a monolithic mess of point solutions.

Instead, it should be the means by which they solve the problem themselves—a design pattern that affords usages. The reachers still have to put in the actual work of doing the new things or doing old things in new ways.

“Hey! We could probably make money off of this!”

Productisation is the act or process of turning ideas, activities, and things into ‘marketable’ products. Put differently, productisationis what product designers and developers do.

If we go by Schumpeter’s definition of innovation as ‘the doing of new things or the doing of things in new ways’, productisation is innovation in the second sense. Productisation makes a product out of some part of some people’s ways of doing things and offers it to them—and they adopt it as a practice if they enjoy the new way of doing their things. The adopters’ value-in-use is the boost to their productivity with regards to some utility they enjoy. Hence, we claim that adoption is the quantum of innovation, because adoption of product usages boosts the productivity of the adopters.

Think of products in terms of simple machines

A fundamental analogy for understanding products is simple machines. Consider the six simple machines of antiquity: lever, wheel-and-axle, pulley, wedge, inclined plane, and screw. From a physics perspective, they are force amplifiers that offer mechanical advantage to you, the user. They boost you by distributing the work you need to do over a distance, reducing the force needed. But you still have to do the work.

From a design perspective, they afford you different usages. Consider the wedge, mankind’s oldest tool: a more effective fingernail or tooth. The usages it affords include the following.

  • Splitting or cleaving things—as an axe (technically, it’s a hand axe until we add a lever)
  • Cutting things—as a knife. If you serrate the edge you get a saw (the teeth are tiny wedges).
  • Puncturing things—as a needle (small) or a spear (big)
  • Prying things apart—as a movable inclined plane. You could use a knife, but you risk destroying the edge—effectively turning the knife into a prybar.
  • Digging—as a spade (without a handle)

From a product perspective, simple machines offer new ways of working.

Simple machines are composable design patterns

The wedge, as any simple machine, encapsulates a general use case and offers a composable design patternthat affords various user-specific usages.

The genius of simple machines is that they are useful and usable on their own while also being composable—capable of being composed into more complex machines that affords other usages. Combine an inclined plane and a screw, and you get a spiral staircase. A wheel-and-axle and two levers make a wheelbarrow. One or more pulleys on a lever forms a crane. A screw with a wedge is a drill. A wedge with a lever, an axe, a prybar, or a shovel, depending on composition.

But simple machines—or, indeed, any product, don’t create themselves. Someone has to take responsibilty for designing, developing, and deploying them.

The Principle of ‘Data Work Product Ownership’

We argue that data managers should be accountable, if not responsible, for creating data work products for the data workers that consume ‘managed data’. To put it provocatively, merely managing data is useless. We’ll quickly add that useless does not mean worthless. We are saying that what really creates value for data workers is stuff that makes them more effective as data workers.

That means being able to do actual data work for their reachers—not wasting time and effort on battling upstream data managers and data engineers for the inputs they need. In short, data managers should take ownership of designing, developing, and deploying data work products as their job. Even if they don’t personally participate in productisation efforts, someone has to enable and manage those efforts.

The same goes for Business Domains (Bizdoms for short). Data managers in Bizdoms should take ownership of designing, developing, and deploying their own data work products for their own data workers. The business case is that that helps the Bizdom’s data workers to better serve reachers in the Bizdom or reachers downstream from it, such as actual paying customers.

Data work product ownership requires investing in productisation capabilities

A product is the result of a productisation effort. Well-designed products are results of well-organised productisation efforts. It’s the productisation capabilities of DM and Bizdoms that determine whether or not their ways of doing data work are effective and enable you to scale as you grow.

And that is structural capital. Investing in human capital is never a bad thing—talents, skills, and competences are necessary ingredients for productivity. But it’s not nearly enough.

Focussing myopically on human capital and hoping that these individuals will save your business by virtue of being masters of their crafts makes the mistake of forgetting a tiny little thing: the whole matter of organising them into concern-separated productisation teams. Teams with high cohesion and low coupling to other teams or units—teams that can operate with purpose, mastery, and autonomy. Before we delve into this, let’s talk about what productisation teams do.

Data work products offer new ways of doing data work and enable Business Domains to form and to scale as they grow

In practice, productising ways of doing data work means co-creating self-services with and for data workers so they can do their data work more productively. This is a mouthful, so let’s call those self-services data work products. For such products, well-designed means useful to data workers and adoptable into their sociotechnical practices.

A data work product mirrors the interface in Team Topologies (TT) between platform teams and stream-aligned teams. TT terms that a X-as-a-Service interface. It means the same thing: a productivity-boosting convenience to the reachers who consume it. The interface in Data Mesh between its platform teams and the data product dev teams follows the same formula. We’d argue that its self-serve data platform is nothing but data work products. Additionally, the data products of Data Mesh are data work products in their own right.

Well-designed products hinge on good semantics

Products made out of data are the most basic form of products: goods. The business logic for goods is offering at low cost and effort to the reachers something that they already know exactly how to use in their operations. The producer can pay full attention to producing their goods because they do not need to think about why the reachers need them or how they are going to use them.

As soon as the reachers have doubts and questions about what they need—and, therefore, what to buy and how to use it—goods logic fails as a business model. That is why well-designed products must look to their ways of doing things and design something that makes sense as a usage in their operations and to the people in operations.

Confused by product, good, service, and self-service? You have good reason!

We use product because service is a semantic warzone. For instance, TT uses X-as-a-Service for what is really a self-service—the polar opposite of service. Even funnier is that self-service actually captures the essence of product—which is why we use it to define data work product. Also, a service—while being a type of ‘marketable’ product—can have a market of a single consumer and still be a viable service. This is not a good mindset for data work products.

There is a method to the madness of arguing semantics. We are trying to develop what Domain-Driven Design calls a ‘ubiquitous language’ in shaping our ‘domain model’ of adoption-centered management of the sociotechnics of Data & AI.

The data products of Data Mesh are data work products

Data Mesh data products offer new ways of working. While they contain data, that is not why data workers adopt them into their practices. Data workers adopt them because data products are composable simple machines.

We’d argue that developing data products as they appear in Data Mesh manifests as “co-creating self-services with and for data workers so they can do their data work more productively”. The genius of Data Mesh has little to do with actual data. It lies in how the data product developers productise data work. Simply put, a data product decouples data from context-specific semantics and usages—thereby becoming bridges between bounded contexts.

In the abstract, they apply Design Thinking—and design patterns in particular—to data work. They decouple data work use cases from the messiness of the actual data usages of data workers, meaning the specific ways in which they curate and transform their sets of inputs.

To elaborate, data product developers decompose data work into concern-separating use cases much in the same way programmers refactor their code. These use cases have high internal cohesion and low coupling to other use cases—and are distributed into a mesh network topology. If we use the language of Double Diamond, a design process model, we can say that this organises the problem space of data work—which minimises friction and maximises scalability.

Then they implement data products as composable design patterns to serve these data work use cases. This organises the solution space of data work. Note that data products—and design patterns in general—afford usages; they are not solutions to problems. They offer themselves as self-services to data workers who consume them as a means for them to solve their own problems—which removes bottlenecks.

For individual data workers, data products are a net bonus. The upside is that each data worker can more easily self-serve some of the inputs they need, offering more effective ways of doing data work. The downside is that the data product pushes any data transformation that is specific to a data worker into their data work. Which is actually fair—everyone should own the tasks that matters only to them.

The upside for DM in general—and DM in Bizdoms in particular—is that composable data products allows for scaling with growth.

It takes a cross-functional and autonomous team to get shit done

Co-creating self-services with and for data workers takes the effort of a cross-functional biz-data-tech data work productisation team. That’s also a mouthful, so let’s call such teams prod teams for short. We’ll also call them autonomous data management teams so we can sneak the concept into DM and stealth-transform DM as a practice. Importantly, everything TT says about teams—platform teams and stream-aligned teams in particular—is valid for prod teams. Just replace the XaaS interface with data worker self-services or products in your mind. In fact, we’d argue that TT’s XaaS interface manifests precisely what we mean with a data work product.

A team requires purpose, mastery, and autonomy to be effective

Purpose is a clear and crisp sense of direction—giving the team a shared and agreed-upon understanding of what they are supposed to be doing and where they are going

Autonomy is the team’s degrees of freedom—the extent to which the team can operate without being bottlenecked or blocked by dependencies

Mastery is about the capabilities needed to do a good job. Co-creating self-services with and for data workers masterfully requires diversity in talents, competences, and skills (and resources). The authors use biz-data-tech as a shorthand for the following breakdown of the required areas of expertise.

  • Business development and organisational development
  • Product or service design and user UX-UI
  • Data engineering, data science, business intelligence, machine learning, or artificial intelligence—depending on which type of data work is being productised and what the data workers’ consumers are expecting
  • Platform engineering, including the tech stack

We use cross-functional instead of multidisciplinary because most companies are organised by function, not domain. If your company is organised by domain—well done! Please read cross-functional as multidisciplinary or even transdisciplinary instead. A prod team has to be cross-functional to have chance of doing their job masterfully. It also needs enough autonomy to be able to operate without bottlenecks.

You can only breach the silos by forming cross-functional and autonomous teams

Anyone who has ever tried to get shit done in a functional organisation is painfully aware of the frustrating insularity of silos. The fact that we must explicitly qualify prod teams as cross-functional and autonomous points to a fundamental anti-pattern in companies organised by function. Functional organisations devolve into silos by design.

A normal business unit or area is nowhere near to being a Bizdom—precisely because they are a function. Frankly, this spells hardships for the very concept of a Business Domain. The reason is simple. A Bizdom operates like a big prod team. It has to be cross-functional and autonomous to be effective.

A Business Domain starts as a prod team

For companies organised by function, the path to effective and scalable ways of doing data work will, unfortunately, be arduous. Fortunately, the path is actionable—because a single prod team is a net bonus. In precisely the same way that a data mesh can grow from the initial data products, a prod team can grow into several and then into a business domain. And that can spawn others, building momentum from the compounding effects of adding net bonuses one at a time.

Data Management can save the day—by switching from data-driven to adoption-centered data work

Data managers have the power to boost the productivity, and even transform the culture, of the entire company simply by forming and managing autonomous data management teams, distributed and embedded as prod teams in business units.

Changing the culture of an organisation is not difficult—it just takes time. Organisational culture is simply the consequences of operational practices. Practices institutionalise organisational behaviours. New ways of working engenders new practices—which begets new organisational behaviours to replace the old ones.

Being data-driven is not nearly enough. It is adoption of data work products that drives business—not data. So, take data work seriously. If you don’t, your company will never be Data-AI-Ready. Inevitably, you will be out-competed and obsoleted by companies that do. The shortest path to success is adoption-centered management of data work that operates autonomously in and with the business units.

Get out there and start productising the work that data workers do! Form your first autonomous data management teams with the express purpose to productise better ways of working.

Data Management can be the catalyst for transformation

In environments cursed by VUCA opportunity landscapes and the bewildering sociotechnics of Data & AI, Data Management can stand tall. Not just as a guardian of data integrity, but as the the catalyst for organizational innovation and growth. The data to value transformation has often been misconstrued as a linear process from source data to business-driving insights. We argue that it is anything but. It is a non-linear and dynamic journey of exploring new ways of working, where the real treasure lies not in the data itself, but in how we leverage it to enhance decision-making, boost productivity, and ultimately foster business agility.

DM has largely been pigeonholed into a custodial role, preoccupied with safeguarding data as an asset. Now, imagine the transformative potential if DM shifts its focus from merely managing data to actively productising data work. By forging cross-functional, autonomous teams tasked with creating data work products, DM can become a shaper of business—growing Bizdoms that are not merely data-informed but also adaptive and scalable—with regards to the operational needs of their data workers.

It’s time for DM functions to evolve beyond traditional confines and embrace the principles of product design and Design Thinking

Evolution requires a shift towards adoption-centered management, where the measure of success is not the volume of data curated but the effectiveness and scalability of the products provided to the data workers. Adopting this mindset doesn’t merely enhance DM—it propels entire organisations forward, enabling them to navigate the complexities of the modern business environment with greater agility and foresight.

The formation of autonomous data management teams, deeply embedded within business units, opens the doors to the future. These teams, productising new way of doing data work, not only enable business units to create value for themselves and the company—they prime the organization for continuous innovation and competitive advantage.

Being data-driven is commendable. Ultimately, however, it is the adoption of well-designed data work products that propels businesses forward. The time to act is now. DM has the opportunity, the responsibility, and the power to redefine itself as the cornerstone of a modern, agile, and innovative enterprise. Start by forming your first cross-functional productization team, and embark on transforming data work, driving business growth.

You can only change culture by instituting new practices

Autonomous data management teams that design, develop, and deploy data work products is not a mere shift in operational focus. They herald a choice of evolutionary paths. Changing the fabric of organizational culture may be a daunting prospect—but that happens automatically and naturally as new ways of doing data work take root. You cannot change organisational cultural by decree or with motivational posters. Productisation teams institutionalise new behaviors and change innovation from being a buzz-word into a practice.

Don’t wait for the future to dictate your actions! Let DM lead the way in crafting a future where data work is a catalyst for innovation, value creation, and enduring success.