Bridging Data and Product Management Practises and Patterns with Juha Korpela - Episode #52

Welcome to the Agile Data Podcast, where we talk about the merging of agile and data ways of working in a simply magical way. Welcome to the Agile Data Podcast. I'm Shane Gibson.

Hej, and I'm Juha Koroppela.

Welcome to the show. Today we've got another exciting one. We're going to talk about product management patterns and whether we should or can or could apply them to the data domain. But before we rip into that, why don't you give a bit of a background around about yourself to the audience and tell them who you are and where you've come from.

Sure thing, Shane. That's the name with the J, not a Y, even though that might make more sense in terms of pronunciation. Helsinki, Finland is where I'm calling in from right now. I've been doing data for 13 years or so now. Recently I was CPO for Ellie Technologies. So we were doing the Ellie.ai data modeling tool. I was there for 3 and a half years, something like that. Working on kind of data modeling, figuring out tooling for data modelers and how to utilize data models in different organizations. Now I've been an independent consultant for 2 months and a bit. Quite new at this, but it's been fun. It's been super fun. Before that, I was working with UPM, one of those big pulp and paper companies. I was, I was working there as kind of head of data platform and figuring out data governance and so on and so forth. Been a consultant and been in the public sector and all sorts of stuff, but always focusing on the content of the data rather than always the kind of technological aspects that much. I've been doing coding as well, but it's been a few years already.

Excellent. So for me, I suppose I've been doing data for 30 years, but I'm fairly new to the land of product management. So when I had my consulting company, we had a few hacks at products, typical services company trying to build a product with the people on the bench. Didn't go well. Would say that I didn't bring any patterns or principles or practices to that. It was very ad hoc. Now as part of the startup, I'm focusing a lot more on product management for development of the app and the platform. So for me, still fairly new to the practice. Really intrigued to talk about product management from a software application development point of view, and then how we could apply that to the data space. And should we? Is it actually useful? That kind of thing. So why don't we just start talking through what do product managers do? Generally, one of the things I think I see product managers doing a lot of is strategy work. They understand the organization's strategy, they figure out how product should fit into that, and then they figure out how to enable the product strategy to deliver the organizational strategy. Do you see that when you were running product management side of things?

I'd say that was quite an important part of what I did, for example, at Alli, and to a lesser degree, but still also when I was, for example, working with a public sector organization, we were doing kind of internal data product and so on and so forth. But I think especially at early, the kind of whole strategic aspect of how do we get where we want to get, what is the vision of the whole thing? How do we get there? That was a very large part of it, dealing with stakeholders, all sorts of partners and contacts and influencers and whatnot, trying to figure out what's hot and what we should be doing. That's, I think, a major part of it. Of course, that being said, if you have a large organization, which we didn't have, If you have a large organization, you have different levels of product management. So, you have the strategic kind of, where do we go? And then you have these sort of tactical level, okay, what do we do next and how do we do that? So, I've always been doing both, but I think what really matters is that the strategic kind of product management is in place.

And so, if we flip that to data, so, you know, one of the differences about being product manager for a product company is, part of the strategy is actually the product. Your strategy is to build a product to go and hit part of the market that has a gap. So it's the core crux of the company, whereas in data, we tend to support the strategy if there is one. So we get the business strategy and then we say, how does data support that? And then potentially we do a data strategy, but we'll talk about that in a minute because I think that's a completely different thing than what we mean from a product strategy. But do you think that makes a difference? Do you think it makes a difference that as a product manager for software development, if you're a software company, is core to what the organization does. Yet when we're in data, we're supporting, we're secondary or ancillary to the organization strategy.

In a way, yes, I get what you mean. Then again, if I were to play devil's advocate, I'd say that even in a product company, what I'm doing in product management is supporting the sales activities. That's bringing in the money, right? But of course, in a product company, that is the only thing that you are doing, the only thing that the the company exists for is to build the product and sell it. Whereas when you build data products, there's, you're selling pulp and paper or whatever, and that is not directly related to the data products that you create. But I think the gap between kind of business strategy and data strategy shouldn't be as wide as we usually see it. I think what we should be doing is to be much closer to the actual business objectives and thus kind of aim the data products to that. I think there's an unnecessary gap, I'd say even.

I suppose if the organization's looking to monetize its data, if it's looking to package, aggregate, anonymize, sell it out in the marketplace, make some money out of it, then you are probably closer to the organizational strategy. But if you're not, you are sitting behind this barrier. What do you think people can do? Obviously the first thing I do if I'm consulting with a customer is I go, show me your business strategy and then I'll figure out how data can support it. Sometimes it exists. Sometimes it's in people's heads. But apart from that, have you got any other tips and tricks to say, if you walked in as a new product manager for an organization and you are new to that domain, that product domain, how would you understand the organization strategy and how you can support it as a product manager outside of the data domain?

I think there's two things that I like to do. One is always ask why and ask it enough. For example, now with a couple of clients I'm working with, we've been looking at some data products, what kind of existing solutions that we want to register as data products and organize the organization around them. What we do is find datasets that are being used around the organization, find people who are working with them, and then we go and ask, why does this exist? Who is using this? What do they get out of it? And if you ask why enough, eventually you get to the point that, okay, there's someone there who needs to make decisions on how much input goes into the machine or whatever. And that decision is made based on the information that they get from this pricing estimation model or something that runs on this data product here. So that's ask, you can find the link between the data product that you have and the actual business decision that results in, or hopefully results in, actual value. So, I think that's key thing, ask why. Other thing is that I feel that all of us data people, we need to understand how the business makes money. So, basically, you have to look at diagram of factory or something, say, okay, inputs are here and they are brought in via ship, and then they go into this machine and it does this and that, and this stuff comes out, and then we sell it on the markets, like, So everyone should actually understand that. And I'd say data product managers, if that were to become an actual kind of profession, which I hope it is becoming, data product managers in particular have to understand that because you can't just say, okay, I have a bunch of data here. Now, please create something out of it. You have to understand what is going on so that you can manage your data product so that it supports it. But I think actually, goes a little bit deeper even. I'd say, take any data engineer, data analyst, anything, you need to know how the company makes money. And that has to be something that you have on the back of your head so that you make good decisions about your data products that you're developing and managing.

I use a little framework where I look at the organization and I say, which of these 3 things are you doing? Are you using data to support your customers? So, are you taking the customer's data, that you get from them, and are you giving it back to them in some way? You may be monetizing, you may not be, but the people generating the data as part of dealing with you, you're giving it back to them to help them run their businesses or, or get their outcome quicker. The second one is, are you using data internally to optimize your business, which most organizations are doing with data? And the third one is, are you aggregating, anonymizing, and selling that data to third-party organizations that aren't your customer. And so what I do is I look at those, I listen to what people tell me they think they're doing, and then I go, okay, where in the business strategy do I align to? So if you are a company that sells subscription services for software, then yes, I can normally see line of sight for you giving the customer's data back to the customer to help them make better decisions. Pretty much every organization's using data internally or should be to make their organization better. But it's that external selling of it that I always see people have a wish for, but it's not part of their strategy.

