Driving Adoption of your Data Products

All right, we're live. Hi everyone. Hey Anthony, how you doing?

Great, how are you?

Very good, very good. It's been a very productive day. I'm also ready for a tent, but before that, super excited for this, I promise. All right, I see we've— we're covering quite the time zone range, uh, from folks commenting, like London, Dubai, Cleveland. Um, so I'll just start us off by giving a bit of context around, I guess, what, what made us decide on the topic as well. And then I'll let you introduce yourself a bit more, Anthony. So first off, what is this? If you've just randomly come across this livestream without knowing where these webinars have come from, we've been running the Data and AI Product Management Community for around 2 and a half years now, which feels kind of terrifying to say. It started as 10 people sitting in a circle in London and then It, that community grew to hundreds. Then I moved to Barcelona and selfishly I was like, I still want this community to be around. Started a chapter in Barcelona. Ariel started a chapter in Montreal. Nicolas started one in Paris. So one of the things that we've been wanting to do for a while is more of these kind of, I don't know what to call it, knowledge sharing sessions. I don't wanna say like guest speakers or webinars cuz it, it it makes it feel like something that it's not. But in short, we want to get more of the expertise that's in our community or from people adjacent to it, uh, in the hands of our members, right? And get more people to, uh, to see how others are doing things. So actually, the very first session we did with Brian O'Neill, uh, that, um, is a leading voice in data product management, and I've learned so much from him, was around user experience for data products. And then Anthony and I were talking about this and how UX is super neglected in the data world, but actually in comparison to the kind of distribution step that you need to think about afterwards, it's almost like the popular kid. And we thought we'd kind of spotlight that as well. So without further ado, I want to Anthony to the forefront and say hello. Maybe the last thing I'll say is that Anthony and Harbor have been some of our biggest, if not actually biggest, if I actually look at the numbers, supporters of the Data Product Management community. So for that, I'm super thankful, but I want to make it clear, that's not why he's here today. It's not, oh, hey, you've hosted the meetup at your offices enough times that you get a speaking slot. No, it's because It's because you're a real expert in data product management and I want to learn from you. And selfishly, I'm using this as the excuse. Do you want to give everyone an introduction, Anthony?

Yeah, sure. And, you know, thank you for the intro. I mean, I think the, you know, the support for the data product and AI management community is, you know, it's partly selfish in terms of, you know, Harbor doesn't really exist without data products and you need data product managers to have good compelling data products. But I think it also just resonated really well, right? Like, we are as a company so focused on delivering value from data. And it's, I mean, you can comment, right? But if there's one thread that goes through that community, like, it seems to be about value. So, you know, we attend and we kind of feel a little bit at home around people who are sort of talking the same language as us. So yeah, I mean, as Nick said, we You know, when I look at the debate and the discussion around data products and where data products have come from, and I'll talk a bit about this through my career because it's been kind of like a golden thread that kind of kicked off, I'd say, about 12 years ago and has sort of kind of defined all of my career for the last 12 years. When I look at data product management, you know, there's been this swell around and a lot of information, a lot of knowledge, a lot of learning, a lot of experience. around the data product management itself as a discipline, which is great, it's awesome. I think that brings a lot of focus and a lot of value to the conversation. There's been an increasing amount of conversation around the technical aspects of a data product, like what is a data product, what should it do, what are its characteristics, you know, what would be like the ideal utopian vision of a data product, you know, whether or not you build that's a different matter, but a lot of conversation there. It's kind of bled into data contracts, some of that overlap with data mesh. So, you know, a lot of technical things happening. And then to your point, you know, quite a bit of conversation around UX, which is obviously very close to the heart of any product manager in any discipline, right? What is the user experience? But there's this bit in the middle, right, between data product managers work with their technical team, they've got this product that they think is really good, and someone actually using it and getting value from it. And it's not simply just that magic happens and people start using it. There is a kind of a go-to-market process that happens. There are jobs to be done, and there's, which we'll go through, right? Lots and lots of different dimensions and facets to how involved that is or isn't, right? That could be something as simple as an email with a URL link in it, and you're sending it to the only people who are gonna use your product and you're kind of done. Or it could be extremely elaborate, you know, lots of different personas, lots of different ICPs, lots of different use cases across organizations, commercial arrangements, so on and so forth. So we wanted to just kind of get together, jam on it a bit, bring some light to kind of what are those jobs to be done, and hopefully we'll get some good chat going as people dive in and ask about it. So So my background, I started building data platforms at HSBC because I'm kind of like an analyst by sort of trade. As I started building those tech platforms, the last one that I built was really a piece of large data infrastructure. And what we had inside that infrastructure was, you know, one of the world's largest financial transaction datasets. And then we had our client dataset associated with that. And then we could see who are our non-clients, right? People on the ends of transactions that we weren't banking. And the purpose of that infrastructure was super clear. It was to help the detection and management of financial crime, right? So great, awesome, very clear use case, very clear business rationale. And it took us several years to build that. And what it wasn't though, was just a piece of infrastructure, right? The data was absolutely critical in facilitating the business outcome. So whilst we didn't call it that at the time, we were definitely managing a data product or a series of data products and the derivatives from them. But what we didn't do was product management of the data. We were very much doing project management, kind of looking back. And the project itself was successful, right? So we delivered it on time to the kind of scope and quality arrangements, you know, on budget, et cetera, et cetera, like tick, tick, tick, delivered the thing we wanted it to deliver. Great. And then what we found was, as we took that to market, there were a bunch of challenges and frustrations that we hadn't anticipated in terms of the project itself, which you probably would have anticipated if you'd focused on it from a product management perspective. So we'll talk about that. But then we kind of also found that when we kind of tried to expand the value proposition of these data assets, data products, call them what you will, that we had created, that was extremely difficult, like really, really difficult. And there were some organizational issues around that, like cross-charging, finance, legal entity stuff. But there was also the challenge that the place that we had put this data product for it to be consumed was in quite technical data infrastructure. And that just simply didn't work for a broad range of users and a broad range of use cases. So we effectively had this very, very hard blocker because the channel that we had used to take that to market was effectively the same channel that we used in order to engineer the product itself. And that just didn't resonate with our target users. Well, it did with some, but not with all of them. So spun out of HSBC, ostensibly to solve that problem, founded Harbour Data, let's say, 8 and a half years ago. We came up with this concept of data products. We weren't actually calling them still that at that point in time. And then we effectively built a platform that's a layer that sits above data infrastructure and allows data product managers to very easily and like in a very scalable way configure, launch, and manage data assets as products. We then had a bunch of user journeys on the other end where data consumers could come and discover, access, and use those data products in a very streamlined way in order to effectively solve that problem of go-to-market. And since we did that, and in the intervening 8 and a half years, I think, A, data product management as a thing has really turned up and become a more meaningful thing in the mainstream as opposed to just for data businesses. And then there's been a proliferation of different channels, right? So there wasn't any meaningful public data marketplace when we started Harbor. Now there are several, right? You can literally choose, and in some cases you might use multiple ones. There's a bunch of different platforms that have sort of marketplace UIs or marketplace features, which are about enabling discovering consumption. And the whole kind of, I think, kind of just the whole game's changed in terms of how do you take a data product to market and what does that look like. And then lastly, and then I'll stop talking, I'm gonna hand it over to you in a minute, Nick. Right now, I sort of fairly recently founded a company which is a data product itself. So it's a virtual financial transaction ecosystem modeled on a national economy. rendered in synthetic datasets that are used to test, train, and benchmark financial crime models. That is a data product. So right now I'm actively taking a data product to market independently. That's the only product in that business, so it's its whole business. So I'm sort of living this at the moment as well. So experienced the problem, probably didn't do it very well. Then InHarbor tried to properly solve the problem with the solution, which it does, but then there's other channels that have popped up as well that it sits amongst. And then now I'm actually actively doing it again, but in a commercial setting.

