Why Data Teams Are a Tax on the Business with Nick Zervoudis

Good morning, good afternoon, or potentially good evening, depending on what time it is, wherever you are in this amazing planet of ours. I’m Malcolm Hawker. I am the chief data officer of Prophecy and the host of the CDO Matters podcast. Thanks for joining today.

Today, we’re gonna talk about product management. We’ll talk about data product management. We’ll probably talk a little bit about data products. We’ll talk about product managers, all things related to product management, data products, and why you as a data leader or a practitioner, this isn’t just for data leaders, as a practitioner or leader should be thinking about being more like a product manager if you are an individual contributor, or if you’re a leader, product management as something that you should be integrating into your data and analytics function.

I can’t think of a better person to have this conversation with than Nick Zavrotis. Good to see you, Nick. Thanks for joining today.

Great to see you, Malcolm. Very excited to be here. Thanks for having me.

Awesome. So, Nick, you and I have traded content for for a few years on LinkedIn.

And I I there’s a very small cadre of people. Nick and I are in it. There’s a there’s a few others who are very passionate about product management. And I I post often about product management.

I was a chief product officer in a previous life. I have managed product teams. I’ve had a product p and l, hired product management, product managers, business analysts, you name it. So this is near and dear to me.

And and and Nick and I have been trading content for a while. We finally got a chance to meet at least virtually last week, and we’re like, okay. We we gotta we gotta do a podcast because we’re both so passionate about products and data products. Tell us what you’re doing today in the market, Nick, and then we’re gonna get into some of the questions that we talked about.

But what are you doing to help companies around product management today?

Yep. So I started a company, a one person training, consulting and community business a couple of years ago because I still think that you and I are far too much in the minority when it comes to how data teams are run. I also, as someone that has been a data product manager since longer than we’ve had the title go around, like nearly ten years now, I lived through the experience of what it’s like kind of growing up as a data product manager and that was a world with very few, if any, resources that I could rely on and having to kind of learn a lot of things the hard way because there were no books, no courses, not even blog posts about this topic, even though there’s a million articles and courses about product management in general or data work in general.

And so now I do a couple of things. The first is training. So I joke that I help data people think less like data people and more like business people instead.

A lot. Because that’s kind of what it is.

And so sometimes it’s working with data product managers and data product teams. Other times it’s someone that might be, you know, the data scientist or the engineer or the analyst that has to spend more of their time talking to people and wants to kind of improve those skills of theirs. And then I also help businesses through consulting work that’s kind of like a little bit like the course is the DIY version that’s like, let’s teach you how to do it. And a lot of the consulting work I’m doing is more, okay, come in and do this for us. Come in and run a discovery sprint for a few weeks so that we know where exactly we should place our next bets on our data and AI roadmap or come and work with our clients because we want to be able to demonstrate the financial value of our work.

You know, look, I’ve got a client, he’s the CEO of a SaaS company, he’s not going to sit through the course and learn how to do this stuff. And also he’s not going to have time to then sit with his end users and his clients in order to kind of prove to the CFO of each of his clients like why is it that you should be, you should keep spending money on our product because it’s making money back for you.

And then it’s not really I won’t say it’s hard to describe it as part of the business in the sense that it doesn’t actually make any money, but the third strand of what I do is community. I’ve been running a data product management meetup for the last three years. It started in London, then I moved to Barcelona and I started a chapter there too. We’ve been doing online stuff for, I’d say six or nine months now, kind of connecting more and more people that either have the job title, but they don’t know many others who do, or who maybe don’t even have the job title, but want to learn more about the non technical and strategic side of data work.

Yeah. So that’s that’s kind of what I do in a nutshell.

Well, thank you for doing it. One word that stuck out to me over the last little bit when you were speaking is the why. And and we I I really wanna drill down on the why. I know you’ve got perspectives here.

I’ve certainly got perspectives here. But we’re gonna spend the next thirty five, forty minutes basically selling the concept of product management in the data world, and that’s really the why. So I I I let you know, this is our opportunity for you and I to hone our pitch, right, to to to convince the practitioners and leaders out there that data management is an important thing. One other thing that you just said struck struck out to me was that you continually use the the the phrase product manager.

And to me, that’s normal. Right? Well, I I was a product manager. I’ve hired product managers.

I know what that word means or that phrase means, the title means.

However, in our world, most often people are have this title of product owner.

Do you see a difference between a product owner and a diff and a product manager? And if so, what is it?

It’s a funny one because on the one hand, there is no difference as in someone can be called product owner and do the same work as a product manager. But at the same time, there’s also a huge difference in terms of show me the average person that has the job title data product owner and also the average company that chooses to have data product owners versus product managers. And there are the differences like night and day because the conventional, let’s say use of the product owner, it’s a role that is very close to a project manager. It presupposes that someone, usually someone from up top has preordained what is it that the team should be doing?