It's way more rare to actually monetize data like that. I can't say I have seen that, very few times that I've seen that actually happen.

If we then jump onto the idea of a data strategy, because often the data strategies I see are right data, right person, right time, or they're blueprints or they're architectures or they're a technology diagram, they're not true strategies. What are you seeing? Are you seeing data people create strategies that look like a product strategy?

In a way, the way it should go is, as you've alluded to this already, there's business strategy somewhere, hopefully, that how does this organization succeed? And then basically, you should be deriving the data strategy from that, saying what data strategy should be is, given that this is our business strategy, We've identified that we can support it by creating such and such data products, for example. I've also seen the data strategies that are full of architectural diagrams and saying, okay, we will utilize LLMs or we'll go into cloud. I think that that's not the strategy. You're listing technologies into it. We want to play around with these tools. But what it should be is saying, we have identified ways that data can help with the actual business strategy. Here's what we're going to be doing. To help that business strategy with clearly identified value creation points, so to speak, saying that this and this is what we're going to be doing, and this is affecting the business. And then you go and create data products to that effect. I think that's the only way to actually strategically do that instead of just technology-focused platform building.

I think we can actually take a lot of the product management behaviors. So, we can talk about things such as total addressable market, So we're not talking about outside the organization, but we can look internally and say, what is our total addressable market in our organization? We can do segmentations of our businesses, our organizations to treat them as separate companies. Finance, HR, which one of those are going to be the most open to us helping them? We can do persona mapping and say, we've got these different personas in the organization. Which persona are we going in to support first? That's what we do when we do strategies for our products. We should be doing that when we do strategies for our data.

Absolutely. What we did, for example, at Ellie, when I was working there, we were trying to look at our customers and prospective customers and figure out what problems they have that we could solve. That's exactly what you should be doing when you are managing data products. And I would maybe even call them what decisions should we support? What sort of decisions are made in the business process that affect the way the organization creates value? And how can we give that decision maker data that supports them in order to make better decisions? That's also the why question. So why do you need this data? Why do you want this data? Why does this data product exist? What decision does it support? And I'm not talking necessarily about massive C-level decisions about mergers and acquisitions. I'm talking about everyday decisions. How tight should I screw this bolt on if you're doing maintenance on some machinery somewhere? That's a decision that someone makes. And we can actually give them data, not every time, but usually we can. And that is what we need to understand. That's the kind of demand for the data products.

But that flips the model because what we're used to as data people is being ticket takers. We have a window and you rock up and ask for some data and we'll ask you 5 whys and then we'll give it to you. We don't approach it with that product management mindset of, let's go find the opportunities in the organization. Let's see where things are broken. Let's find something that we can fix. Let's add some value. We sit there you're waiting for somebody to ask something rather than going out and being a business analyst of the old school ones where you actually said, let's look at the user journey, let's look at that value stream and let's figure out where we can make it better using data. So I think when we move from a product owner, which in my head is delivery, and we'll talk about that later, to product management, we change the model. We flip it from waiting to be asked to going out and finding somebody to sell it to effectively.

Totally. If you think of software product development, you have the thinking occasionally that, okay, we'll just build whatever the customer asks, whatever that is, we'll build that feature. You get these feature factories that take in requests and you just keep building, and you're never figuring out why that thing is needed, or is it more generally applicable than just for an individual customer case somewhere? And I think the same is with data. We just build datasets, we build dashboards that are just glorified Excel lists of transactions that you can filter. That's exactly the sort of kind of feature factory thinking that we're seeing in many software development projects as well. We should be asking why and figuring out how can we support a particular problem or decision somewhere that is not just pushing data to them, it is actually understanding the problem that we need to be figuring out.

So, let's say we've gone in, we've used the product management patterns, we've understood the addressable market in our organization, the different business units, and treated them as customers. We figured out the personas we can help with, we found some opportunities and some jobs to be done that we can fix. And then what we typically want to do is create some form of roadmap, some form of high-level proposition that maybe would focus on this first and then we'll do that, we'll probably do that in this order, we'll probably have some time horizons. This one in the next 3 months, this is in the next 6 or 12, this is a 2 to 3, this is a 3 to 5-year time horizon. Is that what you did from a product point of view?

Yeah, absolutely. And I would even say that the existence of such a roadmap, I don't care about the format of it and how detailed this, but existence of such format is one of the key aspects or signs that you are actually doing product management. Because if you don't have that, imagine now that you have a data product somewhere, a set of data somewhere, or set of reporting application. And the way that is organized is that you get tickets to change it occasionally, and then you change whatever is asked. You're again in that sort of reactive feature factory mode. If you have an actual roadmap, someone's has been thinking about what this product should look like in 1 year from now, 2 years from now. That is a sign that you're actually doing product management. And I'd say you are not doing product management at all if you don't have some kind of a roadmap somewhere.

So for you, is the roadmap just features or has it got some other lens on it?

Of course, they easily become lists of features that we want to do these features, this schedule or whatever. But what it should be is basically a pathway towards the vision that you have a vision of what this thing should be in whatever time. And then you have steps that need to be taken. Ideally, this would also be along the way solving problems. So it should be probably about more what problems do we want to solve first? And then you list those in some sort of semi-chronological order. And that is a roadmap. It's not about necessarily about individual features. Although that being said, do think that even if you do that kind of feature roadmap, it's still better than nothing. At least you have some sort of an idea where you want to go.

What I would typically do is I would create a roadmap that's broken down into two parts. So I would have part of the roadmap, which is around data, and I'll come back to that in a minute, and part of the roadmap, which is around platform, because I want to differentiate when we need to create some more capability versus deliver more valuable information and data. So we may have a roadmap item, which is increase access of self-service to our analysts, starting to democratize, starting to decentralize that work. It's very different than focusing around a theme of lifetime value, but they're both important and we have to make trade-off decisions. What I typically do is have a series of themes around the platform capability, and I'd have a series of themes around the data. And for those data themes, I typically bring them back to domains or business processes, big building blocks, because I want to I want to be able to group them. I want to be able to say, our organization's based on manufacturing and finance, these two domains. How do I put the data work to be done in each of those to segment it out and, and get rid of the noise as much as I can? Or I might do it on core business process, or I might do it on, like I said, lifetime value versus some other big rock of data that we need. So how do you do it? Or if you think about it as taking that roadmap from product management and bring it into the data domain, because we have that unusual balance of actually building the system as well as using the system ourselves. What would you segment the roadmap into? What would the core things you would normally pick?

