Introduction
Should data be managed as a product?
As one of the most salient questions confronting data leaders today, it begs an answer. Traditionally, large organisations have relied on centralised data architectures – from mainframes to data warehouses – but the pressure to decentralise data is taking root. So, is the trend to exploit data? New design strategies such as data lakehouse, data mesh and data fabric are evolving to develop more sophisticated capabilities for producing and consuming data, but that leaves data leaders uncomfortably trapped in a transitory state between old and new.
When we view data through the lens of product management and allow ourselves to be influenced by best practices in software engineering, we can carve a path through the fog. Data is no longer a commodity to be hoarded and siloed, but free flowing and ready to fuel a factory-scale process that manufactures desirable, viable and feasible products for users. With this mental shift, our focus flows towards the valorisation of data in the context of real users and real customers, and more importantly, towards the professionalisation of the capabilities and processes necessary to build and manage data products at enterprise scale.
A data product is a broad definition for a product that uses data to facilitate an end goal. A ticker event stream, a data warehouse, company dashboard, decision support or even a self-driving car might be a ‘data product’ so it is helpful to ascribe some characteristics to our interpretation of a Data Product:
- Designed for a purpose – there is clear purpose to the design of the product.
- Self-contained – it is distinct from a particular platform or storage environment.
- Uses data (sets & assets) – it uses data, potentially a lot of it, to deliver a dynamic output.
- Repeatable/ reusable – it is used more than once, often with multiple users.
- Actionable outputs – the outputs are used to facilitate a specific action/decision.
- Non-deterministic – if data changes, but input stays the same, the output changes.
- Managed as a product – it is owned/supported, and part of an improvement lifecycle.
This is by no means an exhaustive list of characteristics and there are still some grey areas. For example, if a data product by this interpretation has no human users but creates a machine-readable output that powers a second step action / decision, is it a data product? Note also, those cogitations are not likely to conclude any time soon!
The Enterprise Data Management Council’s CDMC+ working group is still evolving its definition to include characteristics such as extensible, shareable, referenceable in a supply chain, ontologically descriptive in metadata, and so on. If you are interested in taming the boundaries of our interpretation, watch our event from October entitled ‘Demystifying Data Products’ through this link.
The perceived lack of a soundbite response to the question ‘what is a data product?’ is possibly a concern, but that isn’t a reason to stop thinking and planning for data products. With data and business leaders focus increasingly on exploiting their data, it begs another question, ‘what’s the alternative?’. Isn’t productisation the best way to surface the data in valuable ways?
However, with a stake in the ground, we can now answer the ‘So what?’ of this article:
As a data leader, how can I effectively use data products and data product management in my organisation to achieve the objectives of my data strategy?
Step 1: Data product by walking around
As a data leader, you need to get out to your business stakeholders. Write down their problem statements. Describe the outcomes they need. Evaluate the problems before diving into a solution – a common pitfall for any product design process, data or otherwise.
For example, “As a VP Sales, I cannot identify high-potential customer accounts. As a result, I cannot direct sales resources to increase the value of those accounts and create revenue. Ideally, I would like to see the lead-scoring methodology I have designed automatically applied to existing customer accounts in our CRM system and flag high-potential accounts to the appropriate account manager with suggested next steps and a view of the account history. As a result, I expect to be able to create an additional £50k of revenue per large customer per year, and over 10 high-potential accounts, create uplift of £500k within 12 months.”
This example statement contains 4 components that a data leader can use to formulate questions to their line of business peers to assess their data product needs. Specifically, the problem statement(s), the impact of the blockers, a description of a target state and a qualitative analysis of the economic benefit. With these 4 components, you can ascertain whether this business need is a feature request or a real data product. In this example, the VP Sales needs a new feature, not a new CRM product, but if this feature is not readily available and is a significant blocker, it could be on a product roadmap.
Do the Gemba Walk – talk to your business stakeholders. Do structured interviews.
Step 2: Evaluate business needs AND capabilities
After an exhausting week of interviewing your business peers, you’ve got a stack of one pagers describing a wide array of problems, from financial reporting to sales automation. It is important to filter these data product requests and assign a priority – this is the tricky part. Put the CFO’s request at the back of the queue and your POs (purchase orders) will take months; tell the VP Sales it’s an issue they should request from their vendor directly and face the thousand-yard stare. One of the key ways you can democratically prioritise data product requests is by putting it to committee with a simple scoring system for usability, feasibility, viability and value creation.
All this detective work is a precursor to your ultimate success as a data leader. You need to deeply understand the current operating environment as it relates to each facet of the business, from supply chain reporting to marketing forecasting, so give yourself the time to use the data product research activity to engage with your stakeholders and peers. Most importantly, whilst you are assessing the needs of your broader organisation, in parallel, you can begin to assess your own delivery capabilities. By having an independent specialist assess your capabilities against a proven framework – like the Data Management Capability Assessment Model (DCAM) – you are addressing your business needs and data capabilities at the same time.
Prioritise data product requests. Do assess your capabilities. Get help when needed.
Step 3: Build the lab, then the factory
In this analogy, we wish to convey the importance of controlled procedures before scale. One of the key outcomes of a data product research activity is the alignment of resources to meet your constituents’ needs, and this is best achieved by adhering to an industry framework such as CDMC. To achieve sustainable value from the creation and exploitation of data products, it is necessary to bring data product development capabilities into the control procedures of CDMC – a cloud vendor neutral framework consisting of 14 key controls that ensure governance and accountability without hindering the speed of innovation. Decentralised does not mean ungoverned; when exploring new concepts such as data products it is important to broadly disseminate why these control processes and procedures exist, to ensure they are fit for purpose, and to provide ‘governance guardrails’ for data products across the enterprise.
The introduction of data products to your organisation presents an opportunity to establish the product development capabilities you want as well as the data management capabilities you need, running against a well-established industry framework to manage risk. As part of the CDMC+ working group on data products, Ortecha is uniquely positioned to advise you on the adoption of CDMC, the assessment of your capabilities and the rightsizing of teams to carry out a data product research activity. With both the bleeding edge of data product thinking and the traditional enterprise data management needs in mind, we can help you derive sustainable value from data products as you go from the lab… to factory scale.
Do establish governance early on. Do experiments. Consider CDMC as a framework.
Next steps
For more information about making data products work at scale, including a conversation about the evolving research of the CDMC+ working group within the Enterprise Data Management Council, please do get in touch with our practice lead Steve Fisher.
contentS
- Introduction
- Step 1: Data product by walking around
- Step 2: Evaluate business needs AND capabilities
- Step 3: Build the lab, then the factory
- Next steps
Webinar
We discussed this topic – and much more! – with our excellent guest speakers in the 4th online event of our Data Leadership Series. Catch up now!