That's awesome. And what I really love about the story is all those full circle moments you described, how like even the company you're launching now, it kind of, I mean, I'm sure it's not quite the same, but at least it kind of links back to what you were doing 10 years ago at HSBC. That's honestly, that's giving me an existential crisis. 'Cause I'm like, there's so many things from my kind of career background that was very much like, I did a good job, then I moved on. And kind of other than having lessons learned from it as a domain, I've not looked back since. Maybe I need to do some of that thinking, honestly.

Yeah, I mean, I don't know, the apple doesn't fall too far from the tree, it seems. Yeah, one thing leads to another and then sometimes back again. So Doug, go ahead.

So I just wanna say I have a bunch of questions and I wanna explore all those topics that you've kind of outlined for us. But I wanna mention for everyone to know that the whole point of us doing this live and doing it at the time that's gonna work for a lot of people's schedules is that we wanna hear from you, right? So we heard from some people about where they're dialing in from, but really if you have questions, comments, it might be just asking us to pick on a topic that's been mentioned. It might be bring something from your day-to-day that you want us to kind of discuss, that's why we're doing it live. And the only thing you should know is there's roughly a 1-minute lag between us talking and you hearing us. So if we don't reply instantly, it's either because we just want to finish a conversation or because we've literally— you've not heard us talk while we're talking, and that's why there's a slight lag. But please keep the questions and comments coming. And yeah, Anthony, back to you. I just want to touch on something you said at the start about how at HSBC you were building something but managing it as a project and not as a product. Now you and I know exactly what that means, but for everyone in the audience, tell us like high level, what are the key differences? What does it mean to manage something as a product even though you're delivering it through projects?

Yeah, so I mean, we could get right into the weeds and do like a laundry list of compare and contrast. But for me, I think it's about, like, mindset. So with a project, you're really looking to deliver a very specific output, which is make this thing, deliver that, you know, and you expect to see this output exist at the end of that project. With a product, I kind of feel like it's just a different mindset, like a There might be an output, there might be multiple outputs involved, but you're really focusing on an outcome. And that outcome is almost always some measurement of value, right? It might be revenue, it might be a cost saving, it might be, you know, some sort of ancillary benefit, whatever that happens to be for your organization. And what you're really trying to do is, you know, in the context of data product management, at least, you're trying to extract as much value as possible out of those assets, right? So what you're doing isn't about creating an output, like here's a notebook or here's a table and I've cleaned it or whatever it happens to be. It's I'm trying to deliver that outcome, um, and I'm going to try and maximize the outcome as much as I possibly can by leveraging these data assets everywhere I can that's, you know, appropriate. So for me, it's if you almost think of it as project point in time, product as long as you can go for, as long as makes sense. Um, and I think in the example I gave, right, We were managing a piece of technical data infrastructure. That's an output, right? It's delivered or it's not. It's available or it's not. It's secure or it's not. It's like pretty binary. And once it's there, it's there. But the outcome was really associated with the data, right? So, so who's using it? Does it have the data they need? Do they trust the data and are they using it? Do they know about it? Like, who knows about it? Just the people that you were tasked with servicing originally or wider people in the organization? But we still managed it as a project. So we were like, we're done. We've delivered the data. Good job. And because we weren't really thinking longer term about the outcome and all of the things that would need to happen there in order to optimize for that, we were then honestly a little bit surprised when people started coming back and saying, well, hey, I've got this other requirement, or could you tell me more about this because I'm not sure I trust it? And hey, I can't really use these tools, are there some other ones? And hey, I'm, you know, across this boundary so I can't see this thing and that's troublesome for me. Or this guy kind of created something that's really great, how can you get that to me in a way that's secure without cutting out the database and sending it via email, which is not acceptable? So, so all of these additional requirements then sprouted up Unsurprisingly now with hindsight, at the end of our project where we delivered an output, but we didn't deliver an outcome. So that would, sorry, that's an extremely long, extremely long answer to a simple question. For me, project is longer term. Product is longer term.

