Today I’m joined by Nick Zervoudis, Data Product Manager at CKDelta. As we dive into his career and background, Nick shares insights into his approach when it comes to developing both internal and external data products. Nick explains why he feels that a software engineering approach is the best way to develop a product that could have multiple applications, as well as the unique way his team is structured to best handle the needs of both internal and external customers. He also talks about the UX design course he took, how that affected his data product work and research with users, and his thoughts on dashboard design. We discuss common themes he’s observed when data product teams get it wrong, and how he manages feelings of imposter syndrome in his career as a DPM. 

Highlights/ Skip to:

• I introduce Nick, who is a Data Product Manager at CKDelta (00:35)
• Nick’s mindset around data products and how his early career in consulting shaped his approach (01:30)
• How Nick defines a data product and why he focuses more on the process rather than the end product (03:59)
• The types of data products that Nick has helped design and his work on both internal and external projects at CKDelta (07:57)
• The similarities and differences of working with internal versus external stakeholders (12:37)
• Nick dives into the details of the data products he has built and how they feed into complex use cases (14:21)
• The role that Nick plays in the Delta Power SaaS application and how the CKDelta team is structured around that product (17:14)
• Where Nick sees data products going wrong and how he’s found value in filling those gaps (23:30)
• Nick’s view on how a digital-first mindset affects the scalability of data products (26:15)
• Why Nick is often heavily involved in the design element of data product development and the course he took that helped shape his design work (28:55)
• The imposter syndrome that Nick has experienced when implementing this new strategy to data product design (36:51)
• Why Nick feels that figuring things out yourself is an inherent part of the DPM role (44:53)
• Nick shares the origins and information on the London Data Product Management meetup (46:08)

Quotes from Today’s Episode

• “What I’m always trying to do is see, how can we best balance the customer’s need to get exactly the data point or insight that they’re after to the business need. ... There’s that constant tug of war between customization and standardization that I have the joy of adjudicating. I think it’s quite fun.” — Nick Zervoudis (16:40)

• “I’ve had times where I was hired, told, 'You’re going to be the product manager for this data product that we have,' as if it’s already, to some extent built and maybe the challenge is scaling it or bringing it to more customers or improving it, and then within a couple of weeks of starting to peek under the hood, realizing that this thing that is being branded a product is actually a bunch of projects hiding under a trench coat.” — Nick Zervoudis (24:04)

• “If I just speak to five users because they’re the users, they’ll give me the insight I need. […] Even when you have a massive product with a huge user base, people face the same issues.” — Nick Zervoudis (33:49)

• “For me, it’s more about making sure that you’re bringing that more software engineering way of building things, but also, before you do that, knowing that your users' needs are going to [be varied]. So, it’s a combination of both, are we building the right thing—in other words, a product that’s flexible enough to meet the different needs of different users—but also, are we building it in the right way?” – Nick Zervoudis (27:51)

• “It’s not to say I’m the only person thinking about [UX design], but very often, I’m the one driving it.” – Nick Zervoudis (30:55)

• “You’re never going to be as good at the thing your colleague does because their job almost certainly is to be a specialist: they’re an architect, they’re a designer, they’re a developer, they’re a salesperson, whereas your job [as a DPM] is to just understand it enough that you can then pass information across other people.” – Nick Zervoudis (41:12)

• “Every time I feel like an imposter, good. I need to embrace that, because I need to be working with people that understand something better than me. If I’m not, then maybe something’s gone wrong there. That’s how I’ve actually embraced impostor syndrome.” – Nick Zervoudis (41:35)

Links

• CKDelta: https://www.ckdelta.ie
• LinkedIn: https://www.linkedin.com/in/nzervoudis/

Transcript

Brian: Welcome back to Experiencing Data. This is Brian T. O’Neill. Today, I have Nick Zervoudis on the line. How’s it going, Nick?

Nick: Hey, Brian, great to be here. How are you?

Brian: Good. It’s nice to finally meet because we’ve been bouncing ideas around on LinkedIn for I don’t know how long. You’ve been in the data product management space for a while and I really enjoy your posts on there. And it’s so funny because I had thought that I had invited you on the show, like, a long time ago, and then I realized in our chats, like, I never did. And I think it was Jon Cooke, maybe, in our community that mentioned, like, “You should get Nick on the show.” It’s like, “I think I asked him. Oh, I didn’t ask him.” [laugh]. So anyhow, I’m glad that you’re here and welcome [laugh]

Nick: I’m super glad to be here. I have been loving Experiencing Data for, I think, well over a year now. So, excited to be a small part of it.

Brian: Yeah, I hope you’re going to be a big part of it here. So, you’re posting some really great stuff here, and as I sometimes say, like, I feel like you get the joke. Like, I come at this whole data product space from a designer’s mindset, from a software mindset, from a real product-y mindset. And we were just kind of talking, we were having a debate about another person that’s, like, “Data is just a packaged whatever,” and like, you know, one of these, like, hypothetical debates: “Is this a data product or not? But what if I build a data mart and it’s this and that?

And it was a solid question, you know? It was a totally valid question, but it’s coming from such a different place, which is okay. And then there’s people that I feel like they get the joke and they understand the product management thing and the fact that we’re bringing a product-oriented approach which is about value creation, benefit delivery, the exact format of what the output of the data thing doesn’t—is it a dashboard, is it an app, is it just a model? Like, it’s less important what the contours of the output is. And like, I don’t know, you tell me, is that where you’re coming from? That’s—I feel like you kind of see the world that way. But maybe you don’t? I don’t know.