What is it that our three year roadmap has in mind, and the product owner is kind of there to keep the wheel spinning. It’s maybe a little bit more than just project management because there’s some fleshing out of requirements to be done and also we call our things products, not projects, but by and large, it’s a waterfall approach to what should be happening. Whereas for me, a product manager is there to solve problems, right? It’s not there is a solution already in mind and I as the product owner, I’m here to just make sure that solution is to be delivered.

That’s the kind of high level description I would give of that difference. One is very solution oriented. It presupposes that we know the problem space well enough.

The other one is, let’s say, epistemically humble and understands that we probably don’t yet know because we’ve not spent the requisite time to do discovery and understand the user and understand the pinpoints and then figure those things out as part of developing the solutions that will become our products.

Yeah, love it. I would add one or two more.

One additional distinction that I see is that product owners tend to be very governance centric. Right? And and and and where their racing is focused on accountability and ownership of data or own ownership through the lens of we need to make sure that, you know, we we’d adhere to the governance policies that that we have associated to this given data product or this given nugget of data.

But also where the the focus is more on scale than customer success. That’s another thing that I see. When when I hear the phrase product owner, then I kind of almost immediately know, oh, what you’re trying to do is solve a scale problem. Right? How do I scale the data and analytics function?

And you’re not trying to solve a customer satisfaction problem or even a value problem. What do what do you think about my my perspectives?

Yeah. I agree. In a way, the first thing you mentioned, I kind of I file under the same bucket of what I described, which is there is a top down mandate for stuff and it’s part of your job to execute on that stuff. So governance are quote unquote agile policies and ways of working are the initiatives we’ve selected, they’re all given to you and you’re there to enforce and execute. The second one is interesting because that’s exactly where I’ve seen a lot of data product owners be. That’s where I’ve been, if I go by my official title when I was at PepsiCo, I was a data product owner.

But in practice, I don’t think it’s a correct division, if that makes sense to go, oh, we now know, you know, we’ve hit our product market fit, now we just need to scale it. Like at PepsiCo, had this where we had a number of internal capabilities that had been proven in some markets or in one market. And then they’re hiring people like me to scale them across more. So I was hired to scale a product called StoreDNA across all of Europe, But in practice, and the reason why I say it’s not quite a correct way to look at it is because we then start scaling across countries and we realize that, well, every country is a bit different. So sure, we’re not going to radically change what the capability is.

But if I had it drilled in my head that my job is to just take this templated thing and roll it out, we would have delivered projects successfully. We would have hit our timelines. We would have built what leadership asked us to.

But in terms of the outcome, we would not have been successful, right? Because ultimately the reason why Pepsi was investing millions in rolling out this capability was not because they wanted to roll out the capability, it was because they wanted to make more money. And ultimately that’s where a product owner is more focused on the outcome and will go out of their way to change the scope and fight people to say, are on the wrong track, we are trying to build the wrong thing. It’s either wrong because it’s wrong for this country or because the market has changed or because there’s new technology available or whatever.

Yeah. And so while often you hire POs for scale, I still think that is kind of wrong in the sense that you should still always be almost like solution agnostic to some extent and think, I’m hiring these people, sure, to scale a capability, but ultimately it’s still to deliver an outcome to solve a problem.

So I can I can tell you’re a product manager? Right? I I just in listening to you, I can tell you’re a product manager, and here’s how I know. I hope that’s Oh, it is good. And and and here’s how I know. Because when I was listening to you respond, what I said was, hey. A lot of people are misguided, basically, because they they assign this label a product owner and their whole mission is to scale.

You said then you said, well, you know, you should be scaling after you have assessed product market fit.

And and which is spot on, which is 100% accurate and is exactly how a product manager thinks. But that’s not how most product owners think. Right? What you just said, product market fit, That that that that is a very short way of saying that you’ve gone through the due diligence.

You’ve gone through the requirements definitions. You’ve gone through the design sessions. You’ve gone you’ve gone through the rounds multiple rounds of feedback. You you’ve probably put the market or the product out there and got a little bit of market feedback, and you have assessed.

It’s working. Right? This is economically viable. There’s demand here. We can we can and now let’s focus on scaling up.

Right? Like, it’s gone beyond proof of concept. It’s it’s gone beyond beta. Maybe it’s in limited release.

And now now you can say, we need to scale.

That’s exactly how a product manager thinks and that’s exactly how we all need to think more of. However, what I what I see is all the things that I talked about. Right?

A rigorous focus on customer success, rigorous focus on requirements definition, rigorous focus on product design. Right? Rigorous focus on on on on ROI and profitability of of the product. That stuff doesn’t happen in data teams, and they jump right to scale, which is, oh, well, data products are about scale. Right? There’s there’s there’s several people who’ve written wonderful books who have said, don’t talk to customers because because they will detract you from being able to scale your function. And the whole point of data product owners is to scale the function.

Meaning, if we build it, then they’ll come. Right? And and then and then we’ll assess product market fit. So anyway, it’s it’s it’s so interesting.