I think your approach is very close to what I'm thinking as well. We were reading this Team Topologies a year or two ago at Eli and reconfiguring our development processes. The Team Topologies idea is that you organize your team so that you have stream-aligned development and you have development or platform development supporting development initiatives. And every time you have a, backlog or roadmap in normal product development in software, you will have pieces of both. You will have these stream-aligned pieces that are meant to be offering something extra to the users. And then you have this background tasks of increasing capacity or clearing technical debt or working on the platforms. And everyone knows in sort of normal product development that you have to balance between these two. So you have a stream for user-facing things and you have a stream for platform things. And it's exactly the same with data. I think one of the massive problems that we've had in data forever in terms of value creation is that we haven't identified these two workstreams. We are very eager to focus on platform work. We're saying, okay, we'll build all of these new capabilities, cloud services, whatever, that can be used at some point to enable something, but we're not actually delivering things that matter to the end user. And there should be a balance. I think overall, as a profession, we data people are a little bit off balance there. We should be really focusing on putting more emphasis on the user-facing things that actually solve problems. And data product roadmaps and backlogs, they should reflect that. And you should be able to clearly identify that here I am doing something that is not right now delivering value, but is enabling something in the future. But at the same time, I have to be doing something that is short-term also valuable.

I agree. And if I was working in a bigger organization, so if I have 10, 20 people and we're starting to have a scaling problem, I will typically then start talking about a platform product manager and a data product manager. And then the platform team and the platform product manager become an enabling team, and their customers are the other teams. What we do in the data world is we tend to build for ourselves. We know how to build it. We don't actually engage and talk to anybody else about what they want. We build what we think we know. And so I'd even change the way I capture requirements for platform is actually different than for data, just to make it look different. I can look at the templates and I can go, oh, that's a platform feature. Oh no, that's a data feature. Because I want that differentiation. I'm a great fan of Team Topologies. You read, there's also a great piece of work called unfixed.work where Jorgen's taken Team Topologies and built onto it with some more descriptions. So if you're in a large organization, it starts bringing the idea of facilitation teams, governance teams, some other things that when you're in a big organization, you have to suck it up for some reasons. He's built on top of it, a bit more complex, but still easy to understand. So definitely go read those. We've got our strategy. We found our internal customers, understood what's important, lined it up with the business strategy and their OKRs. We've got a roadmap where we are clearly saying, here's some buckets of things. Here's a time horizon of what we think we want to do. Next thing happens is we have to go get funding. We may have a team, but we always need vendors, we always need technology, we always need more people. So, again, I would expect a product manager in a software company to be pushing for funding to get their things that they need built. Does the product manager go and influence the money to pay for getting this work done?

I think, of course, it depends on the organization and the internal power dynamics between roles and people there, like it always does. But in a way, the job of a product manager is always to say that, okay, with these resources, I can do approximately this. That's your job. Now, that means that saying that I can deliver something like this with those kinds of resources is a strong message to the purse holders that if you give me more, I can do more. If you give me less, I can do less. And you constantly have to be able to explain what changes if the budget changes. And in a way, I think that responsibility over how much money is spent on product development is not necessarily always what product managers should be worrying about. What product managers should be worrying about is making it very clear what you can do with the budget that you have been given. And then you can use that as an argument that, hey, we're going to be needing more money for whatever, if we want to achieve this in that timeline. That's the kind of conversion between money and timeline and roadmap. That's what you need to be very good at.

If I look at a product manager in a software company, they're very good at saying, yeah, we could carry on building that feature set or that area in our product for 6 months, 12 months, 18 months. But to deliver the value to the market and get that value back, it's 6 months. And then we need to move on to the next thing. In the data world, we're Jira ticket takers, we're wagged by the rest of the organization. So, we will sit there and spend 12 months on a piece of data work, not knowing whether it's 12 months' value or 6 months' value or 18 months' value. We just do it till it's done. I think a data product manager has to take that funding conversation, maybe not as in, give me $1 million to hire a bigger team, but often you do have to do that. But they have to have that conversation of, this is the end of the funding for that piece of value, this is the end of the time the team will spend on it, and we're now going to move on to the next most valuable thing to the organization. And it's the product manager who makes that call. They're not an order taker, they're in charge of the value that's being delivered to the organization. So for me, that's the difference, especially between a product owner and a product manager. Because product owners, if I use a Scrum definition, they're part of the delivery team and they take the work and make it executed to a degree. Product managers, in my head, front-facing around that value and more accountability for delivering that value rather than taking the order.

I've never considered the difference between those roles very important for myself. I've been always in a situation where either the product organization is very flat, so it's me and someone else, or it's small enough that you don't really have that distinction. So, you don't need it or you don't have it. I can totally see that it would be necessary in very large organizations, but I think that What is ownership if not understanding the whole lifecycle of the product and understanding where do you want it to go? I don't really care. I was Chief Product Officer. That was my title at Eli. I always introduced myself as the product owner because it's my product. I own it. I call the shots on what happens next. I figure out where it goes. So in a way, I don't care personally that much about the distinction, but it is true. That these different sorts of tasks do exist. And occasionally you have to split them to different people. I was giving a talk, I don't know, a year or two ago to a group of product owners in a public sector organization. And they were very heavily project organized. So everything was organized around projects and the product owners were a little bit lost in there and trying to figure out what is product ownership when everything that you do is actually run in a project and you have project managers, try to tell them is that you have the vision and you have the roadmap, the big picture idea, where do you want to take that product in long term. If you have resources occasionally given to you in projects, then you have to be able to tell the organization around you that, okay, with this project, I can deliver this value in this time. If the project is cut, then that value is going to be delivered in some, some other time. And that's your job, basically. It doesn't really matter if the resources are allocated via projects or not, but you have to know and understand and communicate how that affects your product. And that's the importance of the role in that sense.

I've done some work around team design now for the data stuff, and I talk about temporary teams, which are project teams. If you're a product owner or a product manager, and you're going to be there for 3 years and you're getting iterations of people that can come and do the work for you and get disbanded. That's not great. It's not a great idea to have people turn up, build half your product and bugger off. But it's okay. You're there for 3 years and you can build that roadmap and go for funding and get your team again and build it out. But if you're being allocated to that temporary team to build this product, and I'm using quote marks here with my fingers, and then you're disbanded then actually it's not a product. It's a project. It's an iteration. Don't even use the term product owner and product manager because there is no product because there is no life of that work you're doing. You've built it, you've walked away, and it's going to die whether you want it to or not. So product thinking is long-term. That's one of the big differences, I think, between product and project.