Nick: Yeah, no, I think I do. And it’s because throughout my career, I’ve worked on data projects on data products, and they’ve been quite diverse, so I’ve kind of learned to recognize that one day, it’s a dashboard, one day to machine learning model, one day it’s, from the point of view of the customer, an email notification. So, it’s very straightforward to me to say that, okay, if I try to have a descriptive definition of a data product, that oh, it’s a CSV file, it’s a dashboard, it’s an API, that’s going to exclude many things that, for me, are so obviously that: they’re their data products. The other thing is, I started my career in consulting. So, for us, it was completely kind of the normal way of doing things: you go in, you understand the client’s problem or you help figure it out together with them because often they’re not sure what the problem is, maybe they just—their issue is the symptom and you’re there to find the root cause, and then the solution comes next.

So, it’s been a very normal way to do problem-solving for me and then translating that and putting a different label to it and saying, “This is product management is how I think about it.” I don’t want to be, you know, like the Web3 blockchain tech bros that have a solution in search of a problem, so that’s always at the back of my head. And that’s why I always avoid any kind of definition that says, “Oh, this particular technical implementation is the thing you need, is the data product, is how we should be doing things.” Because the answer is, “Well, why? Well, what’s making it the best solution in this instance?”

Brian: Yeah. Given that it sounds like you have some parameters for what you don’t feel like should be in a definition, do you have a definition of data product in your mindset in your worldview?

Nick: I do. I’ve not written it down, so I say it in a slightly different way each time. But broadly speaking, I think we should be defining a data product not by looking at what it is, but rather how we go about creating it because it’s the processes that go behind it that make the difference. Superficially, you might end up creating the same thing by not taking a product management approach, by not, you know, studying your users' needs and validating the solution with them, building together, and you might, you know, by just coincidence, end up creating the same thing. My argument is that the former is a data product; the latter is an artifact that happens to be useful.

And that’s the definition I encourage people to take because ultimately, getting it right by sheer luck, is the thing we’re trying to avoid through product management, right? That’s why tech companies have product managers. It’s not because a startup founder is never going to land on the right ideas through their background and the inspiration they had. It’s more how do we get it right consistently? How do we not just land on the right idea by chance, but how do we systematically have a process that lets us build the right thing at the right time, in a way that’s good for users, and good ultimately for the business that we work for?

Brian: So, this definition of data product that you have right now, is this something that has—I know you’ve been at—you were at Pepsi earlier, you’re at a company called CKDelta now. Has this been an evolution to arrive at this or is this kind of like, “Nope, that’s just always how I’ve approached it and thought about this?”

Nick: Well, it’s definitely not how I’ve always approached it because I was a product manager for data products before I knew that phrase, ‘product manager.

Brian: Okay [laugh].

Nick: [I’ve 00:05:53] very much been an evolving, kind of, artifact. Honestly, I could not tell you at which point in time I even had the phrase ‘data product’ as a thing in my lexicon.

Brian: Right, right.

Nick: I think it probably was when I joined PepsiCo because that was the job title, and then that got me reading more and understanding and actually solving a bit of an existential crisis I’d been having up until that point, which was, “I think I’m a product manager and yet, the things I do are so different to what I see online product managers do,” because most resources online are about B2C products or B2B SaaS products. There are very few things about internal products which is what a lot of the data products I’ve worked on are, or external ones, like the ones I’m working on now at CKDelta. So, the fact that there was a word to describe—or two words—to describe what it is I’m working on, kind of helped bring a bit of clarity and say, “Oh, this is just a different bucket.” It’s just like, you have SaaS products and mobile applications and platform products; you also have data products. And that was, for me, the origin of thinking about, okay, if this is a bucket, it’s a category, what is special about this category? Like, how do we define it and how do we think about it? And for me, the definition is not so that, you know, I can, when I tell people what my job is, to be like, “And by the way, a data product is blah, blah, blah”—

Brian: Right, right.

Nick: It’s more for my own ability to think about what is it that I should be doing. What is it that my team should be doing? Where should I be pushing back, for example, on the fact that we may not have done sufficient discovery work for a particular piece of work and challenging that? And sometimes the challenge is accepted, other times the answer is actually no, we’ve done discovery, just not by calling it in that way because we understand the customer’s domain in a really good way having worked with them for years. So, I don’t know if that answers your question or it’s the answer you were hoping for, but that’s what makes sense.

Brian: No hopes. Just curious. Maybe for additional context, can you give us a recent history of, like, the kinds of—just so people can understand what it is that you do, what are some of the data products that you built in your past career and maybe currently at DeltaCK—I’m sorry, [laugh] CKDelta. Apologies.

Nick: Yeah. I guess I can take it from the beginning. The first product which I kind of helped design from inception all the way to shipping was for a big retailer in the UK. And it was a—we called it a spatial analytics platform, basically helping the stores’ management decide how to trade off space between different categories. You know, should I give up a bay of cheese to have a bit more ham or or bread in this particular store? What’s more productive?

