TD:LR

Data Asset, Data Product, Data Service?

There has been a lot of discussions on LinkedIn, lots of podcasts, lots of webinars lately on the question of whether data should be treated as an asset or a product.

If we decide to treat it as an asset, product or service there are common pros and cons that seem to come with each pattern.

Let’s look at the behaviours of four personas to see if we can get a handle on which, if any, of these is the best way to treat data.

The personas are:

• Executive leaders, from a lens of being the owner of the organisation
• The data owner, who has notional ownership of the data
• The data team, from the lens of doing the data work to deliver it the data
• The consumer, who will use the data

And lets use a theme of a company car as an example to compare the data use case against.

Asset

If we treat data as an asset we are going to treat it like a company car.

The executive team will be focussed on maximum use the value of the asset. Data will have a value which the executive team will want to record, manage and leverage. Just like they want to know how many company cars they have and what they cost to procure and maintain, they will want to know the same for the data assets. Once a company car has come to the end of its life it is disposed of and replaced, they will expect the same of data assets. Capturing the true value of this data asset will be fraught and therefore unlike a company car, the data asset will not sit on the traditional company balance sheet. It will be maintained offline in an excel spreadsheet somewhere, which will bring its own problems.

The data owner will treat data like an asset and therefore hoard and protect it, to ensure that value is not lost. They will become data guardians or data stewards and will be protective of who can use the data and for what purpose. Like a company car there will be a tendency to assign the asset to a person or team, rather than make it a pool capability, as a pool of company cars is much harder to manage.

The data team will treat the process of delivering the data as a project, focussed on delivering the asset they have been asked to deliver. They will deliver the data and then push it out of the factory. They will treat it as one and done and let the data degrade unless a decision to invest more time/effort is made. Or the delivery work will be outsourced to a third party, after all what organisations build their own company cars?

The consumer will be focussed on getting access to that asset so they make use of it. They will find the data hard to find, as it has been locked away to keep it safe. Like a company car it will have already been assigned to somebody else, they can either ask that person’s permission to “borrow” the car, or if they want permission to access the data asset on an ongoing basis there will be numerous forms and processes before they can use the asset. Shadow processes to share the data will appear.

At some stage somebody will suggest they lease the data assets rather than build and own it.

Product

If we treat data as a product, we are going to treat it like car tyres.

The executive team will be focussed on unit economics. For internal use, the executive team won’t care where the data products come from as long as they are cheap to buy and do the required job. If the organisation is selling the data products they produce to third party organisations, i.e the organisations business is to sell tyres, then the executive team will care about the factory that makes the tyres, focussing on the cost to produce, the quality of what is produced, and the margin each Data Products returns.

The data owner will be focussed on maximising the value returned for each data product produced. They will become product managers and will focus on ideas for new products to bring to market, ways to reduce the cost of delivering the data product and ways to increase the monetisation of the data product. They will care about how many tyres are produced and how many are sold. If the data products are being sold to third party organisations then real money will trade hands and the product management ways of working will make sense, if the data products are “sold” internally then maybe funny money will be used to determine value, but this will confuse everybody.

The data team will adopt product management or factory optimisation patterns to refine how they design and deliver the data product, but once it has been delivered, they will forget about that product and move onto the next one. Given each data product is likely to be bespoke, they will lose the benefits of repeatability that a tyre manufacturer has and the unit economics of each data product will not make sense.

The consumer will expect to be able to walk into a data product store and get help selecting the right data product for their needs, just like they do for their car tyres, or they will expect to self-serve themselves with ease and at a lower cost than the full service. They will be severely disappointed in the lack of the buyer experience for both of these scenarios. Half the time the tyres they have brought will be flat from day one, and the tyres that are ok will often have unexpected blows outs on a regular basis. If they are buying internal data products, they will not be allowed to buy data products from a competing company, they will have to buy and use the data products their company produces, even if they don’t fit their car.

Service

If we treat data like a service, we are going to treat it like we are a team of mechanics.

The executive team will focus on optimisation of the available resources to achieve the organisation’s goals. The will constrain the resources as much as possible, while trying to maximise the output and value produced by the resources as much as possible.

The data owner will become the service manager, managing the demand from the consumers and the data team and resources available to optimise the two as much as possible. As demand grows the service manager will ask for more people and more resources. But demand will be lumpy and the team and the resources will often sit idle.

The data team will be rushed off their feet with last minute demand for their services as consumers forget to plan for when they need data, just like some people forget to service their car before a big holiday trip. When there is an organisational crisis the team will be flooded with ad-hoc and unknown data work, where they have to diagnose both the root cause of the problem as well as the data work needed to solve it, just like a mechanic does when a car which has broken down comes into the workshop.

The data consumers will find that the data work always takes to longer, costs to much and always has a set of unexpected surprises, they can’t understand how in 2023 the data work always seems to be bespoke and ad-hoc and the service team are always busy for months in advance and never available when they need them.

Data as a Service

Is the answer to treat data in the same way our product and software brethren have treated the move from software as a diskette to software as a service?

Is the answer the way Uber treated the service of taking passengers from point A to point B and changed it to treating that service as a product?

Keep making data simply magical