It's great. And the thing I love the most about what you said, and I totally agree, and that's exactly how I explain it too, is it's about the mindset, right? Because you can look at those same exact things from 2 totally different perspectives, right? users asking for more features, right? If I'm a very project and output-oriented person, I get pissed off because I'm like, my stakeholders are, you know, scope creep. They're asking for more stuff that wasn't in the scope. But when you're thinking about the outcome, you're like, this is fantastic, right? It means there's more ways we can deliver value. It means they care enough about the product that they have things to complain about.

Yeah.

And so it's not that, oh, once you start treating your project, your data initiatives as products, then suddenly those behaviors go away. It's not that, oh, we used to do waterfall, now we do agile, so our tasks are different. Like, no, the way we're building is the same. You can do, like, build a product in waterfall, you can deliver projects with Scrum, but it's more about what do I think these things mean for me? And are they good things or bad things? Should I welcome them? Should I encourage them? Is it, is it, yeah, anyway, I was about to say the same thing again. Like, is it something to be welcomed?

Yeah, exactly. And I think those inbound requirements, to your point, you know, if you are running a project, that can feel frustrating, like you said. But the key point is if you are getting those requirements in, that is super positive because it does mean that somebody's invested. Like, they care enough to actually, like, tell you that they want something different or something more. I mean, the other bit also is sort of when you're looking at those requirements, you know, if you're thinking of it in the context of a project and you're like, there's another task I need to do and get out, and there's a requirement that I need to, you know, close, fine. If you're thinking about it more in terms of outcome value, then you look at that and think, okay, well, what is, what is the outcome and the value, right? And you start having a more meaningful conversation straight off the bat. And a bunch of the times you're going to be like, I'm not going to do that task because it doesn't actually lead to value, or I'm not convinced it does, or it doesn't deliver as much as this other thing that we could be doing and the opportunity cost is too high. So yeah, I mean, I think, you know, I don't want to just bang the drum relentlessly for product management versus project management. They both have their place. But I think in data in particular, you know, if you're delivering a project and it's not within the context of a product, then I'm not quite clear what that would be, you know, apart from like a simple thing like we're migrating our data, right? Fine, it's a project, right? Do it. But it would be like, but why are we migrating our data? Like, I hope there's some kind of value prop behind that that kind of makes sense.

100%. I mean, for me, it— the only times I think it makes sense to think in projects over products is when You know that there's not gonna be any necessarily kind of continuity over time. That's like, hey, we need to do a one-off, like some investigative analysis cuz there's some problem, we need to figure it out. And then off the back of that, you might decide to graduate this project into, hey, you know what, we should be doing this analysis like constantly versus no, it's one and done. You know, we're only gonna consider merging with this one company once. We don't need a product around it.

Exactly.

Exactly. So to kind of bring it back to this question of distribution and access, I guess if someone is listening and thinking, I feel so called out from everything Anthony has said because actually our presentation layer is very much the same technical layer as how we build the data products, where do they start? What are the things you should sense check to make sure you're doing at least somewhat to get towards that best practice and optimal way of building?

