Data is top of mind for most product managers. Models Will Run the World, with the big winners being those model-driven organizations that build products that collect data and continuously learn to optimize growth, in turn accelerating that cycle. But the underside of that phenomenon is that at the core of any successful model is representative data. While the idea and the end product may be awe-inspiring and great for quarterly OKRs, it requires a lot of un-sexy effort. Just like software, data needs its own frameworks for managing this process in order to achieve successful outcomes — enter the Data Product Manager.
The Case for the Data Product Manager
I like to think of technology solutions as Maya — Indian philosophy’s term for the synthetic world of facts and events, imposed on the world through abstractions such as measuring, classification, division. The lifecycle of these solutions is its own kind of technological Karma (kind of like tech debt) — anytime we build a solution, it necessitates further action of quality control, maintenance, extension. The act of forcing technological Maya on the world is inherently anti-equilibrium, creating karmic consequences for the team and customers.
Under this view, the role of any good product manager is to pick the right problems, match them up with the right solutions, and groom the slopes for the team. Getting to the “goodness” of models running on representative data is no different: while the upside of a successful model is huge, there is an even larger potential for a black hole of complexity.
Data is no longer just making reports — data is becoming its own product domain, with its own deliverables, customers, development lifecycle and infrastructure needs. In order to meet expectations and avoid the chaos of go-it-alone hope-for-the-best analyses, we need product managers to steer these data products from ideation to completion.
What is Data Product Management?
“Product Management”, even more so in “Data”, is nebulous. Let’s define what that is.
Some organizations distinguish between more strategic & customer-focused “Product Managers” vs more implementation-focused “Product Owners.” Thankfully there is a small cottage industry of blogs that disparage this “horizontal” model, because we get a situation where the Product Owner won’t understand the customer, and the Product Manager won’t know what’s technically possible. The end result:
Customer-blind Product Owner struggles to deliver good requirements to the engineers, or worse, cedes total control of the roadmap to engineering, which generally will lead to infighting, loss of value, and perhaps even loss of jobs.
Technical-blind Product Manager delivers below-quality product to customers (and they might not even be deep enough in the details to recognize it).

#data-science #product-management #data-product-manager #machine-learning #data analysis