So, that went from, we built the model beforehand, but then what was needed was the interface to truly integrate into the workflow of the users. And that was a very seamless transition between consulting work and eventually figuring out that this random mix of things Nick was doing has a title and it’s called product management. More recently, at PepsiCo, I was responsible for a product called ‘Store DNA’ and it was—the way I explain it is it’s like having a huge Excel table where every row is a store—a PepsiCo customer—and every column is a feature about that store, be it its location, the footfall in that store, the sales it’s pulling through, and like, literally hundreds of other pieces of information about what’s in the vicinity of that place. It wasn’t one big, big Excel table. It was—you know, the actual data model was different, but that was how I would kind of explain it to others.

And its purpose was serving as a platform for building, kind of, clever models or dashboards on top to help the sales team prioritize their efforts. Like, what are the customers I should go visit more because they have a greater potential versus the ones that maybe I’m going to too often, or I’m trying to sell them the wrong things? So, it was a purely internal-facing product, but it very much acted like a product, you know? We had users, there was a problem that we were solving, there was a roadmap that we were building through. And there were different internal customers because every country in PepsiCo is a separate business unit and had different needs, different budgets, and all that.

And more recently at CKDelta, I kind of—I’ve switched to the other side, let’s say, and instead of having internal-facing data products, I also look after external-facing ones. So, one of the many different types of companies that the conglomerate that CKDelta is part of owns is telecoms companies. They own ten around the world. And what we do is we take anonymized data from those companies to understand basically where people are going, where they’re coming from, how long they’re staying somewhere, not at the individual level, but at an aggregated level instead. And what’s really exciting about that product is, it has a very diverse range of use cases and people that are interested in it.

You know, if I’m a retailer or if I’m PepsiCo, I want to know how many people are going to a store because that might be a proxy for how busy it’s going to be, how many sales it’s going to pull through. Or if I’m a real estate investor, who should I rent out a particular piece of property? And because we know but don’t openly share who the people are, or we know their demographics, we can profile that footfall in ways that are definitely more rich than what I had access to in my last job. So, that’s really, really interesting, but because the use cases are so broad, it also means that [laugh] sometimes it’s a bit challenging to prioritize, like, where should we focus our attention? Should we invest more in the features that are useful if you’re the tourism authority of a country and want to know who’s visiting your country from which destinations or is it for real estate company or a retailer or someone looking to figure out where to place billboards, like, which billboards to use to target a particular demographic?

And at the same time, I’m still also doing the internal kind of data products because, like the one I just mentioned also feeds into some of the other applications that CKDelta builds. We help customers figure out where to put electric vehicle chargers, and one of the inputs into the model that goes into that is the data from my product. So, I have a [laugh] fun dynamic is having both external customers and internal stakeholders to, kind of, please and having to prioritize accordingly.

Brian: Talk to me a little bit about the difference there. Is there a—do you switch modes when you’re on the commercial side versus the internal? Do you find—maybe you haven’t ever thought about it, but I’m just curious, is there a mode switch that happens and it’s like, I got to turn on these other [laugh] dials and buttons when I go external mode?

Nick: Not hugely. Of course, when you’re talking to a customer versus a colleague, you may have to be a bit more careful. For example, you know, I’m going to be more careful with what words I throw around if there are data quality issues on a particular month. With a colleague, they’re also more aware of what the issues might be. With a customer or partner, I’m still going to be transparent because, you know, if I tell them the data is fine and then a week later, they find out that it’s not, what’s the difference to me telling them now?

So, I would say that is the main mode switch because even with an internal colleague, they don’t work on this product, they don’t understand the nuances of that data, and so I still need to do that, kind of, consultant type problem-solving of, “Okay, you say you want to use this data for this new product we’re building internally. Talk me through that. What is it you’re trying to understand?” Because, you know, I call it one product, but in practice, there’s so many different configurations and options on the menu that we offer that unless if you understand the data really well, I’m basically the one that’s advising of, you know, “I think you should go with this option. I think you should sacrifice granularity over frequency or vice versa,” those sorts of things. And that’s kind of the same between at least the internal stakeholders I have now and the external ones. Like, the extent to which you need to problem-solve together is going to differ, but you still need to do a bare minimum of it, if that makes sense.

Brian: Yeah, yeah. This external one that you were talking about, you mentioned a whole variety, I mean, electric charging stations and, like, renting property. Is this a bundle, a data as a product where you’re selling a raw bundle of data to them and then they figure out how to figure out where to put our charging stations or it’s an application that would provide that kind of insight in it directly? Like, I’m curious, how would you make—if it is an app, how did you make it work for all those different use cases? How did you design it?

Nick: So, just to be clear, the electric vehicle charging apps that I mentioned, that is a standalone product. We call it Delta Power and it’s something that CKDelta has built.

Brian: I see.

Nick: My data product is, in effect, it’s just the data feed into that.

Brian: Oh, I see. Okay.

Nick: For other customers, if they are sophisticated enough that yes, just giving them data or just giving them a dashboard, which is not completely generic, but—for example, I mentioned tourism earlier. We have a series of tourism dashboards that, you know, no matter which country’s tourism authority you are, we know that there are specific views that you’re interested in. And then for others who are also willing to pay for something more custom, you know, we’ve built further customizations into that.

Brian: Right, right.