We use these words. Right? Like products and product owners. And and even in just a one little phrase, there’s such an interesting difference there.

Anyway, I I I love how you think.

Let’s let’s talk about you you had kind of mentioned this with the waterfall. Right? And you had kind of hinted on data product owners often as order takers. Right? That’s kind of how you how you how you define them.

There’s a lot of CDOs that are running their organizations as service desks. Right? That are that are put in the Jira ticket, and then we’ll work the ticket. And this is our way of being customer focused because we’re only doing what the customer asked. What’s the problem with the service desk approach, Nick?

Yeah. I mean, I think if you go on my LinkedIn profile, my banner says either stop being an order taker or service desk as like the very first line.

I am I know. I know.

Super against it.

Here here’s the thing. If I need a new mouse because my mouse broke. Right? I can just go to IT and they’ll say, need to file a ticket first. And I file the ticket, and I just say, I need a new mouse. I might even specify that I’d like a wireless mouse, not a wired one.

Something something along those lines. And all that really matters to me is, will I get this mouse in the next couple of days or in the next couple of hours? Because I know that I need a mouse, right? I don’t want someone from IT to reach out and be like, hey, like we actually have bought these like VR headsets or these gloves that you can use to navigate your computer more effectively.

Because it’s a very much like well defined and solved problem space, you know, I know how to use a mouse, I understand it, that’s what I need. Same with like, you know, if I need a new laptop, a new screen, whatever.

Crucially, when it comes to working with a data team, there’s two things that are missing, right? The first is the business stakeholders making the requests often are not as experts as I am in knowing that this is a mouse, this is what I need to use my computer and that’s what I want. Right? And very often it’s not just that they don’t, they’re not data literate, which is a phrase I don’t really like, but let’s say data fluent.

It’s also that even if they were, right? Even if it’s a business stakeholder that actually used to work as a data scientist for five years before becoming a commercial director, they might still not know what the right solution to put into that Jira ticket or ServiceNow ticket is going to be because we’re solving more complex problems than I need to control the cursor on my computer. Okay, do I get a mouse or do I use my trackpad? And so for that reason, ultimately, think a data team, not actually, I shouldn’t say I think, The data teams I see working in that way have a very low natural ceiling to the amount of value that they can provide because it’s only really cases where by coincidence or because of the simplicity of what’s going on, you are able to actually effectively match supply and demand.

You know, the problems you have with the solutions the data team can solve. And it’s not just that there is a ceiling, but there’s also a roulette, right? You’re taking a gamble that, oh, by coincidence, the dashboard that this VP of sales is going to ask for is going to be the dashboard that’s going to be needed. Sometimes you’ll get it right.

Other times you’re just letting chance and randomness control it. So that’s my kind of short version of my rant against service desks. We can have a much longer one as well. But I think and to people listening, you know, if some of the following sound like familiar patterns, that’s when you should start thinking that, okay, this is maybe what I’m in as well and I should do something about it.

Number one, you receive requests without context and at most you might reach back out to clarify things like, hey, you said you wanted weekly sales. Does that mean, say like daily sales refreshed once a week or does it mean sales grouped by week or something like that? Or did you want every country? All of it, please.

I want all of it, please.

I’m just kidding. Go ahead.

No. I mean, that’s super common too. Right? The second one is, and this one I think most service desks deal with just on a daily and hourly basis. You might deliver exactly what was asked for.

And then the stakeholder looks at it and they go, no, actually, can we make it something else? Or they might say, oh, that’s not what I meant. Know, I meant when I said weekly sales, which I think most people would probably interpret as sales groups by week, they might have meant, no, actually I want transaction level data. I just want to get it on Monday morning every day.

Something like that. So you’re kind of pulling your hair and going, oh my God, you’ll do this iteration multiple times they’re and probably still not going to be happy. And then the final kind of common warning sign that I see is you build the thing, you you were told that surgeon, you got the request at 4PM on a Friday and then silence, right? You might not even get those annoying kind of new requirements that are like, no, actually I wanted it like this or could we also add this other overlay?

You might just hear nothing or you might check out your login stats and see that this person hasn’t even looked at the dashboard. Or maybe they looked at it once and never again, and you’ve got this graveyard of dashboards or pipelines or reports or whatever that you’ve been building. And for me, often I talk to data people that kind of are frustrated at those symptoms, but the frustration is very much misdirected because they’re like, oh, it’s those stupid, annoying, irritating data illiterate people again. And they call them the business.

Like we’re not part of the business we work with. It’s us versus them.

And I’m like, I mean, yeah, sure. Sometimes it’s annoying and frustrating when your stakeholders don’t think things through or when they just tell you incorrect things or claim something is more urgent than it is. But by and large, it’s kind of your fault. It’s not theirs.

It’s your you are the data experts who’s meant to help them do things with that data. They’re not data experts. And unless if they’re planning a career change and to move into your department, you cannot expect them to become that. Right?