Yeah, so I think, I mean, if we sort of go back to, you know, kind of product management 101, um, you know, I think there are a bundle of things that you're going to think about, you know, in an ideal— it's never linear, but in an ideal linear flow, there's a bunch of things you're going to think about in a certain order. Go-to-market and kind of the channels that you use to engage with your target market is not the first thing you should be thinking about. Like, it just isn't. And if it is, then something's probably like a little awry and like you'd want to think carefully about that. So if the channel has just already been decided by default, that's a bit tricky. Not to say it's wrong, but you'll want to sort of understand that and explore that a bit more. So at the start, you're really thinking about value. What's available? What can you productize? What are you allowed to do? Legal frameworks, that kind of stuff. Understanding the pain points of potential target customers, target users, really deeply understanding that, working through and generating your hypotheses and testing them around What could solve for that? What would good look like? What's the value? Is it worth building something? You know, does it cost too much to solve this problem? It's not worth it. Who else needs to solve the same problem? Is it one ICP? Is it multiple ICPs, et cetera, et cetera? So these are all like the standard things you should be doing and, you know, how you're gonna go to market shouldn't be part of that conversation, I don't think. Once you are at a point where you have a good understanding of how you're gonna solve a real pain, for a real market, let's just use the word market, doesn't necessarily mean an external market here, it could be an internal market. But once you've got a good understanding of how you're going to solve that pain and what that looks like and that you're going to do it, then I think at that point it's worth sort of double-clicking and going, okay, but how are we going to service them? And we kind of have a sort of a mental model, I guess, in terms of thinking through kind of the jobs to be done and what that will look like, and then starting to think about where do we start introducing constraints that are going to enable or disable different options and different opportunities. So we kind of think about, and it's interesting, it's interesting, like, think back to the barbell comment at the start, like, data product management and the product you build, that's up to you. Like, it's really up to you as a data product manager, you have control over that. You know, the UX is also up to you. You need to be very empathetic with what people need and want and biases and psychology. And, you know, that's a whole thing, right? So great. But you still have a level of control. The go-to-market bit is quite nerve-wracking because you don't have control over it. Like, this is literally when the market is just going to tell you if it does or doesn't agree. And I remember speaking to a really awesome product manager years ago, when I was just starting the journey with Harbor. And I was at this point where I was like taking Harbor to market and he said, get ready to be wrong. And it was just like a brilliant comment. So you do need to get ready to be wrong because even if you've tested it, right, there's only so much testing you're gonna do. And even if you've done like a soft go-to-market, maybe with some of the people that you've tested it with and so on and so forth, you're still gonna be exposed, right? So this is quite nerve-wracking. And I think a good way to think about this, a good way to approach it is to think about what your target user needs to do in order for you to get to the point where they've used and adopted your product, right? Like really just put your head exactly where they are, be them, understand that. So they've got to discover your product, right? At some point they have to encounter it in some fashion. They have to usually assess it. So they're gonna make an assessment like, do I is this for me? Like, does this help me? Should I, should I, like, what is it? Um, they might want or need to trial it, uh, and try it out, which is good, right? They're starting to invest in it, so that's really positive. There then might need to be some agreements, and I'm using that term quite loosely because it could be lots of things, right? So that could be anything from an internal usage policy through to an open data license through to a commercial data license. There might be pricing, there might be a finance chargeback internally, but there's some agreements that need to happen and take place. It might also just be agreeing to sign off an access request, for example. Then there needs to be access itself. Somebody actually needs to then get into the product to be interacting with the product. Then potentially, depending on the nature of the product, there's some form of integration, right? So very simple products, fine, I've got an insight, fine, I don't really need to like integrate that. But more complex, more involved products probably need, and particularly ones that are updating over time and changing, continue to add value, they probably need to integrate it in some way into some kind of business process, formally or informally. So these are all the things your customer needs to do in order to like interact and adopt your product. So what are you doing to help them on that journey is basically the question. And if you take a step back from all of those, that laundry list I've just been through, and this came out in a conversation I was having just last week with a bunch of data leaders, functionally that cuts across quite a few disciplines. So like within a software product company, you know, marketing would be focusing on discovery and assessment. Sales would be focusing a bit on assessment, but also on trials and agreements. Customer success would potentially be supporting trials, but also focusing on access and integration. So you've got like 3 separate departments or functions that would typically be doing those roles. So for a data product manager, that can be quite overwhelming. Like, do they have access to those resources? Do they have those capabilities themselves? Like, what does that look like? And I think just being honest about the jobs to be done, being honest about the skills involved in executing those jobs to be done well or well enough to be successful is pretty important so that you don't just default to a bad option that then kind of impacts your success.

And, you know, as you've been saying all of this and all the, those different, like, I don't know what you want to call them, stage gates or important bits to consider, like discovery, trial, agreement, access, and so on. What was going on through my mind is if you're selling a data product externally, it has a whole other set of challenges, but at least you have the luxury that if the first customer you try and sell it to just doesn't buy, not because the product isn't for them, but because you messed up one of those steps, right? You totally fumbled the trial. Your agreement didn't make sense, or you, I don't know. Yeah. By the time you gave them access, it took so long that they'd moved on. It sucks, but also it's fine because you can go to customer number 2 and then customer number 3 and number 4. But internally, sometimes the customers you're going after who are effectively your users, you can't burn through them just as easily. So it's also, you need to figure these things out and do them tactfully so that you don't waste all your social capital with them and then they end up not trusting you. Because then by the time you come back with a better way of letting them trial or letting them use the product, they might go, I don't trust this guy, or I hired some external consultants to do it for me.

