The Data Product Mindset: Caroline Zimmerman

What is the secret to successful data product management? According to Caroline Zimmerman, Data Products & Strategy Director at Profusion, there are four foundational principles that are key to any project.

In this entertaining and wide-ranging conversation, join Harbr co-founder Anthony Cosgrove as he learns from Caroline:

• How do define and align on success criteria
• Why and how to understand your users and their true context
• The secret to delivering incremental value as you iterate

Transcript

Anthony Cosgrove: Hey everyone, I'm Anthony Cosgrove, the co-founder of Harbr. Today I'm joined by Caroline Zimmerman, who is the director of data products and strategy at Profusion. In her role, she sets the overall data strategy and data product roadmap for her clients, and then brings those to life. Before Profusion, she also built and led a data team at BMG, a global music company.

Caroline, thanks for joining us.

Caroline Zimmerman: Thanks for having me.

Anthony: I'm so looking forward to this one. Our conversation the other day was super interesting. To get us going, can you tell us a bit more about your role at Profusion? It sounds like you're really hands-on in making data products a reality.

Caroline: I think of data strategy as setting up the portfolio of data products that you're planning for and prioritizing them according to effort and expected value. I start out with the roadmap, what we're actually doing, and then working with the delivery teams — usually a mix of data engineers, data scientists, data analysts, and data viz folks. It could also include user researchers and subject matter experts, bringing that product team together to deliver one of those data products.

For example, for an automotive company who need to help their car dealers curate their to-do lists better, we might use data to help them figure out what they should focus on — how to surface high propensity clients that they should call that day. That would be an example of the kind of work I do. It's really end-to-end making sure that the data product delivers value. That's my main job — measuring that value, communicating that value, and making sure that we have the right resources to make all that happen.

Anthony: When you're devising this strategy and you see these series of different data products that deliver the value, is it usually the first product that they've built? Do they typically already have a portfolio?

Caroline: It really depends. Sometimes you're starting from nothing, and typically those will be smaller, younger companies. But if you're thinking about bigger corporates, they would always have a base they're working from already, but maybe they had built some things that didn't get adopted. That's pretty typical. Maybe they built a propensity model and a churn model — they have a series of different things that they've built and those haven't ended up being adopted by the sales team or the marketing team. So then we would go in and help them reshape that product so that it does.

Anthony: You've already spoken about propensity models, churn models, insights into customers built into workflows. It's a question that everybody's been talking about a lot recently, but what do you consider to be a data product? And conversely, what would you consider not to be a data product?

Caroline: I was telling you the other day, I don't find that question that interesting. Not as a reflection, but I know that's a debate and I just find that debate really boring because who cares? I think those definitions are fluid. To me, the stuff that I work on that I consider a data product in my daily role is just a thing that delivers some kind of user experience that uses data usually to help a decision of some kind.

There's data products where you're actually putting together a data feed and packaging that up and selling it. But in my world, it's much more internal facing data products. And typically those would be decision support products with a strong data element going on in the background to deliver a recommendation or an insight.

Anthony: We had a guest on recently who was talking about how the payload within a data product, the actual component could be anything from a database down to an individual data element in some cases. It sounds like you agree with that idea that it can just be super flexible — what it needs to be to deliver the value?

Caroline: What I've heard often is the distinction — if it's a one-off, it's probably not a product. If it's a repeatable thing for a persona, you are building to solve a specific problem over time rather than an ad hoc individual request where the CEO says, "I want a piece of analysis to figure out what this group of customers is doing." That's probably not a data product. But if that's an ongoing analysis where that's something that they want surfaced more automatically and integrated into some kind of workflow or system, then it would become a data product.

Anthony: You've obviously got a lot of experience building these products and tying them into a longer term strategy and vision. I'm interested in the lessons you've learned along the way and any advice you'd give to a younger version of yourself who's maybe just starting out.

Caroline: The most important one is don't just build what people ask you for, even if they're very senior. The principles that I always hold close to my heart are all a result of battle scars. They're not theoretical — I learned what happened when I didn't follow these principles and I'd never want to be in that position again.

Those four principles for me are:

1. Define success early on. What does success actually mean and look like for this thing? Are all the different stakeholders on the same page? For a data scientist, it might be the accuracy of your model. For the marketing team, it's probably like "build a churn model, but then make sure that you're retaining customers as a result of those insights."
2. Know your why and why now.
3. Understand end users in their context and how your solution fits into that context and how it solves a whole problem for them. Understand the systems they're already working in, their workflows, and how to integrate what you're doing into that instead of building some kind of standalone thing that they need to be trained on. For example, if you can build a visualization within an existing system like Salesforce, do that instead of going off and building it where someone's going to need another login, or maybe you can integrate the dashboard directly into a Slack channel. Just bring it into people's existing environment and make sure that it is answering a question or providing direction and enabling action.
4. Build iteratively. Make sure that you're not going off and building something that's going to take you six months only to find out six months down the road that the user needs have changed or they were asking you for the wrong thing.

I've built things to perfect requirement and those data products have been completely unused or used once or twice, even though it was exactly following the spec, because I didn't really understand how that embedded into a workflow or what problems we were trying to solve.

Anthony: On one of the principles, you mentioned something briefly but I think it's really interesting — the "why now." Could you talk a little more about that? I think timing is probably one of those things that's often overlooked.

Caroline: I think it's really helpful to work within a burning platform of some kind, where this is not a nice-to-have but a must-have. You're solving a critical pain point for somebody where if they can't overcome this, it's really going to hamper them being able to achieve their goal or get their bonus.

I did research with my old business school, INSEAD, a number of years ago into factors for success for data leaders who are often data product type people, because you're responsible for value. One of the examples was a Chief Data Officer at a big media company. At the time they were going through a big digital transformation, when newspapers were first moving online and they didn't know how they were going to make any money. There was this real sense of burning platform and he ended up being incredibly successful in his role because if they didn't innovate, they were going to die.

That company was owned by a larger conglomerate that had lots of different businesses. He went to be a VP of data for the conglomerate and it didn't go well at all, even though he was replicating the same thing, because there was no urgency around it. They were doing great, making lots of money. There wasn't that burning platform. The "why now" and the sense of urgency around "we need this now, otherwise we might go belly up" really centers people around the same goal, to feel like this is critical right now to us succeeding as a business or as a team.

Anthony: Would that be a criteria that you would look for in all of your projects, or is that just a good accelerator but not necessary?

Caroline: I think it depends where you are in your journey. If you need to bring people along on a journey, I would look for that because the burning problems are the ones that people care about and are going to invest extracurricular time in. A lot of the time, subject matter experts and business stakeholders already have full-time jobs. The data product they're participating in is often going to be some kind of extra add-on. They need to be really invested, either because success is going to have a big impact on their career, so it could be a personal impetus, or because it is a burning platform and the problem really needs to be solved because they're really stuck on a thing.

That's just going to help with engagement, and engagement is everything. That's usually where we fall down — not having enough stakeholder engagement. So just thinking about how you set things up from the beginning to choose those people who are naturally enthusiastic but also have a real business incentive, where they're going to stand to gain something from this being successful. It makes a big difference.

Anthony: Your last point is well made and I think well understood — a lot of data product development now looking quite a lot like software development. Lots of agile practices, iterative development, good teamworking, trying to deliver value early and incrementally and prove or disprove the hypothesis as you go. I often find people find this quite difficult. When we talk to people about data products, it's something that's tacked on the end of a two or three year technology or data transformation journey.

You hear a lot of "I have to get all of my data into one place" or "I have to move it all to the cloud" or "this new database we've invested in." Then "I need to structure it, organize it, cleanse it, make sure I've got good monitoring of it, test it, maybe put some data contracts in" — and this really long and often overwhelming standard track that's expected. Do you believe in that? Do you wait until that foundation's there before you have productive conversations? Or do you want to get in much earlier and avoid them having to go through that for all of their data, as opposed to just the data that counts?

Caroline: I guess that's sort of a solved question in a way — it doesn't work to go off and build things for two or three years and just sit on it. In a world of cheap money and lower interest rates, maybe that kind of thing can fly. But over the last couple of years, that doesn't fly anymore.

I've just done another study on how private equity firms are leveraging data and AI to deliver increased value. Private equity doesn't spend money unless they strongly suspect that's going to deliver positive ROI. What kind of data stuff do you invest in to get a return within a two-year timeframe if you're going to own the company for three to five years? What came out of that is you never go in and just build a single source of truth. You would only ever build the minimum viable infrastructure you need to deliver on a use case, which is a growth initiative of some kind with the data element.