Nick: So, to answer your question, it’s the whole spectrum. There are some customers that just want, you know, the raw CSVs and others who more want the insight, so we actually will also do the analysis and say, “Based on what we’ve found, here’s the recommendation.” Like, a very random one I did last summer was, a water company wanted to see where there’s people who might be swimming in the rivers because there were times when they would have to discharge sewage into the river water. And so, they’re like, “Where do we need to reinforce our sites so that we don’t accidentally get a bunch of swimmers sick because then they’re going to complain to the regulator and will get in trouble.” And because there’s no actual data on, like, who’s swimming in a river, the closest we were able to do for them was say, “Well, we can see who’s near the river for a prolonged period of time during, you know, a sunny day or holiday,” and that became the proxy that we then used to prioritize their sites.

But for me, that verges far too closely to consulting because it’s very bespoke. What I’m always trying to do is see, you know, how can we best balance the customer’s need to get, you know, exactly the data point or insight that they’re after to the business need wishes, I don’t want to spend two weeks of a data scientist’s time building something custom for a customer who very often this will be in the pre-sales stage; it’s more, you know, give me a teaser to help me evaluate your product to see if I’m then interested. So, there’s that constant tug of war between customization and standardization that I have the joy of adjudicating. I think it’s quite fun.

Brian: Got it. Got it. I want to jump back to this Power—CK Power. Is that what it’s called?

Nick: Delta Power.

Brian: Delta Power? Okay. So, this is, like, a SaaS application… that’s how the interface looks or something like this?

Nick: At the moment, is the Tableau dashboards.

Brian: Okay. So, do you act as a product manager for that as well as the underlying data product that feeds into it, or is there a separate person that, kind of, acts as product lead for that?

Nick: There’s a separate product manager for that. The [side 00:17:45] we have at the moment is all of these utilities-related products because we—the group also owns a lot of infrastructure businesses, that stuff falls under my colleague. And then things there to do with telecoms or—very unrelated—container ports falls under me. So, I’ve spent the last six months learning so much about cranes and trucks and container movements within a port.

Brian: The thing that I was interested in is, as a DPM, the interface between you and in this case, there’s another product manager, I don’t know if sitting ahead of you is the right way to state it, but I’m curious, how much did you need to or do you do discovery around the electric vehicle charging use cases and scenarios? Do you do that directly with this—you take the inputs from that person as requirements or the two of you go and talk to the end-users who are buying access to this Tableau dashboard and together—because I would assume the more you know about what the use cases are, the easier it is to make sure that your platform provide, like, do I need to do compiled analytics here so that you’re not doing them in Tableau, but were serving them up already because I understand the use cases better? Talk to me about that kind of relationship there. Is it a one-hop or a two-hop away from the customer?

Nick: So, in this case, I am two hops away from the customer.

Brian: Okay.

Nick: Part of the reason why the split has happened the way it is because the product, when it was first developed—the electric vehicle charger one—is right before I joined, all right? So, I don’t know to what extent that’s because that’s how it happened versus if we were to build it now, would we do it differently? That said, from my point of view, in terms of what do you need from the mobility data to power your EV charger solution or any of the other things that the team is working on the utility side, actually, what I need to know is fairly straightforward in terms of requirements. In this case, I don’t need to know the inner workings of the pain point, like, oh, I also need to understand how many other chargers there are in each location to understand if that’s the optimal place. The important signal I’m providing in this particular instance is, how many people are traveling along the motorway, how many are driving a car, and then everything else happens kind of separately.

So, in that sense, this use case I’m describing is the more commoditized version of the product where it is just about, I want data that describes this thing and I’m going to do the rest of the problem-solving myself. Whereas in other cases, I’m much more closer to the end decision that’s going to be taken using this. But ultimately, with this product, I think—and I know it from having worked with footfall data on myself back at PepsiCo, it kind of is very much one signal out of many you’re going to use to make a decision. And it often is the signal that makes a very big difference, but I don’t think it’s ever going to be the end-to-end solution for your problem unless you have a very specific problem like transport planning, and in that case, yes, it is a much more complete solution. I don’t know if that makes sense.

Brian: Yeah, no, I understand. And the dance there is always just interesting to me, I’ve talked to other, particularly, more in internal enterprise organizations where there’s a data product lead, perhaps on, like, an AI and machine learning team, and there’s a software digital product organization as well and they’re like trying to like, “I want to predict, you know, which insurance plans were the right ones to show to this customer based on information we have about them and all this other stuff. But to get those insights into the product, I have to do a dance with the digital product management team, otherwise, my work doesn’t get surfaced anywhere.” And so, I’m always kind of interested when there’s this two—you know, especially a software plus data product management involved, like, how that dance happens. Is it a Tango? Is it a [laugh]—so yeah.

Nick: I know what you mean. I think it’s, in this particular job, almost a necessity to have some degree of separation. And for me, the kind of blueprint that I’ve used, both in this job and the one before comes from a book called Team Topologies. And the kind of core idea—or the core idea I’ve taken away from it anyway—is that when you have a number of different product teams, or development teams working on interdependent features, there are better ways than others to organize those teams. And the model that makes sense for my product right now is we are the, kind of, platform team or the complicated subsystem team where we work on this one piece of the puzzle that then, in our case, is also an end product in itself, but it’s also an enabler for other teams, [not 00:22:35] to differently to how your actual cloud platform or your data platform is an enabler, and yes, it’s tricky to then track the exact values you can get credit for, you know? Who gets the credit? Is it you? Is it the data scientists building models on your data platform?