100%. So I mean, yeah, like, yes, it's a— I think that is a challenge. And I think with a smaller kind of in that case, or fairly captive market, it's a bit of a double-edged sword, right? You can argue that the go-to-market is much easier, right? You could just, let's say it's 20 internal people, you can email them, hey, this thing's available, go use it, here's why you should use it, and done. And hope that they log in and if they don't, go and manually chase them or whatever. So it's like a relatively straightforward GTM process. But you're right, the problem is if one of them doesn't trust it and word of mouth turns negative quite quickly, you can very rapidly, sort of burn up any goodwill, and you're in a tricky place. And we had an interesting situation in HSBC where we had engineered the data to homogenize data from lots of different transactional systems, so they could be queried in a consistent, coherent way. And someone called out that a field wasn't transformed in the way that they expected that field to be transformed. And it was like throwing a match on a piece of tinder, like the whole thing just blew up immediately. And then there was a very lengthy conversation about exposing, you know, all of the ETL processes, and it was like, I don't think that's going to help, because when you see how complex they are, it's literally hundreds of decisions, and it's tricky. So yeah, like absolutely, you know, trust is key. I mean, I think the other thing that is hopefully coming through as we're having this conversation, right? Thinking about those jobs to be done, thinking about those functions. The guiding light for this, the point that when you start thinking about go-to-market is when you have a good sense of your ICP, your ideal customer profile. Like, who is this for? What are the use cases? What are the value propositions for those users in those use cases? And I think it's key to really make sure that you are managing your go-to-market motion in a way that most appeals to those ICPs. So in the context you've just given, you're like, they're internal users, fine. Like, that's going to come with a bunch of opportunities and risks. I get that. Like, so long as you're acknowledging who your ICP is and you're thinking quite deeply, where are they? What do they do? Like, how much technical skill do they or don't they have? How much empathy do they have for data engineering and ETL or not? You know, are they Are they people who trust easily or are they people who, in my case, were investigators and questioned every single thing? In which case, you know, they had a really high bar for like trusting something and they would go very, very far in terms of investigating things because it was what they did, like that's who they were. So I think really deeply understanding that and then cutting your cloth according to your ICP is a really important part of this whole process.

And I guess to call something out here, kind of translating from thinking about an ICP as an external customer, when we do that exercise to figure out our product positioning, it's partly to understand our ideal customer better. And it's partly also to decide who is our ideal customer, right? Absolutely. And then to understand them. So I guess, do you see that also being true internally that, okay, at first we wanted to build this data product for, I don't know, the manager of this team, but actually turns out it's their direct reports that should use it. And then when we understood the direct reports that, I don't know, they use tablets because they're on the move, we can't build a massive dashboard that you need a screen to look at. And once we know that context, we can build it so that it makes sense for their context, or that it, I don't know, needs to work offline because they don't always have an internet connection. Like, for me, that's an example of understanding your ICP But then there's the step before of, okay, but who should my ICP even be in the first place?

Yeah, absolutely. I mean, like, effectively what you're talking through there is the journey towards product market fit, you know, which is I know my ICP, I know the value proposition, it's repeatable or repeatable enough for me to effectively service the target addressable market that I've identified for that. And it appears that my product is successful. in sort of meeting the needs of that. And I think that isn't a destination is the key point, right? That's always gonna be a journey. So you might have a very clear ICP with a very clear use case and be very comfortable with that. And that works and you don't ever have to question it. But if you did and you scratched beneath the surface, you'd sort of find that actually there's 2 or 3 different kind of use cases going on. There's a couple of different value propositions going on and maybe you could service them a bit better. by actually focusing on them and addressing them more precisely. Maybe, maybe not. So, I kind of feel like it's a constant journey. And to your point, the go-to-market for your data product is going to give you so much feedback on whether you have product-market fit or not. And then to your earlier point, if you get your go-to-market wrong, you're going to end up with some pretty bad signals as to whether or not you've got product-market fit. Right? You might have a product that has the potential to have great product market fit, but your GTM was poorly executed and now you've no idea. So I think just being super mindful of the impact of go-to-market on your notion of ICP and on your notion of product market fit is just really important. And it's just about being deliberate, right? You don't have to do everything. You shouldn't do everything. You should focus on what your highest probability for success in getting to the outcome and the value that you're looking to deliver. But once you're successful, you shouldn't rest on your laurels. And if you're not successful, then you should be asking yourself why. It might not be the payload of the product itself, it might be something associated with it.

I love that you're calling this out because I was thinking, I'm sure there's people in the audience who are thinking, hold on, my job is busy and complex enough as it is. You're telling me I need to do all these other things too? But your point is just, look, some of your tasks are going to have higher leverage than others. Make sure you don't mess things up just because you didn't think about your go-to-market at all.

Yeah, exactly. Exactly. And I think another kind of mental model that we use and we kind of work with our customers in using, and to go back to Harvard Data a little bit, we're really lucky because we have this platform where people are taking their data products to market. Like, that's— it's effectively one of the channels that they use, and it's their own channel, right? So they brand it as their own, and it might be an internal marketplace, an external storefront. There's lots of different models that they use. But some of our customers have literally been doing digital product management for decades. So we get to see, like, really professional people doing this really, really well at scale. And it's fascinating, frankly, to watch them and to learn from them. But one of the models that we use is this concept of like, we used to call it 3 Ps, now we call it the 4 Ps. So there's kind of like the payload of your product. And from a go-to-market perspective, this is quite interesting because it potentially enables or disables different channels. And like at some point we should probably go through and like talk about some of these channels, like what are they? We keep alluding to them, but let's be specific. But beyond that, like, the payload, like, shouldn't influence where you go to market other than certain things are now not possible, right? Because you've got a visualization rather than a table, or you've got a notebook instead of a bunch of PDFs, and that's not enabled or possible within a given channel. We then talk about placement, packaging, and permissions. And placement, packaging, and permissions are all completely interlinked and intertwined. So like drawing them out and thinking about them at the same time is quite critical. Placement is obviously where you put it, like where does it become available? Is it on a website? Is it in a private data marketplace? Is it in a public data marketplace? Is it embedded in a tool or an app? Is it your tool or app or is it a third-party tool or app? You know, is it going via a partner or a reseller and they're using one of those channels but they own it and you're at arm's length? So that's kind of the placement, and the placement is really there to facilitate discovery, right? Like, how can I see it? You've also got some only placement things like ads, emails, comms, that kind of stuff, right? They're not gonna do anything more than that, but they might drive awareness. You then have the packaging, which is there for the discovery and the assessment kind of jobs to be done. And the packaging is really critical in talking to your ICP about a specific use case, about a specific value proposition, and helping them to understand what your product's for and why your product is better, different, more suited to an alternative that they might use. And then you have the permissions, and the permissions are where things really start to bite. So the permissions need to be part of the packaging, right? You need to articulate what permissions people can and can't have for, for your product. And the permissions are going to cover trials, they're going to cover the agreements, they're going to cover access, but they're also probably going to extend into actual usage. So turning on or turning off features, timeboxing access, like providing a trial environment, like whatever it happens to be. And effectively, when you look at those all together, you're like, okay, I have a payload, which means I can or I can't use certain channels. Then within a channel, if I place it there, who's going to discover it? Who's there or who could be there? Who could I bring there? What permissions can I actually evoke and effect within that channel in order to manage risk and to manage the value transfer? And then kind of what is the packaging capability there in terms of letting people know what it's about and what it's good for? And we kind of find that's a useful model And not all channels are equal, right? They don't all cost the same. They're not all as scalable as the other. They don't all have an extensive permissions kind of opportunity, so on and so forth. So you kind of need to weigh these things up. But we find that's a really useful model when thinking about channel payload, packaging, permissions, placement.

