This week I’m chatting with Caroline Zimmerman, Director of Data Products and Strategy at Profusion. Caroline shares her journey through the school of hard knocks that led to her discovery that incorporating more extensive UX research into the data product design process improves outcomes. We explore the complicated nature of discovering and building a better design process, how to engage end users so they actually make time for research, and why understanding how to navigate interdepartmental politics is necessary in the world of data and product design. Caroline reveals the pivotal moment that changed her approach to data product design, as well as her learnings from evolving data products with the users as their needs and business strategies change. Lastly, Caroline and I explore what the future of data product leadership looks like and Caroline shares why there's never been a better time to work in data.
Highlights/ Skip to:
- Intros and Caroline describes how she learned crucial lessons on building data products the hard way (00:36)
- The fundamental moment that helped Caroline to realize that she needed to find a different way to uncover user needs (03:51)
- How working with great UX researchers influenced Caroline’s approach to building data products (08:31)
- Why Caroline feels that exploring the ‘why’ is foundational to designing a data product that gets adopted (10:25)
- Caroline’s experience building a data model for a client and what she learned from that experience when the client’s business model changed (14:34)
- How Caroline addresses the challenge of end users not making time for user research (18:00)
- A high-level overview of the UX research process when Caroline’s team starts working with a new client (22:28)
- The biggest challenges that Caroline faces as a Director of Data Products, and why data products require the ability to navigate company politics and interests (29:58)
- Caroline describes the nuances of working with different stakeholder personas (35:15)
- Why data teams need to embrace a more human-led approach to designing data products and focus less on metrics and the technical aspects (38:10)
- Caroline’s closing thoughts on what she’d like to share with other data leaders and how you can connect with her (40:48)
Quotes from Today’s Episode
- “When I was first starting out, I thought that you could essentially take notes on what someone was asking for, go off and build it to their exact specs, and be successful. And it turns out that you can build something to exact specs and suffer from poor adoption and just not be solving problems because I did it as a wish fulfillment, laundry-list exercise rather than really thinking through user needs.” — Caroline Zimmerman (01:11)
- “People want a thing. They’re paying for a thing, right? And so, just really having that reflex to try to gently come back to that why and spending sufficient time exploring it before going into solution build, even when people are under a lot of deadline pressure and are paying you to deliver a thing [is the most important element of designing a data product].” – Caroline Zimmerman (11:53)
- “A data product evolves because user needs change, business models change, and business priorities change, and we need to evolve with it. It’s not like you got it right once, and then you’re good for life. At all.” – Caroline Zimmerman (17:48)
- “I continue to have lots to learn about stakeholder management and understanding the interplay between what the organization needs to be successful, but also, organizations are made up of people with personal interests, and you need to understand both.” – Caroline Zimmerman (30:18)
- “Data products are built in a political context. And just being aware of that context is important.” – Caroline Zimmerman (32:33)
- “I think that data, maybe more than any other function, is transversal. I think data brings up politics because, especially with larger organizations, there are those departmental and team silos. And the whole thing about data is it cuts through those because it touches all the different teams. It touches all the different processes. And so in order to build great data products, you have to be navigating that political context to understand how to get things done transversely in organizations where most stuff gets done vertically.” – Caroline Zimmerman (34:37)
- “Data leadership positions are data product expertise roles. And I think that often it’s been more technical people that have advanced into those roles. If you follow the LinkedIn-verse in data, it’s very much on every data leader’s mind at the moment: how do you articulate benefits to your CEO and your board and try to do that before it’s too late? So, I’d say that’s really the main thing and that there’s just never been a better time to be a data product person.” – Caroline Zimmerman (37:16)
- Profusion: https://profusion.com/
- Caroline Zimmerman LinkedIn: https://www.linkedin.com/in/caroline-zimmerman-4a531640/
- Nick Zervoudis LinkedIn: https://www.linkedin.com/in/nzervoudis/
- Email: mailto:firstname.lastname@example.org
Brian: Welcome back to Experiencing Data. This is Brian T. O’Neill. Today I have Caroline Zimmerman on the line. And, Caroline, you know, when we talked, when we had our, like, initial screening—or what do you call it, just preview chat, you said you learned… you learned things the hard way, or you did some stuff the wrong way when it came to building data products. And I think this is back at your time at a media company. Like, what happened? Like, what was your lesson learned? Tell me about that.
Caroline: I mean, the main lesson learned, and I think actually you’re the one who phrases this the best, is that requirements are friendly lies.
Brian: Oh, yeah [laugh].
Caroline: And I did not know that when I was first starting out. I thought that you could, you know, essentially take notes on what someone was asking for, go off and build it to their exact specs, and be successful. And it turns out that you can build something to exact specs and suffer from poor adoption and, you know, just not be solving problems because I did it as a wish fulfillment, laundry-list exercise rather than really thinking through user needs. And, you know, that was many years ago now, but definitely, I think there’s nothing like the school of hard knocks to help you know why you need to do it the right way.
Brian: Yeah, you know, right when you played that back to me, I immediately thought of school.
Brian: And why is it that everybody—well, so many people have gone through that, I mean, and I’m talking about designers, too, and product people and data people. You hear this a lot. And I had this reflection. In school, you do the assignment that you’re given, not—you don’t figure out what the assignment is. And I wonder if it’s 20 years of following the instructions of doing the given assignment, and then you go into work mode, and you’re like, I wait for someone to tell me what to do, and then I do it to spec. Like [laugh], that’s not a teacher that’s telling you what to doing, you know [laugh]?
Caroline: Yeah. And I think especially, you know, I have, like, kind of a people-pleasing personality, and I want to make people happy. And so, when they asking—
Caroline: —them for a thing, I think the way I ace it, because I want to get an A, is by doing exactly what they asked me for. And yeah, it took a lot of unlearning and new learning to shift that mindset.
Brian: Yeah, our managers and our clients, they’re not our teachers anymore. [laugh] You know, it’s not like they’re—there’s a reason I gave that assignment, and it’s to learn this concept or whatever. It’s, like, that’s not what’s happening.
Caroline: And the thing is, too, right, like, so I was working at a music company at the time, and music data is very, very big data. It’s seriously big data because one stream is one row. So, you can just imagine, you know, when you’re at a global music company, that’s billions of streams. And so, if you need to build some dashboards or other data products, right, like just data stuff that requires you to manipulate that data, and you’re trying to build at scale from the beginning, it’s an expensive mistake to just do the laundry list of requirements because it takes a really long time to do that, to, like, build the engineering pipelines—
Caroline: —so you can build a dashboard. And I think that was the other hard knock was, like, you know, what does it actually mean to do Agile delivery? So, what does it mean to think about user needs instead of user requirements? And then, what does Agile delivery look like on the ground?
Brian: Was that time at BMG—was that the moment? Or, like, I mean, even if, like—because I know several teams, they struggle with the low adoption piece, and, you know, I gave them what they asked for, and then they didn’t use it. But this has been going on for a long time in some organizations, and I’m like, well, okay, so if it hits you in the head three times, four times, at some point, people eventually have a revelation, and it’s like, “Oh, wait a second. Something’s off here. I need to change something.”
Brian: What was it for you that made you realize, like, it wasn’t just this client? Like, there’s a fundamental issue with approaching these data products this way. We need to do it a different way. Was there something special about this BMG engagement that made it click there, or did it happen later?
Caroline: No, it wasn’t an engagement. I was there, you know, full-time. That was a full-time role. That was before my Profusion time. And that was the moment. That was, like, a turning point in my career. That was when I shifted into product thinking, right, like, into a more of a product mindset and just really deeply understanding why it is, like, what that meant. Like, I worked side by side with the VP of product. I knew what she was doing, but I didn’t think it applied to the world of data at the time.
I was like, user personas? Why should I care about that? I’m building data things [laugh]. And, yeah, it was really an aha moment of I just need to totally shift my framework and my mindset. And I think that the other fundamental shift that happened, though, was actually once I had joined Profusion, and my first big engagement here was with a UK government client.
And I think you know this from having had guests on your podcast from, like, UK government—their DDaT function, which stands for Digital, Data, and Technology, like, with it—many UK departments have that department. Many of them are, like, amazing at product thinking and at data product work. And that was my first time working in a truly multidisciplinary delivery team, understanding how product delivery and specifically user research and UX design, contribute to creating a great data thing. And it was, yeah, just specifically the exposure to user research and meeting people whose profession it was to surface hidden user needs and ask open-ended questions and, you know, all that good stuff, that was the other aha moment. So, it was the experience of failure and then the experience of what good looked like. And so, it was, like, okay well, here’s the problem, and this is a really great example of a solution. And how can I then, like, replicate that in the rest of my work moving forward?
Brian: Yeah, yeah. I guess what I’m really curious about is, was it a really sharp, like, moment where something hit you in the head and was, like, wait, like, stop? Or this was like a gradual slide into this product mindset? Or was there something special about that BMG product that went wrong, and then you were—happened to be working next to the VP of product and it—like, the light bulb went off? Or was it sudden, or was it a gradual thing? I’m just kind of won—what was that impetus that made you flip over?
Caroline: It was sudden to realize that what I was doing wasn’t working. It was gradual to figure out what the solution meant.
Caroline: Because there’s different bits and pieces. And I think, also, you can read a lot of theory, but until you have some lived practice and, like, some body knowledge of what a product approach means, I think it just takes a while to, like, percolate into lived experience and to really know what it means to surface a user need, what it really means to try and do Agile delivery in the context of data products. And what I would say is that that aha moment of, like, this is a clear-cut, like, I understand what the problem is led to probably my most important and successful hire in my role at BMG, which was, until then, I’d most—because I was building the data team, right? I started and led the data team there, and I had mostly hired technical people or, like, kind of data [unintelligible 00:07:44] people, but it was more like, you know, people who were generally good at, like, talking to people [laugh], but essentially they were requirement-gathering people, right? And, like, the key hire there was to say, “I need to go find subject-matter experts in, like, music data analysis,” because what that bridged was the gap between the data and insight, and then what to do about it.
Caroline: And the woman who ended up coming into the team, who’s still there, just totally brilliant at bridging that gap between the insight and the action, and also pulling out the right insights, right, like, from the data that we were surfacing. So, yeah, aha moment for the problem, drip feed and, like, gradual learning for the solution.
Brian: It sounds like you had some good exposure to some design professionals or UX research professionals. Like, tell me about one of those moments. Like, what was it that impressed you about that in terms of achieving better outcomes? Like—
Caroline: Yeah, it was super simple. I mean, one of those moments was just watching the user researcher [sigh] use the Jobs-To-Be-Done framework rather than just putting, you know—before, I think I had an idea that personas were roles. Like, your job title determined what persona you were going to be, right—
Caroline: —and to watch her work in creating different buckets of people, where people in different roles could actually be the same persona because of what they were trying to accomplish with the data that they were using. You know, like, were they trying to do a piece of analysis? Were they trying to influence policy? Were they—you know, I don’t remember what the buckets were, but it was all about, you know, I’m trying to do this kind of work. And one person could be three different personas at different times because they were trying to influence policy on one project; they were trying to create some analysis on another, and blah, blah, blah, and they had a distinct user journey and user experience that we were going to need to provide in the tool according to what they were trying to accomplish, rather than just what their job title was. Well, and just watching her organize qualitative research into actionable insight, just, like, watching that process, made me realize it’s—yeah, it’s a skill and it’s a profession, not just, you know—yeah, I think in the past it was like, “Oh, yeah, use a researcher, someone who’s good at talking to people,” you know? [laugh] And just watching the frameworks, right, and, like, the way that she was able to use different frameworks according to the different stages of the project to sift through a bunch of words and put that into, like, features.
Brian: Yeah. Yeah. Just for those of you listening, you probably want a researcher that is good at listening more than talking to people [laugh].
Caroline: [laugh] Yeah. Yeah.
Brian: It’s a lot more about listening than it is about talking, at the end of the day. But then it’s also, like, they’re data people; they’re just—a lot of them are qual data. I mean, there is quant UX research as well, but a lot of them are qual data, but it’s still data.
Brian: And we had this funny revelation on the show with Klara Linder, who is the last episode—she’s one of our founding members—[laugh] there’s just this moment of how many data products are built with intuition, not with any type of data and insight to drive those decisions, which is ironic because we’re delivering insights products most of the time, and decision support tools, and things like this. And so, it is data, it’s just a different flavor of it. And it actually answers the why, which is probably the most important question to get right, I would have think, with these tools. I mean, it’s—not understanding the whys contributes, I think, to a lot of the low adoption problem that so many of these tools have. I don’t know if you would agree with that, but do you [laugh]?
Caroline: I would completely agree with that. I would. Yeah. And also, I think spending real meaningful time understanding the why. I think I still sometimes go too quickly from the, you know, why. “Okay, I get it. You know, like, let’s move into trying to build a thing.” I think also because I work in a consultancy environment, and people want a thing. They’re paying for a thing, right?
And so, you know, just really having that reflex to just trying to gently come back to that why and spending sufficient time exploring it before going into solution build, even when people are under a lot of deadline pressure and are paying you to deliver a thing. You know, it’s just making sure I spend sufficient time on the why because, yes, I completely agree with you. It’s the most important thing. It’s, like, the building block for everything else. It’s the foundation.
Brian: Yeah. Yeah. I’m curious. So, you said they’re paying for a thing. I guess I’m always trying to get beyond that thing because, while it might feel like, “Okay. There’s going to be some screens and there’s going to be—there’s going to be some nouns that come out,” but they’re not really paying for that, right? They’re paying for the benefit of the—
Brian: —thing they’re supposed to get. And sometimes, I don’t know, that output focus can take us astray sometimes [laugh]. I don’t know.
Caroline: It does.
Brian: Yeah. It could really—
Caroline: And I guess what I’m saying is, even though I know that, I still sometimes get pulled in.
Caroline: I guess I just want to say that to anyone who, like, sometimes still gets pulled in. And I—yeah, I still sometimes get pulled in by the pressure around ‘I want the thing.’ Because I think especially in, like, situations where there is hierarchy, especially if you’re a bit of a people pleaser like myself, you know, it’s, like, it’s a skill to learn how to gently push back on that and to, like, guide your stakeholder to a different way of thinking that will deliver greater benefit in the long term, but maybe in a way that is new to them, and so, there’s a handholding that needs to go along with that, that I’m still learning how to do.
Brian: Yeah. You can’t just tell people, “No, that’s not what you”—[laugh] There’s a want—
Brian: Because there’s a want factor in there, and negotiating the want versus what’s good for them, you know, that’s a whole dance that has to happen, and I totally get that.
Caroline: So, I guess what I’m saying is… I know the theory well now. I’m still learning how to put that into practice.
Brian: Yeah. Well, we all are, right? It’s not like you’re done.
Caroline: Yeah [laugh].
Brian: You’re not done with this kind of work. It is—
Brian: You’re playing the in—these are—design, product management, all this stuff, these are all infinite games. They don’t end.
Caroline: Yeah, yeah. Yeah, exactly. It is crazy, in a way, that, like, even though I teach the theory, I still need to relearn that. Or, like, I continue to need to learn how that applies in real life, and exactly what that looks like when engaging with a stakeholder or a client.
Brian: You told me about, like, a luxury retailer you guys had worked with. You built, like, a propensity model. They sold pretty expensive items. And tell me a little bit about that experience there.
Caroline: Yeah. So, that was a data thing that we built that predicted propensity for certain—like, as you said, like, really expensive products. And it worked super well in the beginning when the model was: we make a bunch of expensive objects, and then we have a bunch of inventory that we need to sell, and the salesperson can pick up the phone and say, “Hey. We just got some of this beautiful product in. Why don’t you come in and try it?”
So, the propensity model worked really well because it was very actionable, right? It was like, “Oh, we have these beautiful objects. Why don’t you come in and try one on, see how it fits, and figure out, you know, if you want to take one home with you?” And then the business model changed so that they were only manufacturing after they had gotten an order. And so, somebody could be in propensity, but there was no longer an excuse for the salesperson to ring them up. There was no inventory for them to come and try on.
And so, we needed to evolve what that data product was. It was a data product that worked very well. You know, like, it had a good user interface into the CRM to make it super actionable, and that had high adoption, but then adoption fell when the business model changed, and so we needed to look again. Like, they needed a reason to call, and how could the data product give them that reason? And then the propensity model, it didn’t really work.
And so, what we ended up doing was shifting towards an engagement model because it turns out that engagement is very predictive of a desire to purchase. Like, if you’re highly engaged with a brand, probably that indicates that you’re in high propensity anyway. And what that allowed the salesperson to see was like, “Okay, what are the different touchpoints with the brand that they’re engaging with?” And you can just see that, right? It’s not, like, an opaque algorithm; there’s just, like, rules on what makes an engaged customer or not, and what their touchpoints with the brand were, and that gives them talking points.
So, we shifted from a propensity model into an engagement model because it was a lot more explainable. It was rules based. It also had—like, we built it with the salespeople. Like, we had early adopters. Like, one of my favorite concepts that I learned from you, Brian, is ‘build with users, not for users.’ And—
Brian: Yeah. Not my thing. I don’t know who said that, but it’s not my—
Caroline: You don’t know who said that? I got it from you, though. I learned it from you [laugh].
Brian: No. I just spread—I’m spreading good ideas. And I wish I remember who said that. But, yeah.
Caroline: [laugh] But, yeah, it’s really excellent. And, by the way, I find that to be one of, like, the fundamental principles that I work with now. That’s like a north star. Like, ‘build with users, not for users.’ And it was exactly that, was just like coming up with the right test audience.
You know, or like, who are going to be our early adopters? Who are we going to build with? Who’s excited about this possibility, and how can we build it with them? And, yeah, and that has been super successful because they built it with us, and it is super transparent and actionable for them, given the changes in the business model. And I think the reason that story is useful for me to come back to is just remembering that a data product evolves because user needs change, and business models change, and business priorities change, and we need to evolve with it. It’s not like you got it right once, and then you’re good for life. At all.
Brian: Right. Have you dealt with gatekeepers? Like, in this case, so you brought salespeople in. Maybe that conversation started with the head of sales. And I know this is a struggle for some teams, which is, “Well, you can just talk to me. I want them on the phone. And I don’t really want to—I know you guys are trying to do the right thing, but, you know, I used to do that job, so I can kind of tell you what my team needs from this, so just go through me, and I’ll get you what you need. So, what do you need?” [laugh] I’m stonewalling here a little bit on purpose, but have you had to deal with that kind of thing where you really can’t—like, Profusion as, like—you know, you’re a consultancy, and you’re trying to get access to the horse’s mouth, it sounds like, to really talk to the end user. Do you ever get that? Do you have to navigate that?
Caroline: I would say not so much that. It’s more like they’ll say yes, but then no one has any time.
Caroline: So yes, the doors are open, but like, basically people are paying lip service to it, right? Like, “Yeah, yeah, yeah, we’ll give you time,” but, actually, there are so many more urgent things that the sales team—because, especially, like, the sales team is on the front line of delivering the revenue numbers—
Caroline: —and the thing is, we build a lot for—because I think that that’s—like… sales team enablement is one of the most powerful value-creation levers that a data team can work, right?
Brian: Yeah. Yeah.
Caroline: And, like, I’m actually doing some research at the moment with my old business school on how private equity firms are leveraging data to deliver value. Because PE firms are, you know—they have a five-year investment horizon; they need to make the company more valuable than what they bought it for five years ago; how are they using data to do that? And, actually, like, commercial team enablement has come up over and over again as, like, one—like, the area where data products tend to deliver the most value. But, yeah, of course, sales teams have a lot of other stuff on their plate, like chasing new leads and converting them and things like that. I find that the ways around that is enthusiasm of the end users who are participating in this tends to be a great predictor for, like, how successful the solution ends up being, I find.
Like, and—so I think it’s like, A, about finding a couple of people who are going to actually commit some time—so, I think that’s an important workaround—and then the second is just, with that team of two or three, delivering some benefit to make other people feel like, “Oh, okay. Wait, this is actually worth our time. This is going to deliver me something.” Because I think that often sales teams get solicited from data teams, like, around data quality, “Make sure that the data that you’re putting in the CRM is of higher quality,” and, you know, blah, blah, blah, but don’t necessarily receive benefit from that or see how it’s actually helping. Like, “Well, why should I spend time doing that? I don’t really see what I’m getting back for it.” So, I think it’s just about picking a couple of people that gives you enough information to just try to do something that delivers some value and to be able to show that, and then use that to get a couple more people on board.
Brian: Yeah, it’s the, “Bob and Jane now have this, like, thing on their side that I don’t have on my side,” [laugh] you know?
Caroline: Yeah. Yep.
Brian: Not that it’s always a competition, but it’s like they have an edge, and they’re pretty stoked about this thing. And this actually gets into marketing a little bit, too, which is there’s a story there and a feeling of having that edge in the case of sales, and that can be really good if you need to spread this thing through an organization. Start with a small audience. Show some tangible wins. Sometimes they won’t want to share it if you’ve gave them a real edge, and it is a competitive environment.
Caroline: [laugh] That’s not—that has not happened to me before [laugh].
Brian: Well, yeah, it could, and it’s just being aware of that that could be the case. And, in a way, that’s actually kind of a good—it’s a fun problem because it means that the thing you created actually has a lot of value there. It’s almost like the secret weapon kind of thinking. But I think it’s great to be thinking about how we spread this idea by delivering value, you know, early and to someone that can feel it, and it’s tangible. That’s a much easier way than trying to force something onto people, and then it takes them time to realize what’s good. It’s kind of like, “Eat your vegetables.” “Well, they taste bad.”
Yeah, long term, you’re going to get healthy, but, like, that’s a tough sale [laugh]. That’s a hard sell where—you know, in your case, it’s like, “Well, my leads close faster, or I’m getting—every time I get on the phone, it’s a warm conversation instead of a cold one.” Those are things that salespeople can feel and report back if that’s what your tool is doing in that case. So, yeah, that’s cool. Tell me a little bit about how—I don’t want to go super deep into process stuff, but, like, when Profusion talks to a new client, like, and you’re going to build some kind of tooling or application interface, dashboard, I don’t know what the output is, but, you know, for—
Caroline: Yep. And it’s usually, like, a predictive model or a dashboard.
Brian: Yeah. Yeah. So, let’s say, yes, it’s a predictive model, and it’s expressed in a dashboard or something. What’s that kind of high-level process? What do you ask for from them in order—but, not the plumbing and the technical and all the, you know, API endpoints, and data engineering, and plumbing, not that stuff, but in terms of making sure you actually create some value for them, what’s that process look like? Who’s involved, in terms of roles and skills on your side? What do you ask from, from their side? Like, tell me about that.
Caroline: Hmm. I’d say it’s evolving. And I think what that playbook looks like right now—so it used to be that I thought that, oh, well, let’s start with understanding your business strategy, and then how can we start thinking about where data slots in to enable that business strategy? And I think what I’ve learned with time is that a lot of organizations don’t really have a business strategy, per se; they just have goals per team, like targets per team. But that’s not necessarily coming from, like, a data-informed view of what is driving value for them.
And so, I think that often—like, the starting point that I’m taking more and more is actually ‘let’s do some basic customer journey mapping to understand where your drop-off points are.’ And this is something who I’ve spoken about a lot with and learned a lot, from Peter Everill, who you’ve had on your show and I know is part of the—one of the founding members of the Data Product Leadership Community—yeah, is just starting with that high-level customer journey mapping to understand, you know, well, do you have a problem, like, more at acquisition or at conversion or at repeat, you know? Because then that makes sure that whatever you’re doing is very customer-centric and is all about moving people through your funnel. Because that is ultimately how you drive value is either getting more customers or converting them better or a combination of both—so understanding where are key drop-off points happening, and how can data help you close the gap in those important drop-off points?
Brian: Let me pause you. Customer journey mapping; the customer being your internal client, like, a head of sales?
Caroline: No, no, no. The end customer.
Brian: The person that’s paying your clients to buy their products and services. Okay. So, a real end customer. Okay. Got it. Got it.
Caroline: A real end customer. Yep. A real end customer. And then thinking about what is the suite of data products that we could build to close the gap in the different drop-off points? And then what is the effort that would be required for each one of those initiatives, and how do we start thinking about prioritization that way?
And, of course, understand the business strategy as it exists on paper, have an understanding just of, like, the stakeholder map, and who’s trying to do what organizationally. Like, what are people [bonused against 00:25:34], you know, like, what do they care about within that organizational context? And then just, like, broadly—and, you know, customer journey mapping helps a lot with this—just understand what the revenue and cost drivers are for the business, like, understand how they make money. And then, from that understanding, build out a prioritized roadmap and then pick the one that feels like it will deliver the most value for the least effort, but that also takes the context in mind. Like, what is on business leaders’ minds at the moment? It’s not just a revenue minus cost; it’s also how are we going to position this to tell the right story? And so, a combination of, like, that quantitative assessment—because it, I mean, it will only be a guess anyway, right—and then the qualitative assessment, okay, what do we pick to start building out?
Brian: Some initial value or some kind of—yeah.
Caroline: [laugh] Yeah, yeah. And then probably go after, like, two or three, you know, just to explore because you’ll have some assumptions that you need to test. And maybe you want to go after a couple before figuring out like, yeah, this is the thing we’re really going to go after. And what I would say is, I find again, now, because we’re quite focused on, like, sales team and commercial team enablement, often the quick wins are around churn and, like, engagement modeling, and churn especially. You know, that will deliver—that tends to deliver a quick win. If you can deliver it with the right end user experience so that it’s super actionable, that can really, like, quite quickly get some momentum going and get people excited about doing more.
Brian: I understand that starting with the journey mapping and, you know, looking for opportunities within that, where are customers struggling or whatever it may be.
Brian: But what was the ask prior to that? Because I’m guessing, you know, the client doesn’t ask you, “Could you come in and do some journey mapping for us [laugh]?”
Brian: That’s probably not what the ask was, right? Maybe it was. I don’t know. Like—
Caroline: So, the ask is different. I mean, sometimes—because I guess I wear, in some ways, two hats, right? I have my data strategy hat and my data product hat, which are interrelated because I think of a data strategy as just a portfolio approach to data products, right? It’s like wrapping up the data products that you’re working on in, like, a cohesive narrative. So, often the ask is, ‘Help us figure out what our data strategy should be, what we should be building in what order, for what purpose.’
Brian: Okay, so it is a broad mandate or request.
Caroline: But I’d say that other times—and this is happening often, I would say at the moment—is people have built a set of data products, so, again, usually dashboards and predictive models that have not been adopted and/or are just like a spaghetti mess, and they need somebody to come and help them just weed the garden, so to speak. But that still would often be a same, similar sort of [sets 00:28:24] because you would just want to make sure, okay, but, like, in order to know what to weed out and how to prioritize things, you need to have that broader understanding of how the business makes money and where there are lost opportunities for making more money. And then how do your data products fit into solving those, you know, drop-off points?
Brian: Mm-hm. When you build these journey maps, are these informed by research, or are they mostly, like, self-reported back from the client about where they just feel—or, I mean, maybe they know, like, the convert—I don’t know, like—
Caroline: It’s both.
Brian: —they know why certain phases or things are happening. I’m just curious how—what went into those?
Caroline: It’s definitely both.
Caroline: So, like, you know, we usually start from—it’s usually a qualitative assessment to begin with. Like, tell us about what the journey looks like, and how do we start recreating that with data to map out where those drop-off points are, and what does the data tell us may be some additional steps that you’re not necessarily seeing about, you know, those drop-off points? And I would say there’s very varying data quality for being able to do that well [laugh]. Because, if your CRM data is junky because people aren’t inputting the data properly, it’s difficult to do that accurately, whereas, if you’re in, like, B2C environment, for example, where it’s all, like, digital transactions, then it’s probably pretty accurate. So, there’s varying levels of massaging the data and cleaning up the data manually to get it to the right place where you can have a decent map.
Brian: Mm-hm. I mean, is there, like, a single biggest challenge being a director of data products, whether it’s internally with Profusion, like your own team or with clients, but is there one thing that stands out for you that’s the biggest challenge? [clear throat].
Caroline: I don’t know if there’s one thing that stands out. I would say what I continue to have lots to learn about is just stakeholder management and understanding the interplay between what the organization needs to be successful, but also, organizations are made up of people with personal interests, and you need to understand both.
Brian: Right. Yeah.
Caroline: And you need to understand both quite quickly, at least in a consultancy environment, because you don’t get to go as deeply, and you’re not as embedded, you know? So, I’d say that that’s the ongoing place. You know, I report into our chief commercial officer, and she’s amazing at that, and so she’s, like, my teacher [laugh]. She’s just amazing. She is just amazing at reading between lines to understand, yeah, just the interplay of organizational context and people.
Brian: Can you abstract one of those out or anonymize one of those for our listeners, like, to help them see what that looks like in a meeting or something that you observed one time?
Caroline: Ahh… okay. So, there might be a very top down, like, hierarchical culture in a big corporate, for example, right—
Caroline: —and the team is super excited about the data strategy and, like, the data team, right, and the data products, and like, they’re super excited about this, but it turns out that they’re not going to get approval for their budget because the IT team is trying to stake their name in the ground to say, “No, actually, we own data, not you, because data is sitting in, I don’t know, the sales and marketing team.” And so, there’s this fight on who owns data, and they think that data should be all these technical things, and we’re thinking data should be this instead. And so, how do we approach that? You know, and, like, how do we, as external partners, help to position the data agenda? And, like, the people in that data team may be feeling quite threatened, right?
Like, how do they put—you know, there’s always a political context, you know? And I think this is maybe a bit more true in larger organizations but understanding that political context, I think, is key to figuring out how to position this stuff. Like, data products are built in a political context. And just being aware of that context, I think, is important. And I always want to—I don’t know, I’m kind of literal, you know [laugh]?
I don’t know. I don’t always—political reading between the lines or, like, positioning is not necessarily my strength. And, yeah, and I think it sounds kind of, I don’t know, dirty when it’s talked about as, like, politics, but I really just think it’s like the interplay of organizational context and, like, individuals and how that all shakes out.
Brian: Yeah, there’s interests. I mean, if it’s not politics, there’s just personal interests and all this kind of stuff. And I think the larger the company you get into, both, in my experience, and what I think I’ve heard, the larger it is, the less risk most companies want to take.
Brian: They want to protect what they have now. Most change comes with risk, whereas, if you just keep the status quo, you probably will do okay. At some point in leadership roles, when you get a ‘C’ in your title, now you have some responsibility to not—status quo may not be sufficient, but a lot of times, when you get, you know, lower down the stack, it’s just risky to change anything.
Brian: It’s much safer to leave things the way they are and to protect those interests and stuff. So, part of it’s like, well, yes, that’s true. There’s probably some opportunity, like if that person wants to adva—you know, the client wants to advance. And client here, I mean, this can be for people—data teams are mostly little consultancies anyways. Most of them are service—or they’re like service—they’re supposed to be service organizations.
Just, these are—you’re not going to go away from them after three months; they’re going to be there in three months because you guys are all employees. But, if you treat it—you know, Jared Spool calls this, like, the servant-leader mentality, you know, where it’s like you’re sort of a servant. You’re actually leading them, but it’s in a service context, not from a top-down standpoint. It can be peer or even like I’m under you, but I’m here to help you advance your cause. You know, and what are the benefits for them? And it’s a leadership model.
Caroline: It is. And I think that data, maybe more than any other function, is transversal. I think data brings up politics because, especially with larger organizations, there are those departmental and team silos. And the whole thing about data is, like, it cuts through those because it touches all the different teams. It touches all the different processes. And so, I think, yeah, in order to build great data products, you have to be navigating that political context to understand how to get things done transversely in organizations where most stuff gets done vertically.
Brian: This kind of topic of data products, I’m curious, when your clients come to you, are they coming in asking for data products or do you not even really talk about it that way? You just talk about benefits, what they’re trying—you know, reducing churn or whatever, and that’s kind of—data products is your internal language. I’m just kind of curious about that.
Caroline: Yeah, I think it definitely depends on the stakeholder. So, with a data leader, we probably would speak quite clearly about data products because most data leaders, I think at this point, have a pretty good concept of what that is and what we’re talking about. For a CMO or a CEO, we would not talk about data products [laugh].
Brian: Yeah. Yeah.
Caroline: We would talk about benefits realization and making sure that you’re solving problems for the sales team or the ops team.
Brian: Are you seeing trends in terms of what the problems are that these—your clients are having, either making data products, understanding the benefits of them, jargon? I don’t know what it is, but do you see any common threads there that you have to like, “Okay, we’re going to have to go into this during this call [laugh]. You know, run Playbook C because we have to have this discussion first.” I don’t know—just kind of open-ended question.
Caroline: I don’t know if I see any trends, per se, but I think that since the world moved into a higher interest rate environment, there’s been a lot more scrutiny around what are the benefits of investing in—because, you know, yeah, CEOs aren’t thinking about data products. They’re just seeing their investment in a data team and not understanding or not able to see what the return is on that investment. And I think that there’s more scrutiny than I’ve ever witnessed in, like, my career in data on that value question. And so, I think it’s never been a better time [laugh] for data product people because, like, that’s what we’re about. And I think that—you know, I mean, I came into the data product title only very recently. It’s been, like, three months that I’ve had data products in my title, although I feel like I’ve been doing data product work for a lot longer than that.
Brian: Yeah. Yeah.
Caroline: But I think data leadership positions are data product expertise roles. Like, that is what it is. And I think that often it’s been more technical people that have advanced into those roles. Yeah, and I think, you know, if you follow kind of the LinkedIn-verse in data, it’s very much on every data leader’s mind at the moment is just, yeah. How do you articulate benefit to your CEO and your board and try to do that before it’s too late, you know? So, I’d say that’s really the main thing and that—yeah. There’s just never been a better time to be a data product person [laugh].
Caroline: And I think that, also, there’s just, like, fatigue around making those investments in stuff that doesn’t get used. I think people are, like, desperate for—well, what are the solutions to build stuff that actually delivers benefit?
Brian: Yeah. Most of the problems now are not tech. They’re not going to be solved with code and tech. That stuff is, quote, “Easier.” It’s like—there might be a lot of labor to set it up, but it’s like—I think it’s a known problem space to solve the technical part.
The squishy part of all this, to the politics, and self-interest, and incentives, I mean, all that kind of stuff to me is the harder game that, I think, data teams need to get better at. They need to invest in that. That’s what’s going to solve the adoption problem, usually not like making the model four percent more accurate. You know, there’s times when that might have a direct change in revenue or something like that. But I don’t know. Would you agree with that?
Caroline: Oh, completely [laugh]. I think I wouldn’t be as much a fan of your work if I didn’t. And… I think less is more at the moment. I think that there was a real emphasis on just, like, building more pipelines, getting more data in. Get the data lake so we can store it all, and it’ll all just hang out there, and we’ll be—you know, it’ll [make us 00:39:12] for sure [laugh].
Brian: One lake to rule them all [laugh].
Caroline: Exactly. We’ll be data rich, but ultimately insight poor. I think that’s what’s happened is that there’s been an explosion of data volume and of accessibility to, like, KPIs and metrics and model building. And, like, yeah, it’s never been easier to gather data and, like, put it into a model, but I think, in some ways, that makes the data product work even more important because it’s about, what’s important? How do you figure out what is signal, and what is noise in your thousand dashboards?
I know so many data leaders who, like, go into new roles and inherit 2,000 dashboards. You know, like, where do you even start picking out what is important, and what isn’t from that? And, like, the ten different machine learning models, just, like, hanging out in different levels, like, of production. How do you make sense of that mess? And I think it comes back to understand either the customer journey map or the growth model. I think I use them interchangeably—you know, what’s going to make your company grow—and pick the five things. Like, what are the five things?
And I guess my rule of thumb is, you know, dashboards should just always tell you if something is good or bad. Who cares about a metric? Who cares? If you can’t tell if it’s good or bad, and you don’t know what somebody is meant to do if it’s bad—you know, if it’s good, great, but like, if it’s bad, then what are you going to do about it? Like that flow. Yeah. So, I guess, again, it’s just never been a better time. Opportunity is ripe for data product work.
Brian: Nice. Nice. This has been super fun to chat. I want to ask you, I know you have a—there’s a meetup group. You’re an American based in the UK, but there’s, like, a data product meetup group there.
But before we get into that and how to get in touch with you, is—I just wanted to give you the last word. Any closing thoughts? Is there something I didn’t ask that I should have, or a piece of advice you’d like to give to people that are in your space? You know, I think a lot of our audiences look and sound like you in terms of the work that they do.
Caroline: Yeah. I don’t know. I mean—well, I, honestly, Brian, what I would say is your work has been transformative to me—
Brian: Oh, thank you.
Caroline: —in my career. It’s been so meaningful and—
Brian: They’re going to think I paid you to come on here, like.
Caroline: [unintelligible 00:41:29] You already do.
Caroline: But I think just, yeah, finding people to learn from and finding people who have new stuff to say is precious, and you have been one of those people for me, like, both through your own work and the guests that you’ve had on, and I’ve learned so much from what you’ve done for this community. And I guess we’re, like, holding the flame in London with the data product management meetup [laugh].
Brian: Yeah. What is that? That sounds nerdy and fun.
Caroline: I know you had my co-founder Nick Zervoudis on the show, and I know he gave a shout-out to it already. But, you know, we meet up, like, once every couple months. It’s super informal. It’s actually—I mean, you know, your listeners won’t be able to see us, but I’m actually sitting in the social space in our office where we host this.
Brian: Oh, okay.
Caroline: And, you know, we’ll throw out a topic, usually, for people to discuss, but it’s also just a chance to chat. And I think what I like about it is that there’s a lot of people without ‘data product’ in their job title who come. So, you do not have to be a data product manager to be someone who wants to come and chat to people who are at the intersection of, like, data, design, and business. And we’re here to hang out.
Brian: Yeah, that’s great. How often does it meet?
Caroline: Yeah, once every couple months or so.
Caroline: It’s kind of informal. We don’t have, like, a steady cadence. But, you know, anyone feel free to reach out on LinkedIn, Caroline Zimmerman, if you want us to add you to the [Listserv 00:42:50]. And definitely follow Nick Zervoudis as well, who’s my partner in crime on this.
Brian: Excellent. Excellent. Cool. And where can people, like, get in tou—is Linked—it sounds like LinkedIn’s kind of the place to go?
Caroline: Yeah. LinkedIn is definitely the platform of choice.
Brian: Nice. Nice. And profusion.com?
Caroline: Yeah, profusion.com. I will tell people my email address. They’re very welcome to reach out if they want to, like, be directly added onto this distribution list and make sure they don’t fall through cracks. It’s email@example.com.
Brian: And for our American listeners, that means Z, right? Did I get it right?
Brian: I always tell—we have—we actually have a Geo UK channel in the DPLC that’s like our first Geo-specific channel, so I use different—I say—
Brian: —football instead of soccer when I’m in that channel. Peter—
Caroline: Yeah. Nice. Very nice.
Caroline: I love it.
Brian: So, excellent, excellent. Well, Caroline, this has been super fun to chat with you, and thanks for sharing your experiences here with us.
Caroline: Thank you for having me. You’ve been brilliant, as always.