Absolutely. And I think many organizations still have problems with this very concept that people do not necessarily understand And I think, again, especially in data, people do not necessarily understand the management of the whole lifecycle, not just, okay, now we built it, now we're gone, and then we're assigned it to some outsourced offshore team to be maintained from now on. Product ownership is eternal in the sense that you have the full lifecycle that you have to manage, and that responsibility is not based on development versus maintenance mode. That is for the product.

And again, you come back to that conversation about, okay, so let's say we're in a larger organization and we have 20 or 30 or 40 data people, right? And we've broken them up into teams, squads, pods, whatever term you want to use. We then have to have a conversation about what are they aligning to? Let's say they are value-stream aligned end to end. Are they then aligned to a domain? And is that their specialty? Or do they pick up the next bit of work off the roadmap? And it may be in a different domain and they do that work. Again, we have to make those decisions as a product manager about how we segment our product up into smaller chunks if we've got larger teams and we can work in parallel. And that team design for me, again, it's part of the product manager role. In terms of our product, I've made a decision on how I've chunked it up. I'm making decisions of which area in our product is being worked on next. I can scale the team out if we could afford to have different teams, and I know how I'm going to scale that team within the product I've got, 'cause I've designed the product to scale if we're lucky enough to get that number of people. So that's the thinking I've done from a product and the product manager, the data product manager should do the same for an organization and data. They should go, how are we going to actually do that team design? Because it's their product, data is their product. And I don't see that. I often see the product manager, if there is one, lower down and some other leader doing the team design, doing the organization design, deciding we've got a team of analysts, a team of BI developers, and a team of data engineers. they'll be separate teams. Half of them will be in technology, half of them will be in the, again, earmark quotes, the business. How do you run a product when you're not in charge of how that product's built?

That's a very interesting point because what I've seen now a few times is that organizations see that they would like to get started with data product thinking and doing data product. Data product management is something that they are eager to try, but the organizational structure is in no way suitable for that. Because you have your centralized team of data engineers. And I think when you try to define data products in that sort of a situation, it exposes the situation very clearly to everyone involved that you might be able to find a data product owner and assign them, but they will have zero resources. There are no resources. The only way they can get their data product developed is that they send tickets to a centralized data engineering team. And that immediately shows you that, hey, this is not how actual product management should work. And it means that it does require the organization at some point, at least, to rethink the ways it has organized data work. And I think that's very good. I think applying product thinking, identifying data products, giving them boundaries, giving them owners and figuring out the roadmaps and so on, that act can lead to, and it should in many cases lead to, changes in the overall data organization structure as well.

I've definitely seen in successful organizations that have had successful data programs or data delivery or data teams, it's the head of data, it's the leader of that part of the organization that's actually adopted product management thinking. They've gone out, they've figured out what the strategy of the organization is and how they support it. They've created the roadmap and convinced their peers that it should be worked on next. They've gone and found funding for their team or what they should fund next. They behave like a product manager, although they'll be called head of data or chief analytics officer or something like that. Strategy, roadmap, funding, prioritization is the next one. When we do product, we have 101 things we could do and we can't do them all. So we figure out some way of prioritizing what we do next. I'm quite lucky because we are small and it's my product. My co-founder and I have robust discussions on what's next, but that's it. And then it's prioritized, and then we build it. You work for a slightly larger organization. So, from a product management point of view, how did you prioritize the work to be done?

That's always the most difficult thing of product management in the end, isn't it? In larger and smaller projects and different organizations I've worked at, even as a sort of Scrum product owner earlier, I've always viewed that part of the role to be one of a funnel. You're a funnel. There's all sorts of requests and ideas and wishes and hopes and demands. About the product coming in from different sources, from all different sources, from all possible different stakeholders. Some guy contacts you on LinkedIn and says, hey, your product should be doing that. That is input. That person has zero actual decision-making power in your organization, but it is input altogether. And you have to take all of that in, and then you have to start balancing things out and considering, given all of this input, given my personal input as well, what should be the next best thing to do. And that is, I think, the most difficult part of doing product management altogether. I can't say that I've had any specific method to it. You'll see Agile methods and so on that you assign certain values to tickets or feature user stories. I've never been very eager on that because the input is so varied. There's so much different sorts of input coming from different sources that most of it is going to be in any case qualitative. Qualitative information, not quantitative information that you could put in a number. So in that sense, it's going to be more art than science. What the result should be is a single prioritized list of things that you need to do. And I'm not talking about priority categorization. So these are priority 1 tickets, these are priority 2 tickets. It's a single list. This is the next thing, this is second thing, and that is the result of that work. And that may involve saying no a lot of time. You're going to be pissed off so many people as a product manager.

I agree. Stack ranking, first, second, third, down to 500. That's it. And if you've got one team, you take from the top. When they finish that one, they do the next one because humans are crap at multitasking. If you've got 3 teams, then they take the top 3, they work on them. And when the next, when teams finish, they take the next one. Again, we give the opportunity to reprioritize at any time. Ideally, we say don't reprioritize work and play because we'll lose all that value, lose that effort. But feel free if we've got 3 teams and pod squads, whatever you want to call them, and number 1, 2, and 3 are in play, then feel free to reorganize 4, 5 to 100. We don't care because we haven't got there yet. I think it's important, but I do see a lot of RICE and weight scoring and gamification of that. I think the difference though is again, it comes back to accountability and responsibility and ownership. Because as a product manager, you're typically expected to listen to all the stakeholders and then make a decision what's next. In the data world, we seem to push it off to committees of people that are outside of the data domain to tell us what's next. And I think that's one of the big differences that actually if we adopt product management thinking and data, the data product manager actually makes the call of what's next.

Yep, yep, totally. I think, Part of that should also be proactively seeking out that information, that you're not just sitting down and waiting for someone to tell you what, what you should be doing, or you're waiting for demands to come in into your funnel. You should be going out there, discussing with people, talking to the actual users of the product, talking to potential users of the product, talking to industry influencers to get new ideas, to see what is going on. Talking to your, if you're building, I don't know, data products for factories or something, talking to the people managing those factories, what sort of ideas they have for expanding those factories. All that information is something that you have to gather. It's not going to come to you if you passively just sit on top of your data product and wait for things to appear. I think that is part of being a good data product manager. And I am not seeing a lot of that in current data work. I am hopeful that I started seeing data product managers and data product owners appear as titles, that this could actually become normal parts of data work as well. But I think we're still quite a long way in terms of the kind of cultural change that we need for that.