I love it. And I love how simple that is that you can, you know, whatever data product you're building at the moment, make this like 4-row table and go, do I have an— do I even have anything on it on these things? Like permissions, probably yes. You know, we— even if it's an internal dashboard, we know who's going to get access and so on. But I'm willing to bet packaging especially, uh, is going to be lots of question marks. Like, oh yeah, we have a data dictionary, but actually it's not human readable. It doesn't actually explain what's in the data or the nuances that I don't know, we're using revenue, but it means this definition of revenue, the finance one, not the sales one, whatever it might be.

Yeah. And again, just to echo that comment from earlier, you don't have to do all of these things incredibly well. You just don't. It really depends on your ICP and any kind of constraints you've got around what channels you can use. So if you are a company that has a first-party app and you want to put a, let's say, a data visualization into that app because you've decided that's the right product to build, that's going to drive a valuable outcome, so on and so forth, you know, you've sort of already kind of decided, or you've taken deliberate decision that that's what— that's the channel you're using. It's like, okay, that's fine. So we're probably inheriting the permissions framework from the app itself. Fine, that might be good, that might be limiting, don't know. Um, you can inherit papering and agreements in terms of the, the EULA that people sign on the way in, uh, so on and so forth. You can maybe do trials by enabling or disabling it behind a feature flag, certain users, you know, like there, there are things you can do there, you know. Is it going to be beautifully packaged up if it's just embedded as a, you know, a sort of a dynamic table on a screen? Probably not. So, okay, so I don't get packaging, but I kind of get all the other things I want. And it's the obvious place to distribute this product to my ICP, which is my existing kind of user base of my existing app. So I think grounding it in the ICP and then making a really deliberate, thoughtful decision that this is the right channel, that's really important. The other bit, just sort of while we talk about channels, because I think in the conversation today we've been talking about like choose a channel almost and assess the channel based on your ICP and your target market. But what we see quite a lot of is people using lots of channels. And I think this is, you know, we probably see a part of the market where organizations have lots of data products and therefore they use lots of channels for that. But you know what, we see it with commercial organizations, we see it with internal marketplaces running on Harbor. You know, it's something that I'm wrestling with as Synthetica, which is, you know, effectively a small startup with a single data product. Like, what channels do I want to use? It's not what channel, it's not like pick one, it's like which ones and what does that look like and is there a relationship Between those channels. So one of the things that we haven't spoken about is just manual, right? Just, I'm gonna block and tackle manually the whole way. Like, I'm gonna set up sales meetings, they're gonna run the pitch, I'm gonna hand over the data or the product, you know, I'm gonna enable the access manually, I'm gonna double-check what they're doing via email or whatever. Like, the whole thing just being manual. And I think in between these channels, often depending on the nature of the channel, there might be manual processes and manual workflows that you need to put in, in and amongst them as well. So, so I think you can augment the channels. I think you use multiple channels. Many of our customers use multiple channels. They will have a Harvard platform that's their channel, their brands, all their products. They'll also be in public data marketplaces. It's not their brand, their products sat there with their competitors. And they're comfortable with that because there's a business reason for it, right? Some of their ICP, some of their target audience is in that environment and they want to consume it there and they want to use it there. So like, great, well let's do that. So it doesn't have to be a choose one.

Like you say, it's about being intentional. It's not just, oh, we want good distribution 'cause we wanna get many customers, so let's use every channel. No, Exactly. Where does your ICP spend time? How can they best be targeted? I really like how you said, you know, you take these 4 Ps and you ground them into how your ICP behaves. It's not that, oh, the packaging of my product could be even better if I put it into this other website that my internal users don't have access to and they'd have to go through a whole new hurdle to get access to it, which probably means they're just never going to log in. And you'll be like, I built the perfect beautiful data product. But actually, it would have been better off as— I'm going to get hate for saying this— maybe you would have been better off automating the emailing of an Excel report every week. If your user won't even bother logging into Tableau, you should kind of not try and fix your user. You should fix your products first.