Just like the, you know, data scientist turned commercial director, which by the way, not going to name who it is, but that person was my manager and it’s a real occurrence. Right? It stopped being his job to understand the intricacies of the data and he was still much better than most business stakeholders I’ve had. But ultimately his job was to have conversations with other parts of the business.

His job was to be responsible for the profit and loss of our product and our department. It was not to think about different algorithms or to specify what pipelines we should build or to, I don’t know, supply data dictionaries and things like that.

Anyway, I’ll stop rambling.

No. So yes, yes, yes. I’ve seen this over and over and over again. I was in it. I did it. Right? And and let’s assume positive intent, which I think is is is so important for for everybody in in in all professional life.

100%.

But let’s let’s assume the intent was I wanna give the customers what they want, and I wanna increase my throughput.

Right? Like, let let’s assume and those are those are those are good things. Right? I wanna give the customer what they want.

Right? And I wanna increase my throughput. And maybe I’m a little more technical. Right? I come from a technical background.

Maybe I’ve I’ve come from traditional IT where where it’s normal to put in the Jira ticket. Right? And, you know, and to manage and this is a very ITSM way of looking at the world. Right?

And and that’s not a wrong way of looking at the world, but your metaphor is spot on. Right? Asking for a mouse or to fix my broken laptop. Right?

Or or or or what or whatever, a new employee setup, doesn’t matter. These are very different things than help me optimize my business process.

Right? These are your metaphor is is so good because it’s like, I know what the mouse is. I’ve got a broken laptop. I need a new employee to be set up. I need a half off a hole punched in our firewall. Doesn’t matter.

Those are really different things than, hey, can you devote some consulting resources to help me understand the insights that I need to better run my business? And that’s that’s what people are asking for when they want data. That’s what they’re asking for. Because they’re gonna take that data and they’re gonna optimize a process, or they’re gonna make a decision.

And sometimes they don’t know. And what you what you said is is so accurate because I’ve seen it over and over again. So let’s assume positive intention. I wanna increase my throughput. I wanna answer more questions.

I’ll stand up a service desk, and and then and fast forward, everything you described, I’ve seen play out over and over and over again. They don’t know what they want.

Or they keep asking for the same thing over and over again, or or I end up with 400 dashboards that nobody uses.

Right? Which is what you or the situation you you described. And at the end of all of that, it’s an Us versus them.

Right? And and and for many CDOs, it’s, oh, well, you know, we need to train these data illiterate people because they keep asking for dumb stuff.

Right? Or they don’t know what to they they don’t know what they want. Right? I’ve heard that. How do you react, like, as as as a product person when you hear if you heard a product manager say, hey, boss, you know, they don’t know what they want.

What’s your reaction to that?

Yeah. It’s, you know, usually trying my best to put on a poker face is part of it.

But, you know, I think so much of this is rooted in a very weird thing that’s happened in our industry over the last couple of decades. And I can’t claim I’ve studied it like a historian and can point you to the root cause. There’s a part of me that thinks maybe the root cause is just how much money BI vendors have thrown into our conferences and our trainings and whispering in the ears of the CDO. Because I’m like, why is the main function of the data team to democratize data and to either enable self serve access of data or to just provide data to many stakeholders.

I’m not saying those things are not things that should happen, but why is that the number one mandate for so many organizations? And I’m biased because I’ve spent most of my career not doing that stuff. I’ve spent most of my career going, we have identified something very specific. It’s only going to affect a handful of users or it’s only going to be provisioned to a handful of users.

And in some cases it won’t even be provisioned to human beings because it’s something like we have built a price optimization engine that’s going to automatically change the prices on our e commerce store. We have built a demand forecasting tool for our supply chain team so that they can make sure that things don’t run out of stock inside stores. We have built a space optimization module to make sure that in this supermarket you have two shelves or two bays of shelves with cheese versus this one has three versus this one has four. And we’re figuring out what’s the right assortment in each place.

These are all use cases that have nothing to do with dashboards. Maybe there’s the odd dashboard, but it’s mostly like models being integrated with other systems, other software, and with workflows that people in the business have. The reason why they’re selected is because they have an outsized impact, right? You build this one thing, it costs the business 300 ks to make and you see an uplift in millions versus giving Bob access to more data, but in the end he’s probably going to make a gut feel decision anyway and it’s going be better than what the data says because Bob’s really good at this and has been doing it for decades.

Like why the obsession with giving Bob more data and deploying data literacy everywhere? Again, I’m not saying these are not things that shouldn’t happen because I’ve seen what organizations where every Bob is great at using data for their different jobs, like that’s great too. But I’m confused as to why that’s often the starting point for becoming a more data mature organization.

I’m not confused. And you touched on it. I’ll say it. Per seat license cost at BI tools.

That’s the answer.

Right? And and and the more seats, the more money. Right? How how do we incentivize people or how how do we facilitate more seats?