I think one of the big problems is data people love to talk to data people, and we love to stay in our own ecosystem, echo chamber. So, all the people I see talking about up data product management right now are data people. I don't see people who have gone down the Marty Cagan route and applied that in a product organization for 5 years coming into our domain and telling us how to do it. I see us making it up. Data people may be reading a book, probably not. And I think that's part of the problem is that we don't acknowledge there is a profession and a domain that does this well. We need to immerse ourselves in what they do and then take the bits that we think are valuable. And prove they're valuable rather than trying to make it up ourselves, because most data people aren't product people.

Exactly. But isn't that what we've been doing forever? We're always coming up ourselves with ideas that have been business as usual for many years in so-called normal software development. Think about version control or testing or X design. All of these things we're figuring out ourselves and saying, oh, this is a new thing in data now. Yeah, but those guys have been doing it for 25 years. Agile or something like that in data. And product management is now exactly the same thing. We're going to be starting to do things that everyone else has been doing all the time. We're trying to figure it out ourselves, but we should be really using the well-known trusted methods and learnings that we can get from real data product management. Now, and one thing I want to add on that, I wrote about data products on LinkedIn, some time ago, and there was lots of discussion there. And many people quite correctly pointed out that Juha, when you are talking about data products, it seems that you're just talking about any kind of application. It could be generalized. What you're saying here could be generalized to be about any applications. What's the difference between a data product and a sort of normal product? And my point is, there is no difference. Why should there be a difference? They're just products like any other. What product management is and does with regards to data is in no way different, I think, as a sort of product management as an activity than it is in any other product. I don't think there should be a difference. Data is not a sort of unique, somehow, discipline where everything works differently. The same sort of basic things work in data as they do in software, as they do in, I don't know, if you build shoes and sausages, it's the same things there. They are product.

I'm going to disagree with you on that, but let me put some context around it.

Sure.

Let's go back to that conversation about we are for some reason behind the rest of our brethren. And I think if I look at DevOps and CI/CD and version control, we have adopted that to some degree, DataOps, cloud enablement, those kinds of things. And I think the reason we've managed to adopt some of that relatively well and some we haven't is because it was based on technology. Data people are technologists. So, what we could do is we could look and see Git, push me, pull you, Mooji thing, and we can go, okay, how do we apply that technology to data? And then how do we apply the practice on top of it? And so, we can see some technology, we see how it behaves, and then we can copy those patterns and apply them to the way we work. When we look at product management, it's not based on technology. It's on the left-hand side of our value stream. Fluffy, it's conversations, it's Word documents, Google Docs, it's an Excel spreadsheet or a Google Sheet if you're lucky with a scoring on it. There is no technology that we can just copy and adopt in the data world. And that's why I think we need to inject the product manager people into our domain because we can't learn it through technology. The second thing is I think data gives us some more challenges to compete to software products. Because with a software product, we are in charge of the capability to capture and store that data, and that reduces a whole lot of complexity. In the data domain, we are typically given that data by somebody else, and we have no control over it. And that makes our job slightly harder, I think. That's the difference, is that we can't trust what we're given. But if we're in a product management environment for a software company, We trust our team, our team are building the right things. We trust, and I don't wanna use the word materials, but I'm going to, right? We trust the materials we have to build, whereas when we're in the data world, we get given data that's crap 9 times out of 10.

I get what you mean, but I'm thinking, where do you draw the line? Let's consider now that we have, I don't know, IoT data coming from production line in some factory, and there's two machines. One is doing something and it feeds data to the other to do something else. You know, your data input and there's something where the data goes in. Now, if you create some sort of controlling system, that's these machines, kind of software development, IoT, whatever you want to call it, that's a product. It gets a data input from the other machine. It does something with that data, you know, guide the other machine to do whatever. So that's software development. You can create that product and you can figure it out. You're still getting data in. You're doing something with the data. You're providing data to something else. It's a data product as well. At that point, we would not be discussing about data products, we're discussing about some sort of IT or, you know, machinery thing. If we take the data from machine 1, we shoot it up to cloud, we run some sort of ML algorithm there, and we shoot the result back down to machine 2, then suddenly we are in data and analytics. Where do you draw the line there? Why do we suddenly become a different discipline when we make the loop longer?

That's a great question. And I'd hope, when I read the original stuff around data mesh, we've always said that if we could embed data practices in the software engineering teams and put ourselves out of a job, the world would be a better place. But it's never happened in 3 decades. I looked at the original definition I had of data mesh, which was to do that, embed the skills and the capability in the software engineering teams and not have a data team. Now, that doesn't seem to be the definition anymore, but that made sense to me. I've never seen it happen.

We are increasingly seeing data from these traditional analytics solutions being fed back into operational solutions. But that loop has become faster and shorter, that data feeding back into the operational activities. I think that is what is going to change the game because we're no longer just creating a dashboard that someone looks at and then person goes somewhere else to do something else. We're in the loop now directly with the data products we create. This is my prediction. I have no data to back this up. This is my feeling. That is to break down the barriers between software development and data development because the loop is getting faster and shorter and we're going to be involved in operational activities, whether we like it or not.

I agree. System to system. That's the thing we've never been involved in typically. We've always been an exhaust, not an enabler. That's going to change. Okay, let's go back to product management. So we've now prioritized, and as product managers, we've talked to everybody, we've made the decisions of the next most valuable thing because it's our product. We have to deliver the value, we're accountable, and we've made that decision and articulated it out to the rest of the organization. So then we get into requirements. And for me, what I do is, just like when we're building our software product, I want a very light version of requirements early so I can understand what it is, how big it is, where it fits before I'll prioritize it. And then once we start working on it, that's when we go into detail. And I think we should do the same in data. I'm quite vocal around the Information Product Canvas because that's my baby. Um, so what I'll do is I'll use the IPC pre-prioritization, and then I'll use the Amazon press release format for any platform features, any enablement features. And the reason, as I said before, is I can look at those two templates and I go, that one's about delivering data and information, and that one's about delivering a capability. And I know which one I'm looking at just visually, 'cause completely different format. I also find the IPC is great for understanding the action and output from this information that we need to provide. And the press release is actually a great way of understanding features and capabilities, 'cause effectively when we build a data platform, we're effectively building software. So that's what I do, and I'll do those really lightly early and prioritize based on those, and then I'll get into any kind of detail work. Once it's been prioritized, pulled off the queue and been worked on, it's number 1 in the stack rank, the team are picking it up, that's when we go into detail. Because until then, it's waste. What's the point of doing a whole lot of analysis on something that may be 498 in my stack ranking in 5 years from now? Now that brings some challenges, which we can talk about, but how do you deal with it? How did you actually do product requirements as a product manager? And then how would you apply that in the data world?