Yeah, I mean, I literally had that exact challenge with user adoption. So we had built a product, whether you want to call it a system or an analytical product or a data product, it kind of doesn't really matter, right? But yeah, just the fact that there was a login prevented some of our users from using it, which I found extraordinary. I mean, funny enough, what we see, which is interesting and it totally talks to your point, if people have a significant enough pain point and your product solves that pain point, like they will crawl through fire to get to it. Like they will do anything to get that because the pain is so significant of what they're trying to solve. that they'll just put up with it. If the value's quite thin, you'd be surprised at what they're not prepared to do, like very simple things. So again, it does come back to that same equation, value proposition for the ICP and then trying to optimize the channel. I'm not saying if you've got a great product, you should make it really difficult to get to, but it is quite surprising what people will do, you know, if they really want to solve a problem.

100%. I mean, in a previous job where we were making a dashboard product available to third-party customers, the fact that we were forced by our IT to reset their passwords every 3 months— but to make it worse, they didn't get automatic notifications. They would just show up, they try to log in, and it would say wrong password. That was super confusing. I was like, I'd be confused too. And what happens in that case is they just go, I'll email them about it later because something is wrong, right? And, and then they get mad because they don't have access to data they're paying for. And like, technically it's their fault, but actually what we're trying to convince our IT and the, the people that had set up the infrastructure that way is that it's on us to provide a smooth user experience. You can't just be like, oh, the user is an idiot because They're the ones paying for us, right? And sure, we're spending all of our time building this data product, but for them it's like a small part of their day that they just wanted to work.

Yeah.

I'm conscious that we've been, we've had a question from Brian that I've been wanting to get to, but I wanted to kind of close the strand before we talk about Synthetica. So let's— Yeah. He's asking for the fintech data product you're building, what's the number one non-technical product slash adoption slash design challenge that you're struggling with?

Yeah, it's a great question. And Brian, and probably you as well, Nate, you'll be pleased to hear we have multiple ICPs and they have slightly different use cases and slightly different needs and the challenges are different. So on the financial services side, so think banks, payment providers, you know, basically anyone that has a regulatory obligation to detect financial crime through transaction monitoring. The challenge there is they tend to be using kind of old rules-based systems and injecting synthetic data into those systems. And we're talking years' worth of synthetic data, like literally billions of transactions that are all connected into those systems. Trying to get a result is actually really hard. So just the integration of the product into their environment in order to then generate a result that we can then mark and score is super challenging. By contrast, on the other side of the house, so technology vendors who are using it to effectively train usually kind of, you know, much more advanced models that aren't rules-based, so there tends to be quite a lot of machine learning in the transaction monitoring space, you know, for them they're like, yeah, we've got TestRig like straight in, like we're good. So for them it's really about speed of feedback loop and wanting to automate that feedback loop mechanism. But that obviously isn't a problem that the financial services companies are yet encountering because just getting it in once is really, really tricky. So to answer your question, what's the number one? I don't know if there is a number one. We've got a couple of different things that we're sort of trying to manage at the same time, but I'd say probably the The one that's more important to us is how do we get our customers to actually be able to inject that data in a meaningful way? Because it's earlier in the delivery of the value proposition and solving that for those customers, they will then hit the second problem, which effectively just buys us some time. Don't know if that answers the question, but hopefully it does.

I like that. And I have this kind of discussion with engineering teams a lot where they go, they come, they, and they present a problem that it's not hit us yet. It's kind of mounting, usually to do with technical debt, right? Yep. And I'm like, I totally get you, right? If and when we'll get 10,000 users, if and when all the users will access this stuff, or after the product's been live for 3 years and we've gathered a lot of data, then these things will be problems. I definitely want to solve them, but also they're not the problems to solve right now.

Hmm.

Because right now maybe we have bigger problems like no one's using the product or there's underlying data quality issues. You know, let's solve the problem for when we hit 10,000 users when we're at 8,000 because right now we're at 800. Yeah. And what I found is as long as you kind of almost say that, that you're like, I understand what you're saying, it's kind of okay. And where I've seen a lot of people that in theory they're the data product manager, but it's more they're the commercial leader that's dealing with the engineering team, there's that lack of understanding. And so the commercial person's like, the engineers really don't get it, we need to fix these bugs first, why are they talking about scalability? And the engineers are like, this, you know, I've been burned so many times by people like that before that ignore me until, uh, the, the shit hits the fan, and then suddenly it's my fault that the pro— the system wasn't scalable and it crashed. Um, and as long as you kind of like actually act in the middle and you understand both sides, uh, it's an addressable challenge.