Well, make people in the business savvy enough to use the tools so that they don’t need the central IT organization. Because if there’s only central IT or a central IT is is building out the dashboards themselves, right, or is managing those interactions, you’re not gonna have as many seats or maybe you don’t even need a dashboard. If you have a good product manager, to to your to your point, what like, to to your point, these these these are higher order questions. Right?

These are these these what we could be delivering is greater value things. We could be consulting on how to improve a business process. Right? We we could be consulting on how to how to run the business better or even maybe investing in decision science and tracking the effectiveness of decisions.

But instead, we’re investing in more seats because we’ve all bought the idea that democratization is inherently good.

I don’t think it is. I said it. There. I said it. I don’t think it is.

And the reason why I don’t think it is is because not all of our customers are the same. I go to the grocery store, and I can walk in. And in in one part of the grocery store store, there there there is, like, peanuts, like, bulk peanuts, and I can make my own peanut butter.

That’s great. For me, maybe I know how to make peanut butter. Maybe I’m okay with stirring it up every time I open the jar because the the the peanut fat has separated from the nuts. Maybe that’s okay with me, or maybe I’m value conscious. Maybe that’s all I can afford is to buy the the peanuts and make the the peanut butter myself.

Or I can go buy the peanut butter out of the jar. Or maybe I can even go order something else that is and maybe my end goal is to put the peanut butter into a a baked good, and I can go buy the finished baked good. Product manager would say, you need to offer all of it. Some of your customers are gonna want the the the low cost.

Right? Some of your customers are gonna want the the the thing in the middle, and maybe some of your customers are gonna want the finished product. That’s what a product manager would say. And I would charge one thing for one and it’s something else for another.

Right? That’s what a product manager wouldn’t say, and this starts to get into product thinking, but we’re gonna talk about product thinking.

But what you said what you said is spot on, which is which is maybe there are twisted incentives here where we have just bought this line about all democratization is inherently good. I’m not sure it is because because you said it yourself. CEO of of a company’s not gonna log in to to to Tableau and go pull the report himself.

It’s not.

And if that’s true for that person, maybe it’s true for the VP and the director. It’s not true for everybody.

Anyway Oh, yeah.

That’s my rant. Sorry.

You know, I I wanna add something because you you you got me thinking. Yeah. For I I think for sure, vendors exerting influence on the enterprise is partly to blame. But I think the other part is what you mentioned that at the end of the day, the business sees IT as a cost center, right? They see effectively you are a tax on the business that for every thousand euros in revenue or for every thousand people in headcount, my costs will also go up in the same way that I need to get laptops for everyone, office space for everyone, insurance coverage, and so on.

And I think that’s part of the problem. The worst thing is we are making the same exact mistake with rolling out AI across the business right now. Oh, let’s get co pilot seats for everyone. And there’s a part of me that’s like, we probably should because I mean, an AI assistant is an amazing thing to have and I could not go back to working the way I used to before I was deep into Claude and Codex.

But I think that that kind of incentive there, it’s more the internal decision making incentive. It’s not there’s some conflict of interest. If I’m like, yeah, the money I spend on IT is a necessary evil. And as a result, I should look to minimize it.

And I’m going to hire a CIO and a head of IT whose mission is going to be, how do I minimize it? That’s also how you get things like, we are paying for teams, not slack. We are paying for teams again, not zoom. And maybe these days Power BI and Teams are about as good as their competitors.

That was not the case five years ago. Five years ago, the businesses that had those usually Microsoft or other like cheaper, more cost effective vendor provided tools, were doing it to minimize costs, not because they genuinely thought that Power BI back in the day was better from a user experience or a development experience point of view than Tableau.

So a lot of it has to do with, are you seen as a cost center or are you seen as a value creator? Because a value creator means like think marketing, right? If I give marketing another thousand dollars to spend on ads, I will make that money back. And so that’s why in a lot of businesses, marketing budgets are in the hundreds of millions because there’s a lot of money to be made from that. It’s not just, yeah, let’s try and give everyone the ********* laptop we can and minimize costs because at the end of the day, yeah, you might be a bit annoyed that your laptop screen is one inch smaller but we just want you to get your job done and for our IT bill to be minimized.

You are, again, you’re onto something and this perception of a cost center, you call that a tax on the business, love that phrase.

That’s if if you run your organization as a service desk and an order taker, then you are a tax on the business.

If if you if if you cannot articulate the value that you drive to the organization, this is also something we need to talk about. Maybe we should have booked more than an hour.

If if you’re not tracking the value and most of you aren’t, right, and you’re only seen as a cost, well, then that’s exactly how you’re gonna be perceived as as a as a cost. Right? So I do wanna tie off on the on on one of my least favorite subjects, which is data literacy.

And and and and you raised that issue as well.

And data literacy has a very interesting history, and I actually touch on this in detail in my book, where I I would argue I would argue the the birth of the modern data literacy movement was was was a result specifically from a report that was commissioned by Click. K? BI vendor. Right? And and the and the person who commissioned the the report and who and who evangelized the report is a wonderful human being who cares deeply about our industry. His name is Jordan Morrow. He’s written multiple books.