For example, maybe you want to understand who your best customers are — what are their characteristics, what are their behaviors, and how can you identify them early on. Then you can make sure you push those people through the funnel, that you're spending more effort making sure those people move through and don't drop off in your customer journey, or you're going to be more willing to spend a bit more money on prospects who show those characteristics very early on because their predicted customer lifetime value is higher.

Caroline: You would build the minimum viable infrastructure you need in order to do that. The way I heard it said multiple times in this study was you don't build infrastructure horizontally, you build it vertically in service of a particular growth initiative.

For example, with pricing — you want to optimize your pricing and so you build out the data sets that you need in order to be able to do dynamic pricing or rationalizing pricing for your products if you're in a service industry. It's always a balancing act because you also need to build that vertical piece of infrastructure to scale for the next one.

I think it's also important to think of ROI as — okay, you would build this piece of infrastructure, but then that would help you deliver against three growth initiatives. The expense is going to be up front and then it's going to be much cheaper to deliver your two other growth initiatives. The balancing act is always when you've delivered the prototype that has a bunch of tech debt but works, then the exec team might not understand why you need to make further investments to make that a lot more robust. You kind of got to play it by ear a little bit to find what that balance is for that particular organization where they're at in their journey.

Anthony: I love that comment of minimum viable infrastructure, as well as the vertical infrastructure and how you started by talking about products and strategy and the strategy almost being a culmination of multiple products. That makes a lot of sense now and I can imagine you having a conversation about where are the growth opportunities, where are the burning platforms — let's start there. Let's understand then as we move into a more strategic mindset, the minimum viable infrastructure for one, two, three, four, five versus just one that's completely throw away, or bogged down in technical debt, not very replicable, actually falls over a lot and is unstable. But starting from that perspective of give me a small number of really solid value propositions and then let's do the minimum to realize value there before growing out.

Caroline: Benny Benford, who's the former Chief Data Officer at Jaguar Land Rover, has a great rule of thumb for iterative delivery. He says you want to give people, your stakeholders, a sense of surprise every two weeks around learning something they didn't already know about their business. I think that's really good — drip feed surprising insight and then use the excitement around that to get money for investment.

That whole sort of "deliver quick wins to get people on board" — quick wins are hard. I've never really met a quick win, if I'm completely honest, with data. But I do think that delivering surprising insight is a great rule of thumb for how you give people a sense that they're getting incremental value, because then it's like, "Oh wow, we learned something about customers that we didn't know." That's cool, buys you a lot of goodwill.

Anthony: Indeed, if not a win, still useful. We've actually got Benny coming on the show. He's on the next podcast.

Caroline: I'm following him and subscribing to his newsletter.

Anthony: Unfortunately, we're getting close to time, but where do you see the data product space heading? I know you've been in it for a while. Patrick, who we had on the last podcast, has been doing it for two decades. But it's certainly something that's gathered steam over the last year or two. How do you see it evolving?

Caroline: We were talking about this. The way I see it evolving is that it's the thing that doesn't evolve, in the sense that there's such an overwhelming amount of tools and tech in that data ecosystem. I think our job is always to bring it back to these really evergreen principles — what's your why, what's the definition of success, how do you get stakeholders on board to all of that, understand end users in their context, deliver iteratively. These are all those perennial good management principles, just good leadership.

It's bringing back those principles because it's so easy to get distracted with all these shiny new tools that evolve super quickly. Especially with Gen AI and all the hype around that, I think our job is to actually take a step back from all that hype and bring it back to those first principles. Those tools are such an easy distraction. We just need to keep emphasizing and coming back to these questions of value. What's your why? Who are you building this for and how is this solution going to deliver value to them? Our job is to prevent everyone from having ADD around tools and just coming back to what we're trying to do and why we're trying to do it.

Anthony: Perfect. So just stay true to product management, essentially, regardless of the technologies, regardless of the variance in the opportunities that present themselves.

Caroline: Yeah, something like that.

Anthony: That's a perfect point to end it on. Caroline, thank you so much for joining us. It's been super interesting to listen to you and hear about what you're doing in Profusion. If anyone would like to learn more about that, head to profusion.com. And if you're interested in setting up a commercial or enterprise data marketplace or moving things forward with data products, check out harbrdata.com. Thanks for listening.