Yeah, absolutely. And I, I think, you know, it's sort of the the plight of the product manager anyway, right? Data or otherwise, like, you're in between a series of groups, hopefully facilitating really good positive interaction with an eye on, like, what's the outcome that we can deliver? Like, what's the maximum value that we can get out of this investment that we're making? You know, and that's your North Star. And, you know, there are going to be decisions in there that are super tricky or contentious. And like, just like, you know, you've got to be humble as well. Like, you can, you can, you can make some mistakes and that's fine. But, you know, I was thinking, I was actually thinking last night about, um, you know, one of the items that we see quite a lot is people really focusing a lot of time and energy on buying tools and doing technical busywork that feels like it's really kind of adding value, right? They're making output. They've cleaned something, they've joined something, they've improved something, whatever it happens to be. And it's almost now become sort of accepted. And I've heard a couple of people say this in the last couple of weeks of like, if the data's really old or the data's no good, no one's going to get any value. And I think that's almost become accepted now, like orthodoxy of like, if the data's no good, you can't get any value. ChatGPT, the data that that launched with was old, and it didn't stop it becoming perhaps the most talked about ubiquitous kind of data analysis tool in the last decade. And you can say, oh, it's not just data, it's not just a data product. It kind of is a data product. And people are asking questions about data, and the data is old, and they know the data's old, but it still didn't stop them engaging with it and hopefully getting value from it and that turning into a phenomenon and, you know, doing what it's done. So, you know, I think you do have to be humble about understanding that you don't know what users actually want, need, will accept, will reject. And it really comes back to this whole point around adoption and go-to-market. You know, we spoke about timing of when to do that on that beautiful linear, paradoxical world where everything works exactly as you hope, unlike the real world. The reality is the quicker you can go to market in a deliberate, thoughtful, measured way, the quicker you are going to really start to answer those questions. Because the answers aren't in some engineer's head. The answers aren't in some commercial leader's head. The answers aren't in the heads of data product managers. The answers are literally in the market waiting to be found. And going to market is a process of finding out those answers. As we said earlier, get ready to be wrong.

And you know, when you were talking about the people doing technical busywork that's effectively not creating real business outcomes, I was thinking, and I bet you these people complain that others in the business still use Excel. And I'm like, Yeah, if Excel is what it takes for them to get their job done, yes, do it. Like, I was having a discussion with someone the other day where they, like, they're planning to build something out to provide data to a stakeholder that had asked for it. And they're like, oh, and of course the stakeholder would rather just get a one-off copy of the data to play with in Excel, but we can't do that. We need to first, you know, build a good enough version 1. And I was like, but if you just give them the data in Excel, you're going to get feedback that's probably going to be similar to the feedback of that data being in a Tableau dashboard, but you're going to get it before you've built the dashboard. Because the feedback might be, this is good enough as it is, I've done what I needed to do. Or it might be, what about these other dimensions, can you add them in? So now you're not going to deal with the scope change, it'll be better requirements up front. Or they'll go, you know what, I had a hypothesis that this data would help me. Actually, it doesn't really. Let's leave it there. And it all comes from just accepting that, like you said, let's get feedback quickly, even if it's imperfect, and even if it's with a technically imperfect artifact, and we can make it look nicer and be more scalable and be prettier over time.

Yeah, absolutely. And I mean, it's It's kind of interesting because there's this really strong parallel with Synthetica. Synthetica, what it really does is it provides an objective feedback loop mechanism on the performance of your system. And you can't really get that with real data because it doesn't have good signal and there's bias in it. And it's really sensitive data, so on and so forth, a bunch of challenges. But giving people a feedback loop mechanism that they can rely on is super valuable. And the go-to-market process for data products or any product done well is that feedback loop mechanism. And you're absolutely right, like, do it as quickly as you can in a controlled and measured way. You know, expect to be wrong and expect to learn, and then make sure you can capture and apply those learnings and then just keep going through it. I think in the social, in the kind of post, the LinkedIn post for this event, I think Anna kind of made this really interesting comment where she was like, the marketing, you know, I think she was talking primarily with internal users, you know, it's kind of go through the channels and trial and error until you find what's right. And I think there's a lot to be said for that, right? You can be quite deliberate and thoughtful about that and kind of plan it so it's not a blunderbuss, right? Which isn't what she was saying, but like, you know, you can plan that. and still experience that trial and error, and that's fine. And just cycle through until you get kind of the outcome or the help, what you expect to find from that, good or otherwise. But I think that idea of I can actually kind of understand very quickly whether this is good or not, that's just super important. And I think you should just dive in. And I think some of the challenges that we face in the data world, and I include me in this, right? I think a lot of data people aren't necessarily the people who have the skills or the inclination to do some of this work, right? Like you mentioned a commercial person earlier, right? Like, I think we all probably know what you mean by a commercial person. That commercial person does commercial stuff and they're great, hopefully great at it. And like, that's what they spent the whole career doing. And it's the same with product marketing, right? It's the same with sales, you know, it's the same with like RevOps, it's the same with the kind of legal, like all of these different stakeholders that might be involved in that kind of go-to-market process that we mentioned from the product being there and someone actually getting value from it. Like leverage these people, don't feel you have to do it yourself. And particularly if there are bits of it that make you feel uncomfortable, just know it needs to be done. And then just find the right people to do it.

That's good. And for me, that's what data product management is too, right? It used to be that you were a data scientist or a data engineer, but you're doing this talking to the business part. And over time we're like, you know what, this should be a role in itself because it's quite a lot of work.

Go figure. The same as, the same as pretty much every other domain where people create products. and try and deliver value. Yeah.

Oh yeah. Alrighty, Anthony, this has been great. Thank you so much for joining us.

Before we go, real pleasure.

Where can people find you if you want them to find you? Any parting words?

Where can't they find me? I'm in every channel, my multi-channel go-to-market. So if you go to harbordata.com, you can kind of find that. If you go to synthetica.ai, because everything needs to have an AI suffix now, you can find that. Otherwise, I'm on LinkedIn, Anthony Cosgrove, MBA. You'll find me.

Awesome. Thanks so much for joining us. Thanks everyone for listening in.

Yeah, thank you.

Yeah. See you at the next meetup.

Great. Thanks, Nick. Thanks everyone.