Jordan screams positive intent. He’s a wonderful person, and he cares deeply about our industry. However, if you trace back the history, what you will find is that click commissioned a study with with the intent purpose of trying to understand how do you put more Click licenses into the hands of people in the business. Right? Well, you make them smarter with data. You make them more comfortable with data. You make them more data lyric, and you produce research that says that that that, you know, your companies are not driving value from investments in data and analytics because people lack literacy.

People are like, oh, wait a minute. Hold on a second. I can finally be seen as a consultative value driven aspect of the business by just making them smarter. Right?

And it and from there, 2019, ****, took off. Gartner jumped on it. Gartner jumped on the bandwagon, started putting data literacy on their CDO surveys every year, and and and here we are. Now data literacy is is firmly rooted.

And where I think it came from, again, I touch on this in in my book, where I think it came from was trying to sell more seeds of BI tools.

So I I mean, you know, maybe I got too much of a tinfoil hat going on here, but but but anyway, I gotta I gotta get you a copy of my book. You’ll love it. Anyway Please. Product thinking.

Product thinking. So there’s a lot of people out there talking about the importance of product thinking. I’m hearing a lot of this on on LinkedIn. And, well, we need more product thinking. When you hear product thinking, what do you think? And do you think there’s a disconnect between what most people would call product thinking and what you see as product thinking?

So let’s take the questions one by one. The kind of one or two things that jump in my mind when I hear it are number one, product not project.

Number two, problem solving.

Well, number three, though it’s the same as product not project in a way, outcome not output.

And that’s that that’s kind of because it a lot of it and and the way I actually introduce product thinking in the course that I’ve got is actually by starting with, Hey, let’s just compare projects versus product. Let’s start with what are the fundamental attributes of what makes up a product, sorry, a project. And it’s things like we have a predefined budget and scope. We’ve got a timeframe we need to deliver against. Our success is measured in terms of hitting our time goals and our budget goals.

And then contrasting all of those against what it means to be product thinking and product led, and the fact that at the end of the day you are here to solve problems for your customers, for your colleagues, whoever your customer is going to be.

And so much of it flows from that point. And in that sense, when someone says product thinking, I mostly find myself in agreement with them, right? There’s going to be disagreements at the margins, but broadly it means that, okay, this is someone that gets it, someone that’s in the know, and someone that’s talking about data products the way I am.

Importantly, it’s when someone mentions data products that I go it’s a little bit like when you first meet someone and you want to suss out where they stand maybe on divisive political issues or things like that where you go, oh, this person’s talking about this term, but let’s see where this goes because, you know, is that sentence gonna finish with, I don’t know, I hate immigrants and we should Contract.

Like, data contract or something. Yeah. Yeah. Yeah. Go ahead.

Yeah.

No. That that that’s where I see the big set of question marks of like, oh, okay. Is this person and I you you posted a diagram probably a couple of years ago that I really liked that talks about, do we see things more from the point of view of how do I make things more convenient for me, the data team, or do I optimize for the business? Exactly.

And so much of it is that, right? It’s the same as what you were talking about earlier in terms of, do I hire data product owners for scale? And really my response to that was, well, if you want to scale the right thing, you still need product managers. But if your concern is just scale from a, my data team, my budget, my people are stressed, you just go, how do I make sure that instead of provisioning a thousand different tables, I can have one reusable sales kind of golden dataset that people can use?

And for me, it’s not that one is right and one is wrong, but you kind of need to understand which is which. In the same way that with data literacy, right? I have a lot of friends in big tech and I talk to them, they’re in totally non data related departments. And whenever they talk about the things they do with that data and their dashboards, I’m like, damn, that’s at the level of data fluency that often I wish I had data analysts at, right?

And you’re killing it. That’s awesome. So it’s not bad that they’re data literate. It helps them do a much better job at It’s their just that usually in most businesses that can come way later as we are trying to get value out of data.

For me, I’m like, you almost certainly will get more bang for your buck initially out of a small number of initiatives where it doesn’t you just need maybe a couple of the business users to understand what’s going on with the data. The rest of the business can be oblivious, not just on how to use data, but as to the existence of our marketing price optimization engine or marketing attribution model. They don’t even need to know that it’s there, but it’s making money and it’s helping the business grow.

Yeah. I I’m thanks for mentioning that that post, which which obviously I agree with. But but basically, what I said was problem my idea of product thinking, and and thank you thank you for sharing yours. And I agree.

Any product thinking is better than no product thinking. Right? And and typically, when I hear people talk about product thinking, it’s a yes and. It’s always a yes and.

It’s not a no. It’s a yes and. And what do I mean by that? Well, you know, what what most people I think when they say product thinking, getting back to my diagram.

My diagram basically split product thinking into two different worlds. One is this idea of a shift left where your your primary focus is on scaling a data function and shift right, which your primary focus is customer success. Right? And and and and and most of the time people are shifting left.

