At Big Data London, I attended a talk by an executive from a large corporation that is known worldwide. What caught my attention from the very beginning was that the speaker mentioned the book Inspired by Marty Cagan, which is very much a bible in the Product Management discipline or profession, if you like.
The idea behind showing the slide with Marty Cagan’s book was to emphasize the fact that data teams need to adopt product thinking, which I very much agree with. I posted an article on that matter and it made quite a splash. But I’m also a fan of being reasonable about what one can expect from a data team.
Here is the point: the product management role and its necessity in the organization are determined by the organization’s level of maturity.
The product management role depends on and varies from organization to organization. For example, if you talk to Google Cloud Product Manager, they have little influence on product naming and no influence on pricing; there are rumors they also do whatever large corporations expect from them, while if you talk to a scale-up, the product manager there will likely be responsible for developing and testing channels for customer acquisition apart from figuring out the pricing, pricing units and naming of the services, etc.
The other point is to calibrate the expectations of product manager skills in data teams. To put it simply, one of the reasons why product management position was invented is that this role is in charge of delivering products which the organization intended to generate direct revenue. Meaning the magnitude of investment is higher for organization than investment in data teams and data infrastructure all together. Classic product management involves orchestrating and aligning all the teams in the organization, including law, marketing, finance, customer success, sales, operation, PR, and more in delivering products they are in charge. The point is, that classic product manager is appointed to the product where the stakes and magnitude of investment are still more significant than in a data project. Yeah, I know that data can be the product itself, but I’m describing a classical variant here. The bottom line is that product managers are managing products that have a different magnitude for business.
So, how do we balance and be reasonable while still expecting product thinking from data teams?
First and foremost, please stop insisting they read this book from Marty Cagan unless they want to. Not because it’s bad for them or the book is bad; the book is wonderful. The best you can do is to explain the business context you have or the data consumers of this data engineer and gently guide them through the process of identifying the audience and understanding their requirements and how they could be helpful.
I would like to double down on this. The underlying principle of product manager is identifying what the user is truly trying to achieve and ensure helping delivering that through the product. At the basic, uncover and understanding a true customer need requires skill to identify a fake request from real needs. But it sounds easier than it is. Believe me, as humans, we do not necessarily know what we need 24/7, and that is still very much present in communication in business as well. The product management books teach to do that by applying frameworks. But once it’s applied wrongly, it can cause more harm than good, and create a big cliff in communication between newly emerged data product managers in data engineers, and their potential customers.
Let me give you an example from my career. I was young and aspiring, so I used the five whys framework. To be short, I made my customers crazy, and they never wanted to talk to me again. I think the reason is that customers do not owe us to be clear or patient following any product manager frameworks.
I mention frameworks because, during the presentation, the speaker suggested that data teams use a double-diamond framework when delivering data products. To be frank, here, I never used it as I never understood it, not like I did not try; I had a very hard time mapping it to the business where I worked so it could provide value beyond what I was already doing. I felt bad, so I reached out to my fellow product managers, who confessed feeling the same ”“ they never used the double diamond framework; and they were feeling bad and unprofessional about it, too. The bottom line is that every framework does not create value and it does not make sense if it’s implemented for the sake of implementation.
Developing a common language in the organization, a shared understanding of what should be achieved, is better than any fancy framework. And more offently this alignment is achieved in casual conversation next to water cooler rather than through the framework. It’s enough to sit down and brainstorm metrics and visualizations together with the data consumer when we are talking about BI analysts, depending on the task we are trying to achieve, obviously.
I expect the rage that this article will have, but hear me out; if you are striving to have a very descriptive process to avoid duplication of data products, which are eventually data sets for the majority of orgs, you might slow down your organization more and therefore create more harm than allowing data engineers to collaborate with data consumers in less rigorous way.
Yet it depends on organization structure, but in 85-90% of cases, empowering a data team with decision-making and accountability for what they are delivering could be way more productive and much more efficient than paying for extra data duplication in cloud storage because of the lack of having a standardized data production framework in place.
One way to improve the current disconnect between data teams and data consumers is coaching data teams in communication business stakeholders by facilitation this meetings, where true needs can be revealed, by simply understanding:
- What is the user trying to achieve (not what they need)?Â
- What they were doing before to achieve what they needed and why it does not work now?Â
- What would happen if we delayed this by a month/quarter?Â
- Are there any partial solutions that could help in the short term?
