How to implement a Data Product Strategy

Introduction

In the previous article I wrote about the data product concept, its application to large companies, and the strategy for adopting this type of approach in the development of data applications.

In this article I am going to talk about some levers to implement this strategy at the organisational and methodological level, which is usually the biggest stumbling block for this type of approach.

If you are looking for the first phase on developing a data product, the prototyping phase, you can take a look at this article where I wrote about the methodology to use.

Organization

Where we come from

The first thing to work on is the organisational level. To do so, we can ask ourselves the following questions:

• How are we going to organize ourselves?
• Do we need to develop a specific team?
• How should we progress as we mature in the strategy?

In order to answer to these questions, we have to take into account:

• where we come from and
• where we want to go.

This will be the key to define the strategy. For example, the worst case could be (you may be familiar with 🙂):

• We have a centralized data team that is responsible for the governance, maintenance and processing of data and its applications.
• There is no knowledge or capabilities in the use of data from the business areas.

Where we want to go

And the model we should go for would be:

• We want to have a small data team, which is in charge of defining the governance, best practices and architecture needed.
• The centralized data team should not be a bottleneck for the business areas to develop products around data.
• In the business areas there are capabilities and data teams that are able to manage their own data, data products, and govern them.
• The business areas are as well data cultured and know the power of using the data to improve or generate business.

In between, there is a range of levels of evolution to this model. In order to move towards this, one approach adopted in the market is called Hub & Spoke.

Hub & Spoke Model

This model comes from the logistics field, but has been applied for decades in any field at the organisational level.

In this specific case we would have the following actors:

Hub:

Entity that drives the initiative:

• In case of a large organisation, this could be the Data/IT area
• In case of a group of companies, corporate IT.

This entity has the following functions:

• Defines standards, methodology, technology, etc.
• Guides the spokes in the use of these standards and tools.
• Monitor what is developed in the spokes so that it can be reused by the rest.
• Helps launch the spokes in areas where there are no existing capabilities.

Spoke:

• Is the extension of the hub in capacities to execute the projects or develop the products, although it has independence of decision while maintaining the defined governance.
• Relies on the hub to take advantage of synergies of what has been developed for other spokes: methodology, technology, products, etc.

Hub & Spoke Model

With this approach, product ownership is decentralized to the business units, with the following advantages:

• Product development is always done from these units, which means that there is a focus on business return.
• The technology teams specialize in that business area and in the products developed, which optimizes and speeds up the evolution of these and the creation of products in that area.

Structure

In order to avoid duplication and align product development with the company’s objectives, a figure, that is currently gaining a lot of traction, is needed: Chief Data Product Officer.

This figure is responsible for, among other things:

• Define and implementing a coherent product strategy
• Coordinate the different product teams to avoid competition, rework, duplication, etc.
• Ensure the use of the various methodologies and processes defined for the product life cycle are implemented and used by the product teams.
• Encourage and evangelize about the use of the data products developed within the company
• Promote reuse and composite building for data product development (develop new data products from other data products)
• Help to prioritize the development of data products and define the road-map among the different areas involved, aligned with the business strategy.
• Maintain the product catalogue

Conclusion

With this approach, we would have the basic organizational changes to be able to implement a data product strategy in a large company.

There are more areas that need to be worked on, such as the economic or technological approach, which we have already covered in summary in the article where I explained the concept of data product strategy, in case you want to review it 🙂.