But I think the thing that makes me lucky for this particular product is that we can also point to the actual monetization that we’re doing by either selling to external customers or having partners that takes the data and build their own SaaS products with it. So, it becomes a slightly easier accounting exercise than when you’re just running the data platform for a company internally. And I know from past experience, it’s harder to then justify either how much value you’re bringing now or if you need to do some big refactoring, big investment, is it worth the big investment?

Brian: Where do you see these data products going wrong? Obviously, generating value, being able to assign some type of value to the work is important, but you talked about when our—during our, like, intake call when we first met, about how these can go wrong. In some ways, there’s two sides of the coin, right: the right and the wrong. So, tell me a little bit where do you see them going wrong? Where do teams get it off?

Nick: So one, I guess pattern I’ve observed a few times now across different companies is talking the talk, but then not quite realizing that you’re not walking the walk. And what I mean by that is, I’ve had times where, you know, I was hired, told, “You’re going to be the product manager for this data product that we have,” as if it’s, you know, already, to some extent built and maybe the challenge is scaling it or bringing it to more customers or improving it, and then kind of within a couple of weeks of starting to peek under the hood, realizing that this thing that is being branded a product is actually a bunch of projects hiding under a trench coat. You know, in the PowerPoint presentations that describes the product, it all sounds great, you know? We’ve built it, it can be scaled to multiple customers or countries or, you know, whatever your unit of distribution is, but then you realize that actually, it’s not scalable. It’s not in the same way that if I design a web application and I have ten users that can access it and if I suddenly get a hundred, I just have a little bit higher cost, but the website can ultimately serve a hundred, and a thousand, and ten thousand users. And that’s one thing I’ve seen kind of go wrong.

And then I think the underlying reason behind that was that there were at times a kind of communications gap between the technical people who were building that product and the senior leadership who sometimes were technical, but not close to the detail, other times were not technical kind of at all; they came for a more commercial background. And for me that kind of is often the affirmation of often, this is one of the things that makes me useful into these teams because I can sit between them, I can understand what both sides are saying and translate. Because, you know, sometimes it’s about coming in and bringing a new idea or having a new insight about what the customer wants or what we should be building, and other times, it’s literally just been, I’m going to listen carefully to my engineering lead and translate back what they’re articulating, but in a way that’s not fully landing on leadership’s ears, things like, “Hey, there’s this technical debt that’s preventing us from scaling and we need to spend a few weeks addressing it otherwise, it’s going to take two months per country that you want to roll out to product in,” and then you’re not actually building a product; you’re just doing ad hoc projects every time.

Brian: Is that what you were referring to when you said—it sounded like you were equating, like, you know, in the digital world, ten users and a thousand is just a cost change [laugh] with your—maybe your infrastructure bill goes up. That doesn’t work for data products, and so a common mistake is having a digital-first kind of mindset. Was that your point with that comment?

Nick: I guess it’s not that inherently it doesn’t work with data projects as much as very often, just the way it’s been designed to begin with means it’s not scalable. Like, one thing—and I don’t know if it’s just because of the data products I’ve personally worked on, but what I found is, it’s very rare that the same exact data set is what each user is going to want. Everyone is going to want something slightly different. And that difference might be really basic, like, Germany wants to see German stores and England wants to say English stores, but otherwise, all the attributes are the same versus in other cases, like with the mobility product I have now, everyone wants a slightly different cut of the data, you know? Someone wants the daily visitation, someone wants it cut by the hour of day, someone wants it, like the average day of week, someone wants additional cuts, like, what someone’s home address or what’s their gender or their age bucket?

And for me, the reason why that historically in my team was a project-by-project delivery was not because inherently you cannot standardize the way you provision that data; it’s just because it hadn’t happened yet. So, for me, it’s more about making sure that you’re bringing that more software engineering way of building things, but also, before you do that, knowing that your users' needs are going to differ. So, it’s a combination of both are we building the right thing—in other words, a product that’s flexible enough to meet the different needs of different users—but also, are we building it in the right way? Are we using software engineering best practices? So, I found myself having never been a software engineer, just going to conferences and reading around some of those topics being the one that gives that advice.

And I’m not going to be doing the implementation. If you tell me, “How do I rewrite my code to make the product modular,” I’ll be like, “I [laugh] don’t know,” but I can definitely tell you that it’s not modular now and I can articulate why that’s a problem both to the technical team and to the commercial team that’s footing the bill for all the work that we’re doing.

Brian: Maybe your current company, you could talk about past experience, too, but I always kind of talk about this idea that you can’t not design the solution. Like, someone designing it—there is an experience; someone is having it if they’re using it. There is a—in your case, you mentioned Tableau is, like, a front-end. Who is doing the design? Is it you? And is it consciously or is it kind of emerging from technical work? Like, who owns that role in making sure things are usable, useful, delightful, insightful, all those kind of adjectives?

Nick: I don’t have a universal answer. Acro—like, very often, I find myself being heavily involved in that either because there was no UX designer in the team and I was the de facto UX designer because everyone else was much better at coding, so it made sense that they do that—that was my first job—all the way to having to because—for example, in a previous job, one of the data products was a dashboard. The people building the dashboard didn’t have that kind of background, you know? They were very much given a general spec and building to it instead of diving to understand, like, who is this for? What do we need to consider? So, my intervention was more retroactive because I was parachuted in.