I think this is super important. Traditional way of doing data production, which is that we try to find out what data we need to push to the end user. The question that we usually ask, and even if we don't ask it, that's the answer that we're given. So, we can very, very detailed lists of individual attributes in an Excel file. I want to see these things. I want to see all transactions. And it gets very quickly to very, very detailed specifications of of attributes. Obviously we are building up the roadmap, figuring out what do we have on the backlog. That information is first of all unnecessary because we don't need that to make the prioritization decisions. Secondly, it's going to be useless in 3 months from now. I push people from thinking about the data that we should push and then why do you need it? What you're looking for? Because eventually the answer could be completely different. The solution design might be completely different from what people are even asking. Asking for. We have trained people to ask for datasets. They are thinking in terms of tables. They're thinking in glorified Excel files. What we should be asking is what you're looking for in that data. Why do you need that? Maybe the actual solution would be that we send an automated SMS after some kind of a transaction happens, or we build some sort of automation thing that stops the production line when something happens. Maybe that is the answer. But what we are getting is, I want to look at this data as a requirement. We need to kind of beyond that. We have to get into the actual business process and figure out where that data is needed. So coming back to the, how does this link to prioritization? What I try to help people with, trying to find the actual business reason of using the data, not the specification of what data they want to use. And then I try to use that prioritizing thing. How are we going to affect the business with what we are doing? And then when we decide to do it, then eventually we get to, you know, okay, so what exact attributes do you need? It's a just-in-time principle, really, that you should be actually getting your attribute descriptions and so on 5 minutes before you start coding, rather than half a year.

Yeah. And we should pick up things like jobs to be done. What job do you need to do? And then we'll be experts on how we can get data and information to help you do that job. The number of times you hear, I need this data. Okay. And what features do you need? I need to export it to Excel. Okay. So what you're telling me is you're now got a second step in this job. What is that step? Oh, I'm going to go and filter it on our most valuable customers and then go and send them a marketing offer. Why don't we just do that bit for you? Why don't we finish the job? The classic example I love is I don't need a jug because all I'm going to do is get the jug to boil water to make a coffee. I just want an espresso machine so it makes me a coffee and just happens to boil water when it does it. The job to be done is have a cup of coffee. And then the detail of that requirements document is really dependent on your team design and your value stream, the way you work. Because if you are following iteration-based end-to-end self-sufficient team, you don't need as much documentation because you give them the problem and let them do their expertise and talk amongst themselves. If you've got a functional team design where somebody above you has decided that you've got BAs who hand off to the designers who hand off to the engineers, who hand off to the visualization team. Now you need more documentation because your handoff is that documentation, and that job to be done needs to be articulated all the way through. And the people at the end of that value stream aren't lucky enough to talk to the original people who want to get the job done. So, we have to make sure our requirements map to the way we're working. And again, less waste. I still see, though, large product organizations doing PRDs, product requirements documents, documents. Is that what you've seen when you were building a product? Did you do PRDs or did you do something lighter?

Well, in a way, I don't think I've, at least many times, used any specific template for product requirements, but I always have a requirements document that explains what this product should do, even for individual features. It's simply so that we have a record of what we have agreed on. The detail level, it's a different way. If the organization structure is such that you have to do multiple handovers, then obviously you will need to document everything to the most detailed level. Sensibly, if you have a group of people who know what to do and they have that kind of agreement of what to do written down so that they don't forget it, then the details do not actually matter that much in the documentation, with one exception. You have to think what information about the data product has to be maintained for posterity. So that people understand what the data product is about and what it contains, what the calculations actually do, what does this customer lifetime value mean, that has to be documented, but that's not documentation for the development team. It can be created and it should be created during development, but that is documentation aimed for the users of that data product. And I think that's way more important documentation actually, than a kind of requirements documentation for development needs, unless of course As you said, if you have that kind of an organization where handovers are multiple, then there's no alternative to that.

I think we can lighten up some of the requirements for the data products that we're seeing, but we still need documentation for a bunch of reasons. And again, what I always say to teams is, figure out what the document looks like, and then tell me who's going to use it next and what are they going to do with it. And if you can't tell me who's going to use it and what action they're going to take, take, then actually we've wasted our time, it's waste. But if we have people taking an action later on and they can't find what they need, then we've got wasted data. And so that needs to be documented and we should automate it. The system should document everything we need as much as possible. So prioritize that to stop the humans having to do it.

One more quick point on documentation, because I've been working on this very topic recently, the documentation of the data product for its users. I think there also the question should be, What do people need to know about regarding this product? What do people need to know about so that they can utilize this data product for its intended purpose safely and they can trust it? And that's everything you need. You don't need anything else. You figure out what people need to know, you give them that. You figure out what people need to be told about the product, you document that and nothing else. And there's your documentation.

I mean, we had this conversation offline around business glossaries, because I'm working on that next. And I sat back and I went, what does a business glossary need to do? And then I ran out of energy and I go, okay, here's all the table stakes things that it has to do because everybody does it. I'm going to have to think more around actually what should it do? It's a much harder conversation. But if we go back to product, if we go back to cereal on a supermarket shelf, what do I do? I pick up a box, I look at the expiry date, and then if I'm on a health kick, I look at the sugar and fat levels. I've got a little table of contents. And then I look at it to see if there's anything in there that I don't like. Don't like nuts. Okay, there's no peanuts in there. That's all good. That's the information I need from that product to decide to buy it. That's what we need on our data products. What do you need to actually use it? What do you need to buy it, to invest in it, to spend your time doing it? That's what's important. And you're right, our catalogs aren't designed for people to do that. They're designed for us, maybe, but actually they're designed so vendors can spend a fortune putting them in and nobody can use them because Very rarely do I see a data catalog being used, which is sad because it's a valuable tool. Okay.

It is.

Let's jump on product-market fit. Do you want to explain what that is for data people who have never heard that term?

Honestly, I'm not sure if I can explain that in very simple terms. I see vague discussion about product-market fit. All the VCs are saying, yes, there needs to be product-market fit, and that's the most important thing. And you don't get a very clear answer of what that really means. I think it's important if there is an actual problem that the product is going to solve. You understand what the problem is. The product can actually help with that problem. And there is enough of that problem in the market that it makes it sensible to create such a product. I think as far as I would go with product-market fit, everything else on top of that, sprinkle on top, I'd say. Okay.