What I hear is a shifting left. And that’s great. Right? And and that’s that’s that’s really good, but it’s not the only thing.

That’s kind of the whole my my whole idea here is, hey. It’s shift left and shift right. And the reason why we need to is because not all customers are created equally. Right?

Sometimes you need a custom bespoke product that you one dashboard that only gets one view that is only used once. But if the CEO asked for it, you better be prepared to make it. Right? Because that’s the high value customer who’s gonna make an important decision about a merger and acquisition that could be worth billions to your company.

Right? In that case, you say, all right, I only built a dashboard once, but if it’s worth billions, okay, cool. On the other end of the spectrum, you need repeatability, you need scalability. That that is exactly the scenario you described.

Right? Which is the the one customer table that can be used millions of times instead of 15 different versions of the same table across different divisions. You gotta be doing that too. You gotta do both.

Right? It’s not an either either or. Particularly in an agentic world, you need to be shifting left because the agents, if you view agents as customers, and I do, they’re just an automated form of a customer. They’re a machine customer instead of a human customer.

We need to be able to serve them too, and increasingly, that’s where we’re going. So I love it, man. I I I love the product thinking. I I can tell you’re a product manager.

Another reason why, by the way, here’s here’s here’s how you will know, friends, if you’re listening. Nick keeps using the word customer, and I love it.

I I love it. Just just using that word matters, I I I think. Anyway, last topic, value. Let’s talk let’s talk about value. I saved the hardest one for I saved the hardest one for last.

You know, I know you and I think alike on this, but if I’m one of your potential clients and I say, hey Nick, heard you on CDM Matters podcast, love what you’re saying.

Heard you talk about becoming more of a P and L, more of a value driver. I don’t want to be a cost center. I don’t want to be taxed in the business. I want to be the thing that is driving value. What are some of the things that you’re gonna advise to that potential client?

Yeah, so, well, first the classic answer, it depends as in who am I talking to and what’s there. Just in the sense of, if someone’s like, hello, I’m a data scientist or data analyst, how can I be more value focused in my work? We’ll go through much more tactical answers than, I’m a head of data, I want my whole team to start thinking this way, I want to reorganize our operating model. But broadly speaking, I think usually you kind of have a flow that starts with, show the value of what you’re doing now in a kind of retrospective way.

And over time you want to be optimizing for it, right? Because you kind of need both. You need to know, am I delivering value today? If so, how much?

Because at the end of the day, even the dashboard graveyards are delivering value. Probably not every individual dashboard. I’m happy to say that there’s a lot of dashboards with zero value, meaning actually it’s negative because it costs some money to build. Exactly.

But you’re going to have some stuff that, you know, you won the lottery, you helped inform that M and A decision, someone in marketing is using it to make decisions around, should I spend more on radio ads or TV or Instagram or whatever.

So it’s partly a question of, okay, how can I start getting credit for this stuff? And that’s not just because it’s going to help you ask for more headcount or get a promotion or get a pay rise. So those things are nice side effects too. But it’s also to show to the bit to make the case for things like, why do we need to invest in the data quality of this particular pipeline? Well, because 5,000,000 is at stake. Right? And that’s the kind of linguistic framing that’s going to get a lot of your business stakeholders who are previously they couldn’t care less or it seemed like they couldn’t care less about your mounting technical debt and data quality issues and lack of data ownership and all those other things that we data people really care about.

At the end of the day, the thing that’s going to get them to understand the magnitude of the problem is how much money is at stake. And it could be potential revenue we’re losing out. It could be more customers churning. It could be mounting costs.

Any of those things, even kind of more intangible risks like the risk of us being front page news and not in a good way because there’s been a data breach or some other issue with our data driving us in the wrong direction.

And so you want to start with, how can I demonstrate the value of what I’m doing? In parallel to that, especially if you’re still in a service desk fashion, you want to start also estimating the value of things to come. Right? Bulbs come again with a data request. And I’m not saying your ServiceNow input form now needs to have one more field being like, many dollars is this request worth? Because that is something that your stakeholders will both not know what to do with. And also they’ll just put a big number to game the system and it’s going to be useless for you.

But start understanding the why behind requests. Right? For me, anytime there’s a new request, the first question cannot be, do you want it in CSV or Excel? Or do you want the charts blue or pink?

Or do you want the period to be year to date or the last twelve months? The first question is always like, hey, can you give me a bit more context around where this request is coming from? What project is it part of? Or what are you hoping to get out of it?

And you’d be surprised at how much you can learn both about the value of the something that is being requested, but also about what the solution should ultimately be. And sometimes off the back of that asking why and effectively forcing your stakeholder to take a moment, almost like reflect back and explain themselves, very often you also find out that this request is not needed.

Right? And I’m not talking about all this like simple dashboard is not needed. Like so many times, and I’ve seen this both with my own work and with work of people I’ve worked with, you ask things like, Hey, so this feature that’s part of our global deployment roadmap that we’re going to roll out in your country, I’m just curious, who’s going to use it in your country? And then the stakeholders are like, Oh, actually we don’t really have a need for that because our country runs a little bit differently to the other ones.