Brian: Mm-hm.

Nick: And then right now, I guess partly because the focus of the data products we’re developing doesn’t revolve around front-end—at least what I’ve been doing over the last few months—is that design is not about designing an interface as an experience, but a bit more abstract, like, is the right experience an API to do delivery? Is it a certain way of making sure that the files are shared to someone’s cloud bucket? Which is, you know, if I were to call that experience design to someone that doesn’t deeply understand what that entails, they’d be like, “What are you talking about? You just said, ‘I need an API,’ or you just said, ‘there’s a way to simplify the way we transfer data to our customer.’” so I guess, having gone around thinking about your question as I’ve been talking, I think the answer is me.

It’s not to say I’m the only person thinking about it, but very often, I’m the one driving it. And sometimes it’ll be my technical team that’s going to call me out, especially on, like, could we do this in a more simple way, but generally, it comes from me being one of the people that spent a lot of time speaking to the end-users and customers.

Brian: Sure, sure. And I’m curious. In past lives, have you had design invol—like, formal design involved or UX research or anything from the user experience community as a resource, or is that something you’ve kind of learned on your own and you’ve always done it yourself?

Nick: I’ve worked was a designer before, but I wasn’t a product manager back then. Every time there’s any UX work to be done outside of that project, it’s kind of been me. And it started from just a lot of learning on my own because my first job was at a startup and there were a lot of things that we had to all pick up from scratch and figure out how to do. More recently, I actually took a course on UX design with a company that I previously taught data analytics, and that was quite eye-opening because I thought I understood the basics of UX and UI design. And I think I did, but it really opened my eyes as to how much more there is once you open that can of worms.

Like, the thing I’ve not really done before was the UX side of things. Like, I’ve used tools to design user interfaces and I was subconsciously thinking about the experience, but things like information architecture and what are the choices someone’s going to make and where you take them, that was not something I had kind of formally encountered. And it kind of convinced me that we do need to hire UX people as we start building more complicated applications with more complicated experiences and sets of personas.

Brian: Were there other things that you learned about that you didn’t even know existed when you went to the class? I’m curious.

Nick: I mean, I learned about Figma, just because Figma didn’t exist when I first did UI design.

Brian: Oh okay.

Nick: Or I’d learned how to use it. I’ve known about it before. I think the one thing, it wasn’t so much a, I guess a pillar of design as much as a simple concept was that most of the time, you only need to interview five users to get to 80% of the insight that interviewing, you know, 30 different users for your product would give you. And I found that really powerful and validating because one of the problems that I was having, you know, reading through product management literature being like, “You got to, you know, analyze your user data and do A/B tests,” and it was kind of assuming that you have hundreds if not hundreds of thousands of users. I was like, “But I only have the five users that are using this internal product. That’s it. It’s all the decision-makers in the company. How can I A/B test something?”

And it’s one of those things where you kind of know it already that actually if I just speak to the five users because they’re the users, they’ll give me the insight I need, but getting that validation that actually even when you have a massive product with a huge user base, people face the same issues. If you want to test usability, chances are just doing it with a couple of people or even doing a demo yourself, and every time you do a demo, everything goes wrong, you spot those issues fairly early on. Whereas having come from a data background, what’s always in the back of my head is, “Oh, there’s going to be this golden insight, golden nugget of insight hidden somewhere in the data and I need to find it. And similarly, if I’m interviewing my users, someone’s going to have that golden insight.” But actually, a lot of the times, the problems are the same.

Brian: Mm-hm. I wanted to make one comment. I’ve heard this five-user thing before—and I could just be out of touch because I’m not, like, following that stuff all the time—I don’t think I’ve seen any science behind that, but what I do know and what I do advocate in my own training is that you can learn a lot from a few people and you’ll know it when you stop learning anything new. And a lot of times it can be in the handful 10, 15, you know, these low numbers. We’re not talking about even high teens or, you know, a hundred or more people.

You will find out quite quickly that you’re hearing the same stuff. Or if you’re hearing wildly different things than you know you’re probably way off because people aren’t even understanding remotely what you’re presenting to them and you’re getting wildly different feedback. There’s signal that comes quite quickly. I was curious, did they give you any such any, like, science behind that five number? Because I’ve heard this before, but I’m not seeing any data that suggests that’s empirically accurate.

Nick: So, there [is 00:35:34]. And actually, the other thing I kind of took away from that course is that, for most things to do with UX design, the Norman Nielsen Group is kind of the gold standard. They have so many resources and research behind it. And so, this research—I think it was Jacob Nielsen who carried it out—it was a quantitative study of all of their qualitative interviews with customers. So, I think they did two. Like, the first one, they went through 30 different studies, and then I think there was a larger one that had, like, way, way more data points. So, it did have some science behind it.

Brian: Oh, interesting.

Nick: But the key distinction there is, it’s five users or roughly five users if you’re testing a very narrow thing, right? So, if I’m testing, how do people aged 50 or older deal with the user settings page that I’ve released, that’s very different to, oh, I’m going to test a bunch of different demographics and have them look through the entire website and see what comes up. So, it has to be narrow. So, it’s more about doing a series of more narrow tests around either usability or solution discovery than, you know, if I speak to five people, suddenly, I’m going to know everything I need, I [never 00:36:50] will need about my products.