I'm going to try a definition. So when I start off, when I start off coaching a new team or a new organization, But I talk to them about balancing out time to market, so ad hoc behavior where we build things quickly, and building things that will scale without over-engineering them. And that is an art. But I talk about that scaling thing because I say every organization I've worked in where data's become a successful part of the business is there is an adoption curve, right? There's that linear bell curve that you get from any product. So we go out and as a data team, we should find those early adopters in our organization. Those people that are hungry for data, are willing to take risks, are willing to invest their time to help you get the data or information to them. They are early adopters, they are excited by it, and there's always a small group of those, and we should find those, and we should build for them. Because what they'll do is they will then go start bragging to their peers about this great stuff they've got done. And then the rest of the organization starts to observe. We start to see the adoption take up a little bit. And the organization starts going, I've asked for data for years. People have told me they could do it. I've raised a Jira ticket. 3 years later, somebody came and asked me if it was still valid or actually the system just shut it down. But actually, Steven over there and Kate over there seem to be getting some information. I'm going to keep an eye on this. And then a few more join them and join the party. And then we hit a problem. We hit this massive adoption that all this latent demand absolutely snots us. That to me is product market fit. That is where we have people coming in and demanding that we work for them next because they know we can deliver. And that for me is product market fit for a data team. If you're still out there pimping, if you're still out there asking for people to give you some work, if you're still out there trying to get people to use your dashboards because you built it and they haven't come, that is not product-market fit for a data team or a data product manager. So, that's my definition.

Yeah, I think that fits actually with what I kind of said. It is about having a product that solves some kind of a problem on the market, a big enough problem, a wide enough problem that there's actual demand for the product. And it's not just that this kind of thing exists, you have to be conscious of it, and the market has to be conscious of it as well. So, yes, if that is the case, then we will reach the situation that you described there. I think that's kind of how it should go.

And if you become a data product manager, the benefit you have is you have a much longer runway than most product teams. You're funded out of the organization typically, not by a VC who's going to not fund you again. You have very few competitors because there's not a lot of competitive companies that can come in and do the data work in your organization without you. So, you have a whole lot of benefits of getting product-market fit over a typical product company. Okay. And user journeys, how would you apply, what is a user journey, first of all, for data people who haven't seen one? And then how would you apply it in the data domain?

Right. Yeah. That's actually super important. I'm no user journey expert, but I've been dabbling with them. And I think the important thing is again, to understand the job to be done, what problem the user has, what are they trying to do and how the product is going to help them with that. And I think has to go quite deeply into the actual activities of that end user. And you brought up the export to Excel example previously, and I love all the memes and stories about export to Excel, because early on I was just laughing like everyone else at that time as a younger data expert saying, "Haha, weird users are just exporting to Excel. They don't know that they could do things in our product." But nowadays I see better, I see that It's just a sign that we didn't actually go through the user journey. We didn't understand what the user wants to do. We built them something, we gave them a set of data, but export to Excel is a sign that we didn't understand the user's actual journey or job to be done. And doing that means that you actually track basically the decision-making that the user has to do, the activities they have to do in their life, in their processes. There's the guy who goes to the machine, flips a switch, switch or something, you have to know that they go there and flip the switch based on the data they got. That's part of the user journey. And that's also kind of why I think that service design discipline is something that needs to be more involved in data products as well. Because we have to be able to understand the user's journey well enough that we can design a service that fits that particular user journey rather than will do that. Because pushing out data is never actually solving the actual problem. There's the mass of activities after that, which most data teams are completely unaware of.

I think the other thing is, let's look at the user's journey for the job to be done, but then also look at the user journey for our product. So, go and map it and say, actually, go and try and order some data from your organization and see what happens. Because if you're building a product, in that space, you worry about the product itself, what features and functions and jobs to be done, and are you serving that market. But you also worry about the user experience, about how can they find it, how can they buy it. So I don't know about you, but every time I go onto somebody's website and I look at the product and I go, oh, actually that could be quite useful, and then I get the contact us and I get called by an SDR, my user journey is dead. So think about that again. Think about you're a product team internally. You've got the benefit of a captured audience. You've got some benefit of funding, but actually, think like a product manager. What's the user experience? What's their journey buying your product, using your product, as well as getting their job done? So I think you can take user journeys in both lenses, and I think they're both valuable.

Totally, totally. And I think that kind of relates to data catalogs that we talked about a little moment ago. Where this journey actually starts from is that someone has that problem and they say, oh, I need to optimize road transport costs in Germany. So that's the start of the whole journey. And now the whole thing breaks down immediately in many organizations because there's no way they could search easily what sort of data products do we have available about road transport costs. The whole thing breaks down immediately. If we had a very sensible data catalog, we would have search field there that you could search for logistics costs or something, and you could get a list of data products, and then you You could point at the data product and say, okay, I want that. And then you would be somehow guided to see the data, to use the data, to apply it, and then your initial problem would be eventually solved. We don't do that. We don't have that in many organizations.

No, but GenAI is going to fix it, right? It's going to magically answer every question.

Yeah, yeah, totally.

Okay, let's go quickfire. Should the data product manager manage the team? What do you reckon?

No.

And why?

I think managing a team of human resources and managing a product are different kinds of work. Different kinds of people are usually good at different kinds of work. And I would say it's rare to find a person who is good at managing members of the team and managing a product at the same time, let alone the fact that it would use a lot a lot of their effort is going to be split into completely different kinds of activities, and you can't really focus on either. So I don't think that team leaders should be product owners or product managers.

Okay. I'd answer it in terms of the product manager is in charge of the work to be done. That's their focus. So they guide the work to be done, and they make sure that work delivers value. If you're in a small organization and that person has pastoral care of the team, they look after the team, make them healthy, career, all those good things, and the person has both sets of skills, then great. But they have to have both sets of skills. And often you are, uh, left-brain, right? You are a people person that loves looking after people, or you're a delivery person that loves delivering value. Times, you know, people get given the wrong role. So that's my answer is if you can do both, yes, but actually if you can't Your focus is product management, delivering products of value. Should the product manager be the warden of Jira ticket prison?

In a way, yes. If that is the way you actually want to do it, the actual means, the actual processes of doing day-to-day product management, these differ. And if your way of doing that is to actually have a Jira ticket for everything, then yes. The point of that job, The point of that job is to figure out how do you deliver, what should we do next with the product. If that practically means balancing Jira tickets, then sure, yeah, do it.

Yeah, my answer is if you're using Jira, you're not a product company, and then you should just stop. But that's not actually true because everybody uses it. I just hate it with a passion. Okay, should the data product manager be in charge of the product vision?

Yes, absolutely unequivocally.

Should they be in charge of profit and loss tracking?

I think for actually, because of the reasons that we've been taught, you know, how data products do in a way from sort of real software project products, it will be difficult because most organizations are built so that you can't often see directly the profits that your data product creates, unless you're actually monetizing the whole thing and selling it outside the organization. So I'd say ideally, yes, but practically, it would be very, very difficult.

Yep, I agree. If you can get line of sight, great, but normally we're influencing rather than delivering something that can be attributed directly. But we should try, we should try and have an idea. Should the data product manager be in charge of access management decisions? Who's allowed to use specific sets of data?

