As businesses wake up to the transformative power of data, the data product owner is playing a vital part in driving this change. While the role of product manager or product owner isn’t new, the application of the product role in data is emergent.
So whether you’re considering a role as a data product owner or are keen to implement the position into your business, our Principal Product Owner Danny Ivatt has some key learnings that you should consider…
Traditionally, organisations viewed technology as a risk and a cost to be minimised. In the days before the digital revolution, technology would be procured and delivered as a project with specifications developed up front. Since the early 2000s technology has enabled markets to transform, with radically increased customer expectations, increased competition and a high pace of change. To compete here companies have shifted to viewing technology as a strategic enabler.
This shift has seen organisations move to the continuous development of digital products and services according to customer needs with small autonomous, persistent, multi-disciplinary teams working to deliver target outcomes using lean and agile principles. Success is not determined in terms of technology implementation or project milestones, but measurable business value. This transformation is product thinking.
Despite this revolution, data is often still treated how technology used to be treated. This means centralised platforms, delivery conceptualised as technology initiatives and projects managed to a timeline. It’s usually handled in single-discipline teams with little understanding of how they can deliver business value because they are isolated from customers and service delivery.
If companies want to unlock value from data and treat it as a strategic enabler, they must apply the same transformation to data. Apply product thinking, create data products and invest in the data product owner role.
.png)
They work with their team to understand who their customer is and what problems need solving in a way that adds business value. Not centralised and isolated but working closely with their customer and in the relevant business area. In software we refer to real-world context as working in their ‘domain’. Data product owners measure value, not delivery to a timeline or according to implementation of technology. Data products are persistent, not projects delivered to a specification and are developed in small multi-disciplinary product teams.
Product development is about navigating through risk and uncertainty. We typically think of four sources of risk and uncertainty that must be mitigated:
- Is the product feasible (can we build it?)
- Is the product valuable (will customers want to use it?)
- Is the product usable (are customers able to use it?)
- Is the product viable (does it create value for the business?)
As a data product owner, you leverage towards the source of the greatest uncertainty to ensure you can deliver business value. Product risk, not project delivery risk, drives prioritisation, delivery and mitigation activities.
Activities to mitigate these risks in product development are referred to as ‘discovery.’ Classical product discovery approaches are often weighted towards mitigating value and viability risks (the risks that a customer would use the product and the risks that it is business viable). Contemporary technologies and software development frameworks mean that feasibility is often more certain.
All of these risks are still present for data products, but typically risks are weighted towards feasibility. Data is very uncertain, data access, data quality and data governance concerns mean that we are often far more certain that a hypothetical data product would create value, but far less certain as to how we would deliver that value. Data product discovery must reflect this weighting.
A key question I ask product people is ‘when did you last speak to your customer and what did you learn?’
Most organisations create data product roles back to front. They put product owners in a role where all they're doing is project delivery, managing backlogs, writing user stories and getting involved in project governance, without changing process, organisational structures, architectures, how customer needs are understood and importantly how success is measured and value delivered.
In those organisations the answer to the above question is often ‘never.’
What organisations need to do is conceptualise data products around customer problems and needs, business value and target outcomes. Locate the data product team within its domain, close to that customer. Conceptualise differently, make measuring success be about value and invest in a data product owner role that can impact all of these things.
Product strategy must be informed by talking to customers and formulated around target outcomes, not a laundry list of features.
This isn’t because you want to sit in perpetual and unending chaos, but because you're a creative problem solver who can navigate a way through that uncertainty. You also have to be inquisitive and want to learn, often working from first principles. Navigating through the uncertainty associated with the above products risks is how you create meaningful value.
We’ve all played Trivial Pursuit. In the game, areas of knowledge are represented by a ‘cheese’ that each player has to collect. Great product owners are like the winningest Trivial Pursuit player. They know enough about each subject matter area, maybe specialising in one or two, but with continuous room to grow and learn about the others. In addition to this ability to navigate uncertainty, it’s a role that best suits people who have some experience elsewhere in a relevant discipline. There are many paths into product and one isn’t more valid than another.
Data product owners often end up siloed in technology and don't necessarily report within the same function as other product roles in an organisation. Data has different qualities but it’s a false dichotomy to debate over whether someone is a data product owner or simply a product owner. Matrix structures allow people to have a different team, community of practice and reporting line. Silo-ing people into different functions doesn't allow for collaboration and doesn't create a cohesive whole organisation approach to product development. Data as a set of skills is one ‘cheese’ in our Trivial Pursuits model, the other ‘cheeses’ are valuable skills and principles that cross the product discipline.
Interested in seeing our latest blogs as soon as they get released? Sign up for our newsletter using the form below, and also follow us on LinkedIn.