Brian: Yeah, I think again, the spirit of you’re obviously doing a lot of qualitative work, it sounds like, with customer interviews and all of that. I think, getting that going just, like, just get to the gym, you can do two push-ups. Just if you can get there and get started, you’re on the right track. And so, I love to hear that you’re doing qualitative work because I feel like sometimes in the data community, qualitative is always backseat to quantitative, and it feels like if you don’t have a lot to back it up, it’s not factual or believable. So, it’s great to hear that you’re pushing that forward.

When I started the Data Product Leadership Community, I interviewed a lot of people to pick 20 founding members, and over time, people have come into the group. And there was a theme of this, like, impostor syndrome about data product management. Some people falling into this thing, and like, oh, there’s a title—there’s, like, a discipline for what this thing is that I’m doing. And I’m curious if you had any of that, like, in your own process here of feeling like imposter syndrome, and like, there’s—I don’t know, there’s all this hype bullshit and stuff out there about data products. I feel like there’s—it feels like hyped, even though I feel like within the community that—I think you and I are part of the same circle of people that are just taught, it’s just like—it’s just product management to build better, you know, insight applications and tools and resources, using machine learning and analytics are kind of the main—you know, two of the big skills that we apply to creating stuff that matters, better decision-making and stuff. It’s not really anything hype-ful, but like, this imposter syndrome kicks in. I’m just curious if you’ve had any of that, and how do you address it?

Nick: Oh, hugely. I mean, it—I’d say it’s gotten a lot better over time, but when I first started, like I said, I was at a startup. I was the first hire. I was hired as an analyst, but very quickly ended up being that project management operations kind of person that was—you know, didn’t have a PhD in physics or maths like everyone else, but I was still doing things that were adding value. But because I didn’t have a clear job title for what I was doing, I was like, you—know, technically I have the same title as everyone else: I’m an analyst.

I was getting that existential crisis slash impostor syndrome of what am I doing here? Why am I here? So, the kind of first wave of taming that impostor syndrome was when my CEO showed up one day and just dropped three books about product management on my desk and said, “I found out what you are.” [laugh].

Brian: [laugh].

Nick: And we kind of both discovered it. I still remember that day. I started skimming through the books and I was like, “Oh, my God, yes. That is exactly what I am. It’s that Venn diagram between UX and business and tech, you know?” I’m not amazing at any of them, but I understand all three and I work with all three.

Brian: Yeah.

Nick: But then as I was learning more about product management, you know, I took a couple of courses and the imposter syndrome came back. So, I was like, “Okay, I’m not actually doing most of these things.” That’s not—you know, my job doesn’t have the hundreds of users, like, half the time it doesn’t even have a fully working product because we were building internal products for customers. And that made me feel like an imposter again. And it’s really weird how a single picture can really change your outlook on life, but I—don’t remember what year it was—maybe 2019—I saw this picture that had two Venn diagrams. And on the left, it’s like, “How I think the world is,” that had these big yellow circles that’s everyone else and then this tiny blue circle that’s you. And it’s like, “How much I know,” “How much others know. I just know this tiny little thing.”

And then the picture on the right was, “What it actually looks like,” which is, there’s a blue circle in the middle and it overlaps a little bit with everyone else. And what’s unique about it is, it’s the only circle that’s actually bridging all the other equally-sized circles around it. And that’s—I know, it’s slightly hard to describe that in words, but visually it really drove the point forward, which is, you know, I’m not a data scientist, I’m not an expert coder, I can write a bit of SQL, I can do it okay, but it’s not going to be my day job and if it is, I’m not going to be very good at it. I’m not an expert salesperson, I’m not an expert UI designer, but by virtue of being the one that can do these different things or having the domain knowledge of retailers or telecoms or whatever other industry I’m in, that’s the unique perspective I provide. And I think that’s true, just—I think that’s just inherently true for product management.

You’re never going to be as good at the thing your colleague does because their job almost certainly is to be a specialist: they’re an architect, they’re a designer they’re a developer, they’re a salesperson, whereas your job is to just understand it enough that you can then pass information across other people. And for me, that’s been the kind of single most powerful insight that’s told me, you know what? Every time I feel like an imposter, good. I need to embrace that because I need to be, you know, working with people that understand something better than me. If I’m not, then maybe something’s gone wrong there. Yeah, that’s kind of how I’ve actually embraced impostor syndrome as opposed to feeling kind of devastated about it.

Brian: Yeah. My read—even though we haven’t known each other for [laugh] very long at all—my read is you have some confidence now. It feels like you have a little more confidence with things. Is that true?

Nick: Yeah. Yeah, I think it’s because, you know, I didn’t study statistics or computer science. I did politics and then I did a master’s in management. So, when I started off, I really liked data, I really liked using spreadsheets in my day-to-day life, so it came kind of naturally to me, but I knew I wasn’t an expert at it. So, I had that—yeah, the lack of confidence came from the fact that I knew that on paper, I am missing these boxes that other people have ticked many years before me.