And then suddenly you go, oh, so should we kill this six months of engineering work that it would take for us to build this as part of scaling this capability? That’s a real story. That’s a real story from someone I worked with who asked in the same level of simplicity as I’ve described those kinds of questions and figured out that the value there is negligible, which means that you’re not just being difficult and saying no and rejecting requests because you’re drowning and have too much work, which is what we all are hoping to be able to do. You’re saying no by just getting the stakeholder to give you the reasoning for the no instead.

So anyway, that’s the kind of short version of how I’d start, right? Show the value of what you’re doing and also try and get the value and estimate it upfront before a single line of code is written. Over time, you’re going to get to more things like we’re going to prioritize based on expected value. We’re going to check our homework and say, we worked with Bob, we estimated that this marketing optimization model is going to make us 10,000,000 a year.

Well, it’s been a year. Have we made the 10,000,000? Have we made more? Have we made less?

And if less, have we made like half as much, which is still okay? Or have we made 1%? If so, we need to have a stern conversation with Bob about how we estimate value in the future because actually we’d lost money building this thing because we thought it would make 10,000,000 and it only made 100 ks.

I love it. So everything you’ve heard just heard, my friends, is be a consultant. Ask questions. Be curious.

Push back on request to better understand why. What problem are you trying to solve? Be be that internal consultant. I would argue, this is getting back to our original conversation about the why.

Right? Behind every extremely successful product or every colossal product failure is product management. And when product management is good, right, you build great products that are providing material financial benefit that your customers want and what customers will demand, and you build them in a way that is scalable, that is repeatable, right, that is financially responsible. Right?

If you do all those things, the the tip of that spear is absolutely product management. Understanding what customers want. What will they pay for? What will they not pay for?

That’s I think that’s a worthwhile north star. I I agree with you, Nick. Like, the idea of I I find it a useful exercise to to think about maybe putting a price tag on everything. We’re a long way from that.

We’re a long way from that, but it’s it’s an interesting thought exercise. But my whole point here is, will your customers want to pay you? Right? Do they see the value in what you are doing? It all starts with product management.

We all need to be more like product managers. I would I would argue if there are two people that you hire next year, if you’re in a leadership role, hire a product manager and maybe then hire even somebody that I would call a value engineer. But all product managers who are any good at what they do can understand cost benefit and who can do ROI models, who can understand the cost of of building and marketing and training a product. So, Nick, I this this is this is awesome. We could talk for hours.

I hope we’ve made a strong case for the benefits of product management, but just in case maybe we haven’t and people need to be convinced a little bit more and they wanna see a little more of your content. They wanna read a little bit more about the insights you share around product management. How would they get in touch with you?

Yeah. So I post a lot possibly too much on LinkedIn. My name is Nixar Votis and I also run a blog under the name of my company, which is Value From Data and AI. So the URL is blog.valuefromdata.ai.

Lots of ramps there. And I just want to very quickly do, maybe not disagree, but do a yes and on what you just said, Malcolm.

Because you’re like, you know, we are long, long way away from being able to put a price tag against everything.

My experience has been, it is much easier than thought. Now I’m not talking about quantify the precise value, but if we’re talking about order of magnitude, for example, is this a 6 figure opportunity or 7 figures? And usually a bit more specific than that, like, it a 100 to $2.50, $2.50 to 500, 500 to $7.50.

That is surprisingly easy. It’s not just that it’s easy and so you might as well do it. But by trying to get to that order of magnitude of roughly how much is this worth, you’re answering the deeper and more important question of what value is this going to create? And as a result, the answer might be, oh my God, we need to prioritize this for our team because there’s a huge amount of value, right?

It’s that billion dollar question behind the merger. Or the answer might be, this is really like a nice to have that we might get around to answering, but it’s just not worth it. And your stakeholders will agree. So that’s my soapbox pitch for why you really should try and get to that financial figure and not just think that’s one for next year.

Like you can do it this year too.

You’re right. Crawl, walk, run, and we could all crawl when it comes to this. And it doesn’t have to be perfect. Right?

Oh, yeah. It it it can just be a ballpark estimate, but then what you’ll do is to your point, do your homework, follow-up. Right? Build some of the models.

We’ve got AI now increasingly that can that can help us understand some of these correlations between investments and data and maybe even causal relationships between investments and data and actual business performance. So, I agree with you. Thanks for the check on that. Nick, thanks for joining today.

It’s been fun.

Thanks for having me.

I had a blast.

Good stuff. Alright. If you have stayed with us this long, thank you. Thank you for being a member of this community.

If you enjoyed this content, please like. Please subscribe to CDO Matters podcast through your provider of choice or, you know, check us out on YouTube. We publish every two weeks. With that, thank you for tuning in.

Thank you for supporting this community. I will see you on another episode of CDO Matters sometime very soon. Thanks all. Bye for now.