The question I keep asking organizations when it comes to this is, who do you want to make those decisions? If you, I don't know, separate data owner in terms of kind of content and access management, a separate product owner who makes, or product manager who makes decisions on individual data products, I think that's a perfectly valid way of doing things. But if they are the same person, you know, why not?

Yeah, my view is you should automate it. It should be based on policies and then people don't have to make a decision. They make a decision on the policy. And then the system takes care of it, and we remove that waste of a human trying to be an intermediary. Should the data product manager be in charge of prototyping, or should they prototype?

I don't know who practically does the prototyping, but the data product manager decides that we are going to prototype these things.

Yeah, I agree. I think prototyping, MVP, research, UX design early, they're all valuable patterns out of product management that we can apply to the data world and get value out out of, so go try them. Okay, should the data product manager be the VP of the business unit? Should it be the hippo?

Oh man, if for some reason the data product is so big part of their lives that they can consider all these aspects and act as the funnel of all incoming demands and juggle the Jira tickets, if that's what they need to do, if they are willing and able of doing that, then why not? But I'd say that in 98% of cases, that's probably not going to happen. So it's going to be someone a little bit lower on the hierarchy who deals with individual data products.

Yeah, I look at it and say, when you have that behavior, it's a VP, they're normally doing the strategy and potentially the funding, the roadmap, and they sometimes do prioritization. What that means is then they actually disempower the product manager. So if they are in that role and they can do it all, good, but if they're going to do half the role, they're disempowering the product manager from making the value decisions. Should it be the analytics engineer or data engineer who built and maintains the solution? So, should it be a technical member of the team?

Depends on how the organization works. I think it is a valid choice if the engineering person is deeply in touch with actual business users. They have to proactively seek for feedback, seek for demand, seek for changes needed or something. If they're able to do that, then sure, why not? That just means that the communication loop between the product manager and the actual developer is going to be very short, which is good. Again, they can't sit back and wait for tickets to come in.

I'd say it's an anti-pattern. I say it can work, but it's very rare. So if I look at a software development team, it is unusual for the UI React engineer to be the product manager.

Yep, yep, yep. Again, it's a different skill set, right? It's a different skill set.

So if you want to do that, embed them in product management training and patterns, and then they'll pick them up. But you can't just go, you're the product manager. Okay. Is there a difference between a product manager and a product owner?

Well, this we discussed in a way, or, or I don't really care much, to be honest, about the differences. I just want someone to be there to make the decisions that need to be made. If you want to split different decisions to different roles, That might be necessary in some organizations. You can use whatever titles you want. I don't really care. I just want those decisions to be made.

For me, it's around clarity of terms. So if I hear product owner, the next question I always ask the organization is, do you follow Scrum? If I hear yes, then now the product owner is behaving like a delivery person to a degree and is very rarely doing the strategy, roadmap funding, and prioritization. So then I go, okay, you need a product manager. So for me, it's around that definition. And I think product owner now in the last 10, 20 years has been superseded by the definition from Scrum. And therefore, I use it now differently, which is really disappointing because actually, I want somebody that owns the product, not manages it. It's like owning the strategy, the roadmap, and the funding. That is all ownership, not management. It's leadership. I keep being tempted to talk about a data product leader, but then that just doesn't work. It's not a term that comes from anywhere.

I mean, common sense, consider these terms in terms of common sense. Owner and the manager, who is the kind of bigger boss, obviously. That's not practically the case, I don't know.

And then even at a C-level, it's Chief Product Officer, it's not Chief Product Owner, so that's different. Okay, last couple of questions. Does a product manager in the software development environment need to understand the software development process? Not do it, not have done it, but do they actually need to know the mechanics of how the team builds?

I think you already asked two different questions. Do they need to understand the process and do they have to understand the mechanics? For the process overall, I'd say yes, you have to understand how the process of doing development works. For the mechanics, I'd say no, not necessarily. It can be a good thing if you understand a little bit more, but I don't think you have to know anything about APIs or so on. You just understand that there's an output port that can be utilized by machine, and that helps you make decisions related to it. I mean, it's helpful, but not necessarily.

Okay. And so if you're a data product manager, do you need to understand the process and/or do you need to understand the mechanics?

I'd say it's the same. Understand the process, understand at the level of logical architecture, we have a set of data here and there's a reporting application there. That's the data. You have to understand what your product is, right? It's made of these things. These are the pieces in the product. These are the boundaries. Of the product, which is one of the most difficult questions about data products, actually, I think, is where it ends, what parts belong to a data product. But you have to understand what's in your product. You don't have to necessarily understand how that thing inside your product works.

For me, if you've played on the field, if you've worked in both data and product management, then you've got a head start to anybody else. If you've only worked in one of those, you need to actually immerse yourself to learn the other one. You don't need to do it, but you need to understand it because the language is different. The amount of time I spent trying to understand, do I go Angular or React or Vue or, I didn't need to know how to build them, but I needed to make a strategic decision for our product on which one of those we're going to bind ourselves to. And we were going to live that for 10 years. That was a strategic decision for me as the product manager. But I had to do a bit of learning about what the hell are those these things? Why are they different? Why am I making a decision? Why is it important? So that's the thing, right? If we're getting a product manager outside of data coming in, we have to teach them the language we use. We have to teach them that you can have 5 products and there might be a product of products because we want a single view of customer. It's quite complex to understand if you're not in the data domain. And the same as if we're data people, we need to learn how to do product management, not treat ourselves as the customer and building what It's a completely different mindset. Anything you want to cover before we close out?

I think actually almost last sentence there about the mindset. I think that's what this comes down to, right? The whole thing is about product management mindset applied to data. And with that, all the kind of best practices and roadmaps and strategies and so on and so forth. But you have to start with the mindset and then you go from there. I think that's An excellent summation of the whole thing.

Excellent. Well, we'll put that at the front and then at the end. If people want to get hold of you, what's the best way to get hold of you, figure out how you can help them, talk to you about data catalogs, business glossaries, or data product management?

LinkedIn. I'm very actively on LinkedIn. I don't always remember the post thing, but I read a lot of stuff on LinkedIn. So hit me up on LinkedIn. Always happy to connect with like-minded people. I have my own little company now called Data Core Consulting. So there's a website called called datakor.fi. It's data K-O-R as in my last name, but the core works almost. That's where you can find more information about myself, but LinkedIn is where I hang out. So just contact me there.

Excellent. And you're definitely active. We have lots of good chats on there and tend to post on the same things. So it's great to see you there with the rest of us. So excellent. All right. Thank you for another excellent podcast. And I hope everybody has a simply magical day. Data Magicians was another Agile Data podcast. If you'd like to learn more on applying an agile way of working to your data and analytics, head over to agiledata.io.