Whereas more recently, it’s just been that recognition that, yeah, we each bring our own strengths into the puzzle. And there’s things that I’m good at and I enjoy doing that my data scientists hate doing, and they’re very grateful when, you know, I take meetings off their plate, off their shoulder, or the way we kind of weave the story about the work that we’ve done because that’s not what they like doing and it’s not—just like, I’m not good at tuning a machine learning model and I would absolutely hate having to do it.

Brian: Yeah, yeah. I don’t know, but I’ll just throw this at you. To me writing is really important because it forces you to make your ideas concrete and you’re publishing quite a lot on data product management on LinkedIn, so I’d recommend people listening to go follow your work. But that might be—just throwing this out there, that might be part of why you feel more confident because the act of writing isn’t—I think people often think it’s like, you premeditate all this stuff and then you just put it down on paper so someone else can see it. It’s like, no, no, no, no, no, it’s a mess in your head and as you write it down, you’re literally forming—you’re making the ideas concrete, you’re getting rid of the fluff, and now you’re actually processing all this here: what do I actually think about data product management [laugh] or design or, you know, tuning machine learning models or does it even matter? Maybe that has something to do with it. I don’t know. I think it’s great, though, that you’re publishing, however, it impacts your imposter syndrome [laugh].

Nick: That’s very nice of you to say. And that is the number one reason why I started writing. It is very much that I have ideas in my head, but until I articulate them, sometimes they’re jumbled up. Or I think it makes sense in my head, then I tell it to someone or I put it in writing and I realize, oh, this is incoherent. And it goes to a forcing mechanism for, you know, sometimes I need to do some research or some thinking to figure out the missing piece of something I want to write. And if I didn’t have that pressure I’ve set to myself which is, “I’m going to write this article; I’m going to write this post,” I probably wouldn’t do that research. I would probably just be watching something on Netflix instead.

Brian: Yeah, yeah. Nick, this has been great to talk to you. This is Nick Zervoudis, he’s over at CKDelta. And I want to ask you about the London Data Product Management Meetup in just a second and how people get in touch with you, but just as a last question, just kind of looking backwards, you know, if you’re quote, “Ahead,” of someone else in kind of their career journey or their adoption of doing data-product management, is there anything in hindsight that you would redo differently or accelerate some of your learning or anything? Like, “I would have taken that class earlier. I would have skipped this thing.” And any insights, like in hindsight, you could pass on?

Nick: Is this going to sound so cocky if I say [laugh] not a huge amount—and you know, I’ve not given it too much thought because you just asked me—one thing that I think I found really useful is the very specific subset of the UX training I did, which is around how to interview people, how to ask questions that are not leading, you know how to follow through. It’s something I was probably doing to some extent beforehand, but I think I’ve gotten much better doing it now, kind of going, “I’m going to ask you something and not put an answer in your mouth because that’s what I want to hear, but instead, I’m going to ask more open-ended questions to see where you take the conversation, you know, what pain point you talk about.” That’s the one thing that I think would have helped. Otherwise, you know, there was a lot of figuring things out on my own and I think that’s just a bit inherent in the work that we do. And I also really enjoy doing that.

Brian: Excellent. Excellent. Tell us about the London Data Product Management Meetup and how people can get in touch with that, and you.

Nick: Yeah, so Caroline Zimmerman and I, we met just because we were commenting on each other’s posts on LinkedIn, and then one day started chatting. We figured out that we’re both living, like, 15 minutes away from each other and met for coffee. And then I was like, “You know what? Like, it’s so great, you know, meeting other people who are doing similar work because I don’t really know that many data product managers.” I mentioned that there used to be this online meetup that a vendor was organizing, but they did four meetups and that was it.

And Caroline jumped in on it. She’s like, let’s do it. Let’s organize one. So, she gets most of the credit—

Brian: [laugh].

Nick: —for making it happen, one hundred percent. But yeah, it’s been really nice meeting, I don’t know, I think, like, 30-ish different data product managers that, you know, some of them are people that I’ve worked with, some of them are people that Caroline’s worked with, a couple are people that just saw us post about it online and said, “Hey, I want in.” Because I think in general—and this is true for all product managers, not just those of us in data—PM is a bit of a lonely profession because even if you’re in a company with other product managers, you don’t actually work together most of the time in the way that software engineers work together and do code reviews and problem solve together. You are a bit more isolated, so having, you know, our first Data Product Management Meetup, we all described it as a therapy circle. We were literally sitting in a circle, kind of, talking through about things that are they’re challenging to us. And yeah, having that sounding board is quite cathartic and helpful.

Brian: Yeah, yeah. No, I’ve heard good things. There’s definitely—London seems to have a fair number, and Jonathan Cairns-Terry has been on this show, Peter Everill, they’re both in the DPLC—Jonathan Cooke. They’re—Jon Cooke is all—they’re all London-based and stuff, so there’s definitely, if you’re in the London area, there’s definitely a data product management cluster [laugh] there, it seems, so get in touch with Caroline and Nick about the next one. And LinkedIn, is that the best place to do that? Find you?

Nick: Yeah. A message on LinkedIn. And you know, we don’t have a formal meetup or anything. I’ll just add your email to a spreadsheet and we’ll use that to invite you.

Brian: Nice. Excellent. Cool. Nick, it’s been really great to talk with you on Experiencing Data. Thanks for coming on here, and so glad to—

Nick: Thanks so much for having me.

Brian: Meet you in person, finally. Yeah. [laugh].

Nick: Likewise.