Watch now | Recording of AURA - Anna Bergevin & Shane Gibson on 13th July 2026

Hey, Ina, hey, thanks for coming on to Aura. You're the third of the Awesome Foursome, so great to have you on here, and I'm particularly looking forward to having conversations and seeing if there's any questions around the kind of product management and product lens to the data world. So what's happening? What's top of your mind at the moment?

Well, what is top of mind at the moment? I mean, it's annual planning time at my company, so top of mind is is roadmap and just commitment cycles. Been doing a lot of work right now around, you know, it's interesting because your, your branding is about agility. And I feel like the hospital is really struggling with this idea of like how to be agile and how to also know when you can make a commitment so other teams know what they can count on, which internally, you know, when you're an internal data team, So explain to my product team of like what it means to like kind of lock in the quarter because our executives need to know what we're actually going to deliver. And by that, I don't mean every tiny report. I mean the big, the big investments. And so that doesn't feel agile. That feels anti-product in some ways to people. But I'm like, here's how I handle it, which is when things come up mid-quarter and we're expected to pivot, is if the executives accept that and tell us yes. But what we do is try to explain this thing that we committed to, this is what's at risk if I accept this new thing. So we leave that call to those people who have the authority to make that call is what we try to do so that we get basic, we can be agile, but we can be committed. So that's been dominating my mind for the last month internally. And then I think broader industry-wide, What I'm thinking the most about is like knowledge management, context management, and how the role of the data team changes in the world of AI. And of course, in an enterprise, it's not changing today. We don't have like everyone's talking to robots, everyone's talking to agents to get their analytics, but it's clear we need to build metadata pipelines and context pipelines in addition to traditional data pipelines. So thinking about what's the system we're going to build that's going to enable that, that's my macro thing that I'm thinking about a lot.

Yeah, the agility one's interesting, right? So I kind of differentiate ad hoc to agility. And so, you know, for me, it's not about, you know, moving fast and breaking things. It's about being able to change at the lowest cost and with the greatest speed. And so, you know, when we talk about quarterly planning, Yeah, it kind of reminds me of SAFe, Scaled Agile. And yeah, I'm not a great fan of those patterns because what I find is while the intent is the ability to give you a roadmap for 3 months, you actually end up locking one in for 9 months, right? Because everybody's kind of 3 3s out. But what I always say to stakeholders is change is okay, it just comes as a cost. It's not free. So what would you like to do, right? Would you like to pay that cost? In terms of work not done, or would you not? Because, you know, if you're the people in charge of prioritization, you get to make that call, right? What's the next most important thing the team can build? I think in data, lots of people treat it as free, right? You put a Jira ticket in and that request is there, you don't have to pay money, you never have to pay any time, you just wait for somebody else to do all the work. So there's that real challenge, and like you said, bringing product thinking into data. It's not as easy as just treating it like a software project, in my view, right? It's kind of— the patterns are useful, but you've got to apply them in certain different ways.

It's a lot of translation. So like, um, the big reason I started writing When Data Met Product was because when I started working in data platform as a product manager coming from like the software side, um, it felt like every podcast I listened to, every book I read was like, well, yeah, but I don't have external customers. I don't have go-to-market. I don't have these, like, I, these things people are talking about don't really apply in my context. And also data. The biggest difference between software and data is the company I worked at, um, on the software side, they had bounded context, meaning every team kind of controlled their database, controlled their context. And they would share data streams between teams. And so you had kind of this very ability to move fast because your team didn't— was loosely coupled to other software teams. In data, it's like, it's like your raw materials are just being thrown at you and you have no control for how they're showing up and you're supposed to create stability and, and value out of that. And, and yeah, we are trying to do data contracts and do a little bit more reliability upstream, but I think data is quite different than software, even though the patterns are useful. So it's all translation, and hardly anyone's creating content about how they're doing it. And, and there are people doing it, um, and there are leaders hearing about this and hearing it's valuable, and they're hiring. But even like Netflix's data blog just talked about data as a product like 6 months ago. Netflix, you know, Silicon Valley is supposed to be cutting edge. So like, if people are doing it Everyone is a pioneer, everyone is new, no one knows what they're doing. They're finding useful patterns, but nobody— there's no best practice emerging. And we are starting to see now, 3 years into it, 3 years into my— 4 years, actually, into my journey of this, a couple of books are being published, a couple more, more than just data mesh's idea of a data product, more about product thinking applied to data. We're seeing a little bit more coming out, but it's still very much there's not enough content to guide new data product managers at all.

Yeah, I've seen, seen a lot of books coming out now with the words product and data, and like you said, some of them are technology, how to build a product technically, uh, some are process, some are trying to define it, some are product thinking for data, some are team design. So, you know, it's all those lenses that actually— there will never be one book to rule them all, I don't think, because it'll be too big a book. But they're taking those different lenses. But then how many product people or data people have time to and money to buy 10 different books and figure out which ones are giving them the bits they need and then cobbling the Lego blocks together themselves, right? That's the hard bit because we're stealing from product, we're stealing from agile, we're stealing from data when we try to put all those together into a new way of working. And that, that's hard, right? That's pioneering work.

Yeah, this is why my favorite type of content is more podcasts or conferences. I want to hear, like, we had to tackle, like, I want to talk to other hospitals about how they tackled a unified longitudinal model across EHR systems, right? So electronic health record systems in the United States. Most hospitals, our hospitals been around over 100 years. Most hospitals have a long history and if they have migrated EHRs, which many have, they didn't import all the data because it's costly and difficult. And so if doctors or data scientists want to look at patterns over time, if you want to create a seasonal forecast that says how big this year's flu year is going to be and how many extra nurses we need to handle the fact that, like, we're getting a surge in the ER, you need forecasting models, which requires longitudinal data, and that data is difficult to stitch together. So Every time you encounter difficult problems, what's kind of fun about working at a children's hospital is in the US you don't have competing children's hospitals. Like, we don't have a National Health Service like the UK or anything like that, but we have, um, in the adult healthcare system, you will have a little bit of market competition between similar hospitals in the same geographical area. That's not true of pediatric hospitals. There's usually like one for the state or one for many states. And so pediatric hospitals will talk to each other and be like, All right, how did you guys tackle this? And so it's kind of this informal peer network. And that's been really fun for me as a data product manager because historically I've only gotten that through my friends like yourself or Nick Zervoudis or other like data consultants or product managers. The few of us who are out there talking online have been my peer network. And so now I have a little bit of this peer network, non-competitive built in, which is kind of fun. But that's what I want is I don't, I don't want to hear in the abstract. I don't want to hear your theory. I don't want to read some giant manifesto. I want to hear Last month we had to build this customer data platform for this specific campaign, and here's how we handled the ETL augmentation reverse ETL pattern, and these are the problems we encountered. I want to hear that because that's what I can take back to my team and go, hey, we're tackling a similar problem. This is how this company did it. And you don't get that in books. The books are too theoretical. And so there's still a useful reference. I feel like if you're a new product manager, I would love to have a handful of books to to be like, read this, listen to this, like the Marty Cagan for software product management. I want like something like that. But the content I personally am most interested in is podcast conferences or like Discord servers talking to people about like the nitty-gritty of the job.

Yeah, I went to a Data Mesh Live conference in Antwerp last month, just because I've never been to Antwerp. So, you know, pick a conference in a city you've never been to and treat it as a work holiday to a degree. What surprised me, so there's over 150 people there, and what surprised me was I kind of thought data mesh was dead, but there were practitioners there and they were talking about real use cases. There were one or two fluffy corporate, you know, here's our journey stuff, but the majority of them were hands-on, talking about data contracts, the standards around that and the data product standards and how they implemented them and how they layered their data products from source to aggregated to consume ones. And so it was really, really hands-on, not hands-on, but it was really, really practitioner level stuff, which I enjoyed because it showed what people were doing and I learned from there. Um, so let's, let's see what we get in terms of questions, right? Um, so yeah, Chris, Chris Gamble saying Practical Data Community, that's great. If everybody wants to, uh, talk to data practitioners, hop on there. If you— yeah, um, there's a lot of us there. It is relatively unhinged, I will quantify that, that, uh, qualify that. You know, it is— yeah, it goes all over the place, so you have to be willing to, uh, to live with that kind of culture. Um, but it is a good culture in my view. So it's free, hop on and do it. Johnny Winter said, wait, data mesh is still alive. Ah, yeah, so yeah, the key thing I got back from that conference is it is. Yeah, there are, especially in Europe, practitioners taking the 4 principles from the book and focusing on executing them and then sharing their knowledge. How, you know, federated data governance was probably still the weakest of the 4 pillars, because it is the hardest, right? They've kind of solved the source aggregated consume layered problem. I mean, effectively they've built a layered architecture with data products. I found that interesting. Again, reuse of the pattern. They're using the Open Data Product standard in terms of input ports and output ports, and that has given them a shared language. So they can actually talk to each other and deploy data products the same way. They're still treating them as containers. So that was interesting, although there was a mismatch of what lives in the container for a data product and what doesn't. That, that confuses— like, yeah, that kind of looks like a data warehouse pattern. One interesting thing is they were polite but negative about monolithic data warehouses. So that was kind of interesting, but we all do that. And then what was the last one? Product thinking. Yeah, there was a lot of product thinking in there. So yeah, you know, I wouldn't say it's dominating the world anymore, but I think the core patterns that were in the book have come out and kind of got a life of their own.

Yeah.

What about you? Do you see it much in your side of the world?

I see it less in the US. I definitely hear it more from my European friends. Um, but I don't— what I think is happening right now that is going to be very interesting for like the next 5 to 10 years is AI is changing how we work, uh, not just in data but across the corporation. And what's clear is like org design is going to be impacted, the roles we hire for impacted, how we collaborate is going to be impacted. And so, um, whether— and that will impact our data architecture and how we construct systems, right? So the The people are going to shift, and I think no one knows how this is going to go. I think it's going to be very interesting to be like, what emerges from this? Does data mesh take a new flavor where it's like we have these micro domain warehouses but a centralized metadata store that helps with retrieval of the context, and then you go find the data you need and construct it? Will we lean even more into centralized because AI makes it easier to port the data and bring it together and mesh and do all the things we want to I don't know. I don't know how it's going to evolve. But what seems very clear is like, I think what we'll figure out first is like new roles will start to emerge. And then people thinking in these new roles and these new collaboration patterns, we will see architectures evolve. But I don't— I still see people favoring or it's easier on the planning side to be like, we'll get all the data in one place and then we have lots of options. Of what to do, where if you stay separate, it's harder to think about having ultimate flexibility or the ultimate— it feels like you have to coordinate more with people. People are always the hardest part of data. So, centralized data teams don't love the idea of like, well, now we have to trust those guys even more. It's like all of it has to ship together or it doesn't quite work. And so, I feel like the bigger the company is, in some ways, the harder it can be. But I, I also think leadership has to buy into data mesh and be very opinionated, like, this is the way we're going. And I often see enterprise architecture is quite weak in the company. And so that's not opinionated enough. And so the gravity and the vendors pull you towards centralized warehouse. So I think I have no idea where it's going to go, but I think it's really hard to fight for data contracts, decentralized data ownership. I'm trying to just get people to give me their column descriptions. You know, like, just like, can you write it down somewhere in any format, in JSON, in a database, in a spreadsheet, just something you consistently update every time you add a new column so I can pull it? That's hard enough. So like the idea of going even more intensive decentralized governance feels like a big lift.

Yeah, I mean, don't you just get Claude to write the column descriptions for you? Because that's easier, right? And then use Claude to read the column descriptions so that, you know, it talks to itself and there's no human in the loop. That's a triggering comment, I know.

My favorite thing is I've used these automated column description tools. I've tried this and my data governance analyst Cindy calls these cheeseburger definitions because they'll be like, what's a hamburger? I mean, a cheeseburger, it's a hamburger with cheese. You're like, thanks Claude, thanks for writing that. I could have inferred that in 2 seconds. That doesn't tell me anything. The real context people need is so much richer than that of like, you know, this column contains the medication codes, but the codes shifted in 1992. So don't try to do time series across them, then you have to normalize them. But if you're doing it at this time period, it's fine. Like that richer context, we are not to a place where the raw materials of that context are accessible to Claude yet. So Claude can't write good descriptions descriptions yet. Claude's perfectly capable of summarizing and providing good syntax. The problem is still that context engineering problem.

Yeah, and also storage. So, you know, natural reaction for me is to store that, that extended context somewhere else, right outside of the physical, physical structure of the data. But then, yes, as I'm building things now, I've got to get the GenAI tools to recognize, well, the structural context is here, and then the business context, that extended context, is over there. And now it's got to couple the two together, whereas if I take that extended context and I bound it to the physical stuff, it kind of sees it for free, right, to a degree. Um, so there's a whole lot of architectural decisions now about, well, and consequences. If I store it over there, it makes sense. I've got, you know, form of a wiki or context store or whatever. But now architecturally, I've got to make sure that whatever tool is using it is going to see both. What I say to people now is, um, reducing the number of uncertainties. So because we're all experimenting, because there's no good practice and there's no proven architectures. Everybody's pioneering and we're all learning from each other. Uh, there's too many moving parts. And so just pick some and make them certainties. Like, we're going to start off with a centralized data store, right, for now. We're not going to decentralize it, um, because that increases the complexity and the risk so much. And then we're gonna, we're gonna do this, and therefore the bit that we're not sure about is this space, and we have some hypothesis, and we're going to go test just that space, and we're going to try and make sure nothing else moves while we're doing it. And then you kind of, again, you're just Lego blocking, right? You're going, that worked, right? The other thing I'd say is don't say data mesh anymore, say decentralised. What do we want to decentralise and what do we want to centralise? Because that's the language that business leaders or stakeholders understand. And we'll kind of come back to language in a minute, but we've got a question here from Raul, so I'll read it out. I was thinking about data quality. I was thinking of using the TSDC 2.0 and its application data to data. What are your thoughts? I have absolutely no clue what that is.

Do you know? I'm looking. I do not, but, um, I think we can talk about data quality, uh, in general. Um, I, I'm on my mobile, so I can't pull up the link in a side monitor. I would say, I would— here's what I'll say. Where my, my head is at with data quality right now is a lot thinking about semantic data quality. Like, do we know what this word means? And do we agree as an enterprise what this word means? And if we finally have done the hard work of the enterprise of agreeing as humans, this is our common language, Is that version control stored? Are there systems to record that decision so we don't remake that decision in 18 months when we all come back or new people come back and all this stuff? And so I'm thinking about this a lot. I think, and part of it is the timing of my new role. I joined this company end of September and we got a new electronic health record system in March, which at a hospital means 80% of our data moved, the source system migrated. So it's a massive, massive disruptive event. But it also means it's an opportune moment to revisit like things like, okay, this new electronic health record says a visit, a hospital visit is X, or an encounter is X, but in the old system it was different. And then people have different conceptions in the hospital that those two things mean. And that affects a lot of metrics at a hospital because you care about visit volumes and admissions and readmissions and all these different things. And so we're having these like workshops, many hours with very expensive senior people deciding what these words mean. And I'm thinking, now where do I record that so that two different analysts in the hospital don't, six months from now, build dashboards that don't agree with each other and restart this loop again where leaders are going, wait a second, what, what are we saying a visit is again? And so like, that's where I'm thinking about data quality right now is like, meaning quality. And then once we know what things mean or what our target state is, then we can look at does the data match our expectation of reality. And then if the data doesn't match our expectation, I'm also thinking a lot about how the data team can ship data quality context back to source system to fix at the source rather than trying to just do analytical fixes for data quality downstream. So data quality has always kind of been— the idea of like automated data quality audits doesn't really appeal to me a whole lot because I feel like if no one's prepared to act on it, we're just spending money to discover problems in our data. So I've been working more on the business problems and expectation settings so we can do targeted data quality audits and having a plan structurally or with between these two orgs, because of course the source system is owned by IT and the analytical system is owned by data. So it's not just, can we surface the problem and pass it from this IC to this IC? We're saying, how do these two organizations now coordinate change across source and analytics? So I'm looking at data quality more from the ownership, like architectural pattern problem of how we're going to work on it. And then once we get there, writing the test itself and uncovering the problems is, to me, the easy part.

Yeah, because I'm doing a lot of work and, you know, we're building out a harness to help me do the data work a little bit quicker than I used to. And so it's all running backend in our product, but I'm using Claude Code at the frontend to help me kind of do the work. Um, and what's interesting is the amount of stuff it does under the covers without telling me. So one of the things, yeah, is like, I've got to keep telling it to— it's not lying, it's just doing it. Um, so some examples. So whenever we bring data into our platform, we automatically profile it. We have a set of profiling stats, and every row that comes in, every table, uh, as soon as there's a load, it gets recalculated. Um, but— and there's an MCP access to it and a bunch of APIs, so Claude knows that those profile stats exist. Yet actually, whenever it tries to do the work, it'll go reprofile the data itself. And I'm like, why, why are you doing that? Um, and then it does some really interesting things. Uh, so with one of my demo datasets, it recognized that, uh, Auckland had, uh, various versions at different cases. Um, so it right-cased it without telling me, like just did it. Uh, which is good and bad, right? Because it's— maybe I wanted the cases to do that. We're doing some work in the media space at the moment, and so you'll have a content title, you have a TV show and then you'll have a rerun of it where it's basically bracket R. And for our customer, it's really important that they get counts by first seen, by reruns, and by both. But interestingly, Cloud Code, first thing it did was it took off the Rs, said, oh no, no, no, no, no, you want to— and it didn't tell me, right? And so I think, you know, we've got to be a little bit careful about what the tooling's doing without us seeing it. And so Profiling is really good, data quality metrics are really good for it, but you have to make sure it uses it. And then I agree with you, actually, the biggest data quality problem is, you know, uh, what does it mean? You won't always use this. Renko Brockmans did some work for a hospital in the Netherlands, and, um, he had to get a definition of a bed. Um, and what he said was, you know, every— he thought this was going to be the easy one, but some of the organization thought it was a place a patient was. So it was effectively a room, and then the other part of the organization thought it was the metal thing that you lied on that they moved around. That was maintenance, right? You know, we're going to remove that bed and fix it versus how many beds do we have available. So yeah, I'm with you, it's the definition. So I definitely do data quality work still, but I wouldn't do it as a stocktake anymore. Yeah, that idea of going out and doing a data quality project, I would bake it in. And then the other thing that I would say is your data engineers are actually the people that often uncover the structural data quality issues every time. So they should be documenting those in a way that everybody can see, and then like you said, ideally pass it back to the system that owns the creation of that quality issue. But I really see that, I really see it going back into those sort of systems, especially in enterprise, right? Because it's just normally somebody else's software and it's normally too hard to configure.

Yeah, yep, absolutely.

All right, um, got another question from Ro. Uh, we had a major price structure change from usage-based pricing to a mix of usage-based pricing and subscription-based pricing. So the meaning— ah, confirmation with the leaders rings true. Yeah, um, because like you said, it's not only about capturing the context of those terms and those definitions now, it's also capturing the context as it changes over time. And then, yeah, we've almost now got time series data, time series business logic, and time series definitions, right? And they're all going to be moving at different times, and that kind of makes it even more complex.

Oh yeah, it's very, uh, you know, the one I'm really interested in lately, um, is the finance use case, which is Finance cares what the data meant at a point in time. And so finance doesn't, doesn't just care what happened in June. They cared what hap— what it looked like happened in June as of July 1st. They don't want to know what it looks like today, 6 months later. They want to know what it looked like on the day the books closed. They don't want any after— or they need to be able to look at both and see if there's a delta between the two. And so I'm interested in that problem because I feel like it's in that reconstructing what this table looks like before any changes happened after a certain time point, right? Being able to reconstruct the state of a table over time and not just the time period itself is a problem we haven't really solved for in the companies I've been working at. And the reason that's interesting is because it leads finance to do things in their own analytical systems and in spreadsheets because they can pull a timestamp and they know that dataset they've pulled is frozen. And if we don't solve that problem for them in the warehouse, they're going to keep building fragile quasi-data pipelines in spreadsheets or in FP&A tools. And sometimes those tools may be the right and appropriate way to do it. But the problem is it's often siloed and not documented and single point of failure and all the problems that we get in finance. And I just had this aha moment one day. Where I went, it isn't always just that they find the interface of the spreadsheet more pleasant to manipulate in, cuz of course they do. They, they pivot tables are very intuitive formulas you've memorized from years and years ago. But, um, you could buy a tool like Sigma and have the spreadsheet interface. The other reason they like it is not just the interface, it's the ability to control and to know the dataset they're using is frozen at this point in time that they care about. So we either need to do snapshots or we need a way to ad hoc reconstruct the state of a table at a point in time. So I'm very interested in that problem space because I feel like it's not talked about enough. And finance is, you know, if there's both a domain we never want to touch as a data team, it's finance. And if there was a domain that's the most valuable to the company to be correct and reliable, it would be finance. And so I'm very intrigued by the finance use case. I'm not going to say I've solved for this problem, but having the awareness of like, why is it so hard? Why do finance teams so resistant to using the data platform? Why are they still doing things in these what feel antiquated ways? And then I realized it's because we're not solving one of the biggest problems for them.

Yeah, there's, there's the pattern of bitemporality. So you see a lot of that in the European data platforms that have been built because they go to that level of complexity basically. And so it allows you to say what does it look like at the date it happened, what does it look like with today's structures as that date, and then what does it look like for the data that happened based on any other structure. Um, but that's just for data, right? That's quite complex to build. And then it gets worse, you know, as you said, you've done a data migration to a new platform. So when that data comes in, it's like, is it the date that the record was created in the new system? Probably not, because it their business effective date for that record was probably years ago because now it's a migration. So that, that's a really complex problem. But then we overlay context to it. Okay, what was the definition of that, you know, margin on that date? And what's the definition now? And, you know, do we want to be able to report the definition of margin as it is now for that data and as the data today is at the definition back then, right? So you're it's the kind of like a 3D matrix now, where, you know, it's more than just the data that's going to have temporality. Yeah, or temporal.

The other thing that I'm very thinking a lot about lately, we just went through a data catalog vendor evaluation because we're up for renewal with our current catalog, is like, if you think of a catalog as the catalogs role is expanding in the state of AI, right, as catalog becomes a source system for context, not the source system, but a source system for context. And how does that interoperate with the other places context is shared or created? So we've been talking about, you know, how will this interact with the semantic layer downstream of it? You know, the catalog becomes the source of truth for like this definition of visits and encounters working out of the hospital right now. Once we decide this, we will document this, right? And the definition and where it lives, and then the canonical calculation downstream, which will live in YAML, or, you know, all the things that we need to do. But the interesting discussion I had with my boss maybe last week or the week before was, you know, the hospital, it's really interesting to have one source system that's so dominant because you can go really deep on like, how does this system evolve? Where usually we're juggling so many systems in like my prior role, you know, like dozens of integrations that we're like, we never have the luxury of going deep on any of them. But at the hospital, 80% of the data, it's like, how do we get this really, really right? The way we bring in data from the system. And since the system is brand new, it becomes a really interesting moment of like, we don't have a bunch of how things changed over time in the system because the system only existed on March 1st to now. And so we have this opportunity to be like, how are we going to manage this system effectively? And one thing I've been talking about with my boss is, what if the catalog isn't just where the data team stores, or the catalog in the broader context system, the catalog is one hub of it at least. And then the semantic layer, the YAML by the warehouse is another. And then the EHR's own context layer is its own knowledge base as part of it. But what if the team that designed the workflows in the catalog, right? And sorry, in the EHR, when they design it, they're talking to the same stakeholders we're going to talk to for analytics being like, how do you need this workflow to work when a patient comes in for surgery and you're going through these fields and you're doing all this checking? We are later going to go try to make sense of that data and need to know what the trade-offs were, what the mental model of like the medical assistant doing the check-in is when they're filling in this field. Where there's validation, where there's not validation. There's like all this context baked into the design stage. And that again, like I said, sits in IT and we sit in data. And I was like, what if, what if we had a system where as they built it, they're, you know, recording these context gathering sessions and having AI summarize, you know, all this context that's learned at the time and contributing that to our, our knowledge management layer and then the actual design How are they documenting what the system is? The screenshots, the fields, this is happening here, this is what you need to know. And then when we go to create analytics, before we go talk to those stakeholders again, we can have our Copilot or our Claude or whatever tool it is access all of that documentation from the source system team to say this is the meaning of this data, it lands in this table, this is where you can find it, and then we're going to the stakeholder being like, all right, so I understand when someone comes in for surgery, the medical assistant is doing X. What I don't understand is how this works here, or before this electronic health record, how did it work in the old system? And we're gonna have to figure out this historical problem. So I'm really thinking about how do we close the, like, tighten the feedback loop and the context sharing between source system maintainers and creators and the consumption, because they both need the same context, and it should be a shared, connected system. So, that's what I'm really excited to, like, try to pick apart and solve this year at the hospital, because I'm like, why are we going back and having 6 hours of workshops again with these stakeholders to figure out their business context when someone else just talked to them about it 3 months ago to build the system? Like, that doesn't make any sense.

Yeah, it's the same thing because Johanna and I are writing a book on Modeling Business Concepts, and one of the things we came to is when we're talking to subject matter experts, uh, we're having a conversation and we're summarizing it. We're effectively sketching out a conceptual model as we talk to them. What we're not doing is actually recording the conversation, so we can never go back and replay the conversation to see whether we got it right or not. And so when you said summarizing the transcripts, I'd say keep the raw transcripts because I think you're going to need to go and replay that that raw data, that raw conversation, different ways when things change or when you don't understand them. Then the question is how many people are willing to have their knowledge and their wisdom documented? Because basically a lot of the time that's their value to an organization as a subject matter expert. But I want to come back to this idea of catalogs because what I'm seeing is, you know, it's all evolving and we're not quite sure who's going to own the context plane or whether it's going to be a certain type of vendor or a certain vendor Like, it is a race. I definitely can see some patterns. So I can see catalog-centric patterns, um, I can see platform-centric patterns, I can see BI semantic metric layer-centric patterns, I can see wiki kind of centric patterns. Um, so yeah, what's your view? Like, did you go catalog because you had one, you've got funding for it, it makes sense to carry on there?

This is so interesting. Um, I probably shouldn't name the company, but, um, my daughter, my 10-year-old daughter has a friend, and I was at the pool with her mom, and her mom works on a governance team at a tech vendor. Um, tech, not vendor, tech domain company. And I work at a hospital, so very different domains. We both work in data and governance, and so it was really fun to be— our kids played in the pool, we were like talking shop and we were talking about catalogs because we're both currently on the same catalog who shall not be named. Big legacy player, you can probably guess. And both of us are likely leaving that. But I work at a hospital that has a very concentrated, smaller team. And she works at a, we'll call it an IPO'd tech company that's mature. And so the talent density and, you know, the bandwidth they have to handle things is different. And so when we evaluated build versus buy, which is really interesting in the catalog space, because historically you may not even evaluate build, right? It was like, which of these vendors are we going to go with? Not should we even have one? And I would say this is the first time I've been in a company that was like, are we ready to maybe just, you know, do YAML and code and like do these things. Anyway, and her company decided they were ready. And so they're building something custom. Her platform engineers are building this semantic context layer, whatever they're building, they're ditching the catalog completely. And our discussion at the hospital was like, we have too much volatility with this sort of huge source system change. And our engineers need to focus on this core other stuff. And we did not have the bandwidth to build this, the functionality and the way I broke that down is we— I, I guess this gets back to more like how the product manager approaches this differently than maybe like an architect or an engineering leader would, which was what are the jobs to be done that we want from a catalog? What's our catalog currently serving? What's our ideal state of what a catalog would serve? And it's like it's a discovery plane, it's a system of record for meaning, it is a governance platform for sign-offs and approvals. It like has these different functions. And then we looked at the various vendors and which of those features were jobs that we absolutely had to have done and which were nice to have. And what we kind of decided was to build the minimum viable functionality was more of a build than our team could do right now. There are parts that we could do, right? We could build the semantics, we could use Unity Catalog, we could use YAML and Git repos. There's things we could do, but it wouldn't cover enough of the job. So we decided to continue with a data catalog platform at this time. And what's interesting is I don't know what that will look like in 3 years, right? But right now it's the right choice. But like you said, when I thought about this, the other thing that I'm starting to see, you said you can build context at these other layers. The problem is with some of these layers, like building at the warehouse layer would not work for us because the warehouse layer only covers metadata for objects that exist in the warehouse. And we care about objects that exist outside the warehouse and we care about— meaning systems that aren't yet ingested as well as like objects like glossary terms and things and like Unity Catalog is just going to provide metadata on the table, the physical objects that are in the warehouse. Similarly, semantic layers or BI layers, some semantic layers like dbt semantic layer, the analytics engineer is codifying context in that semantic layer. But I don't want my analytics engineers in all those discovery calls for hours and hours building conceptual models because that's not an effective use of my limited engineering time. So my product managers are doing concept modeling and just artifacts and recording these calls and summarizing them. And, and so the moment the tooling supports only the personas who are further downstream and they don't support upstream enough. And so I'm like, well, that's a nonstarter because I don't buy into the assumption that Or they buy into the assumption that the decider of meaning is an engineer, not a business user, right? And so I'm like, no, my engineers should be surfacing their hypothesis of this is what I heard, is this correct? But a human— and so they're too technical, they don't have enough of a UX. So to me, the catalog still provides a meaningful interface between those who decide what things mean, and those who document meaning and version control it and iterate on it over time. And so I think catalog is still sticky for that reason. And I feel like a lot of BI vendors and warehouse vendors and stuff are making some pretty big assumptions about what context needs to be gathered and which personas need to care. And so to me, I have no interest in them because they've made too many decisions for me and it's not flexible enough.

Yeah, and it's interesting just that journey you went on. So there is the pattern of team design. So how's the team designed for the data team and the organization? There was a pattern of the information value stream. How are we actually going from problem statement to build design and to value? What are our personas? What are their skills? Where does the job— jobs to be done, where should that job be done? Therefore, what technology or tooling helps those people get that job done? And they're all decisions that you actually have to use before you then decide, I need this technical thing over here to do this bit of work, right? Whereas if you look at a lot of organizations, they, they just go straight in, you know, it's, it's a technical person going, oh, we need a data catalog, or we need a BI semantic layer, um, because they do a technical architecture up rather than, you know, all these different patterns. So I'm kind of always intrigued when I ask people how they make decisions, um, which answer I get back. Um, and we are in we are in a time of change. So right now, no choice is safe because, you know, like you said, in 3 years' time, who knows what it's going to look like. So again, you've got to, you've got to pick a horse and then execute it because you can't sit there worrying about the change that's going to happen 6 months' time.

Right. The thing is, those vendors need to know that that calculus is changing. Like, it's definitely overhyped, the death of SaaS. I have no interest in building every tool my platform team uses from scratch and maintaining it. What a nightmare. That sounds awful. I don't want to do that. But it does mean their pricing has to be competitive, or I'm going to get the question from my execs of like, oh my gosh, half a million dollars? Can't you guys build something for like half that at least? You're like, yeah, I guess if you want to hire someone and it's their dedicated job to build this thing, we can. So I think there's a lot of pressure coming on SaaS companies to make their products Um, the ROI is so obvious and so genuinely useful. And gone are the days when you can provide this software that like does one job to be done and it's like good enough and we're gonna just keep renewing. It's like the ROI needs to be there, the stickiness, the user friendliness, the things where it's like, oh my gosh, to create something this fully featured that solves all these problems for us, no way we could build the bare bones solution. So I feel like It's going to be very interesting to see how SaaS vendors, both their pricing side and their discipline around creating really, really good products, changes under this pressure of like, well, we could just build it ourselves. If we want a really crappy data catalog, we'll just go build our own crappy data catalog.

Yeah, they're going to get squashed, right? They're not going to disappear, but the platform players are going to eat a lot. Like you said, Unity Catalog, those kind of things, they're getting better, right? They're starting to take that space. I'm definitely seeing in smaller teams and certain types of organizations, depending on the culture, the team topology, the value stream, they're building rather than buying now. That's a cultural decision. I'm with you, right? Sometimes costs more in people time, but that's seen as free. There's also the threat of, you know, a lot of leaders that are tech savvy now are just vibe coding it and saying, "Well, I can't use that." But it comes back to, like you said, you know, is it valuable? Is it viable? Is it feasible? All those magnifici lenses. And, you know, what's interesting is, like, I was just building out a cut of a data dictionary screen for us right now, just to iterate and make it a little bit more usable for when I use it. And, you know, the first cut of it was really quick. It did exactly what I wanted. And then I went into this deep window of time trying to make it beautiful because, because I care. And, and it just wasn't right. I was like, it works, but it's ugly. And it doesn't matter what I'm doing to it, it's still ugly. Um, and so I think you're right. I think the, these companies that have that wow moment, that they have that magic, uh, they, they will be the ones that survive better than, than all the others. Um, all right, we've got some more questions. Uh, one that came in through LinkedIn was from Tim Fraser, who was the first awesome foursome on, um, he said, what's the single most important skill to learn today in the data work that didn't exist 5 years ago? What do you reckon?

Uh, I think it's like the becoming meta skill of like, um, being literate in what AI is capable of as of now, right? And what's required to get the results you want out of AI. Right? What's required from you as the user? What's required of a less skilled user? What's required of the system? How do— when do you need deterministic? When is probabilistic okay? Like the ways of like thinking about what it means to integrate these tools, not as a personal productivity tool, but as part of a system is, is like the thing I'm thinking about the most and the skill that like data people need. And so I feel like it's interesting because you— all the hype on LinkedIn is heavily skewed to solopreneurs, consultants, a certain type of person. Well, in an enterprise, I don't have a choice of like bring in any new startup cool tool. I don't have— I live— I'm a regulated hospital. I use what IT lets me use. So I use Microsoft 365 Copilot because that's what is authorized. So how do I get good results from that tool? Or, or what are the limitations of that tool? And when might we need to fight for something different? And like, how to think about the limitations of AI and when to reach for AI and changing behavior? And how do you change your team? How do you upskill your team's mental models? How do you upskill Okay, yes, you can have this written, but then we still need code review. You can't just auto-push it. Or yes, you can use it for like you— architecture review becomes even more important before you throw agents at it. We need to make sure your instructions aren't just good for another developer. They're good enough that when you give them to a system, like the nature, the flavor of the code review is like Claude's not going to understand this because Claude doesn't have the context, let's improve this requirement, or let's improve this technical design document. So I feel like how everything is changing when you make assumptions that an AI collaborator will be part of the system, like that's the, that's the skill like that I don't— those of us who are early adopters or those who are working in a solo environment where they control the harness, they control their machine. Or you control this whole stack that you've built, right? So you can make sure it all interoperates and works how you want to work it. That is great. And all of us should be trying to optimize our personal environments and all those things. But that's completely different from how is our whole organization going to evolve to use AI? Is it ready for us to use in this way at this time? And if it is ready, what needs to be true to do that responsibly and reliably and all those things? That's the meta skill to me that it's like The laggards, I worry about them. I worry about the people who are just still showing up and doing things the same way they were doing it 5 years ago. I'm like, you're— I do not want to be— I, I don't want to see you lose your job because you're not staying on the edge. And the edge now means rethinking the whole way we do things.

Yeah, I thought about this one because I got to see it before you did. Um, I'm not sure these new skills to learn, but I think these skills that we need to double down on and improve. Uh, so I thought about, you know, as you were talking, uh, the, the skill of experimentation. Yeah, because actually the only way right now, if you want to stay in this game at this early stage, uh, is you've got to be able to play. You know, you, you— I did it with a personal OS, you went and did it with the, the, um, app around your garden, but by, by building something in your spare time, you're learning and you're experimenting. I think we, we need to understand systems thinking. Like you said, I can change this little bit here, but actually has no impact because of all these other things. I think we have to understand how humans work. What I'm finding is in my harnesses, I'm more and more treating the LLMs like agents or employees, like humans, and I'm giving them personas and policies and ways of working because when I lead teams, those things worked, right? We have to-dos and doings and dones, and we keep track of them because as a team it was easy to see what people were working on quickly by doing that. I'm getting the, the LLMs or the GenAI tools to do that now. So this idea of how do we scale, how do we scale people and teams, is now becoming more important as we scale the technology. Um, and then recognizing it's bounded by context. You know, if I'm in If I'm working in a hospital and I have a framework where I talk about ask AI, assisted AI, and automated AI, I would not put automated AI in there right now. You know, there is no way because the impact of getting that wrong is a bad thing will happen to a human. Yes, exactly. If I'm building a demo system, then yeah, I can put it onto auto mode and see what happens because the blast impact, the bad impact of if I get it wrong is minimal. And so I think that context is really, really important. Context of the team and technology, like you said, you know, we, when we're independent, we get to play with the cool tools because it's our choice. When we work in large organizations, we follow the architecture and the architecture is there for a reason. So yeah, I think, I think one of the key points you pulled out is if you're in the data space and you're watching all this cool stuff happen, It's because there are people lucky enough to play in these isolated environments and do these things. And that's not the mass of the people in the world. But yeah, I think you still got to experiment. I think you should go and play with some things at home to whatever level you can, because I think learning and keeping up is going to be really important. I think we've seen that already.

Yeah, and I think you can, you can find, like, as a leader, you also have to say, how is our team going to start to experiment with this in safe ways. So something I am not hot on until our context layer improves is natural language to SQL because we don't have enough structured context for me to know that that executive is going to get an accurate answer every time, right? Um, but I am very interested in text to SQL for the analysts on the central data team. So our central data team at the hospital was working on Business Objects, right, under a different paradigm. And now under our new, like, lots of drag and drop configure, lots of I'm a subject matter expert and I know how to construct a report. And now we're moving to an era where they're going to need to know more SQL and how to work with analytics engineers and how to pull context anyway. So it's just like their job has shifted a lot. Some of them are already strong in SQL, some are still developing, and basically the requirements of the job have shifted a lot. So I'm interested in the idea of like, how does an LLM— like LLMs are amazing at writing syntax if you can give them enough context. And these analysts have all the business context and even knowing what's in what table, right? That's where their expertise currently is. And so it's like, am I interested in building an agent for only that persona, no one else in the hospital, which is that behaves in a way that says, okay, I found these 5 tables. I think this one looks promising, and the analyst can go, no, I don't know, that's wrong. You know, like, where can their expertise show up? Sorry.

That's right.

Am I still live? Sorry. I had a little notification pull up that was going to mess things up.

That's right.

But anyway—

Yo, camera's up there.

I'm interested in that.

Your camera's off now.

Go ahead, go ahead, Shane, back to you.

Ah, okay. Um, oh, your camera is off.

Give me 2 seconds, I had some— yeah, I'll be back. Okay, I tried to like dismiss it, something stupid, so I'll be back in a second.

All righty.

Wait, anyway, you go ahead and talk for a minute, Shane.

Well, that's okay, we've only got a couple of minutes before we have to close it out, so leave camera off, that'll be, uh, That'll be fine. I think there are some patterns out there that are hard to find but are highly valuable. So that example you use of text-to-SQL, I agree, right? If you're in an organization where people need to trust the numbers, I don't think we've got the tooling yet that gives us that trust. But one of the patterns I've seen work really, really well is we can create a list of business questions that we know get asked all the time. We can create trusted queries or trusted dashboards or trusted reports that answer those questions and are curated. And then we can give an interface where people can type in a natural language question and it comes back with the curated questions that are close to what they're asking. And then they go, oh yeah, that one. And when they click on it, they then get the deterministic run, right? The SQL runs or the dashboard comes up.. Now, is that the magic, you know, ask any question of any data and get an answer? No. But is that a starting point? Is that a good way of experimenting how your stakeholders and your users, your information consumers, are going to start engaging? Like, will they actually use that, or will they go, that was a great demo, now let me get back to my day job? We had that with self-service, you know, this idea that back when we had OLAP cubes and we had Business Objects, it was like, everybody's going to write their own report. The number of times I worked with frontline staff and they said to me, I don't want to do that data shit, right? That's not my job and I'm not interested in it, it's too slow. I just want to know the answer to this question because I've got an angry customer on the phone, right? Like, what is the delivery date of the order? I don't want to have to drag and drop something. I just want to go, what is the delivery date of the order? And then carry on with my job of making that customer happy. So I think again, this is this ecosystem of people like us in the data world that get to explore, and then the ecosystem of data people who think everybody wants to do the job that we do, and then the people out there that actually just want data to help them take an action and achieve an outcome. So I think we've got to be really clear about where we sit in that continuum as an organization.

Yeah, that's what makes me really, um, I think self-service is really interesting in the future of, of a data products universe. Like, take that customer service example. If we know based on, you know, 10 years of data service ticket, like Zendesk tickets or whatever, the typical questions that are coming in and the data assets that those customer service agents need at hand to be able to answer questions like, has it shipped yet? When is the ship date? You can build a really good data product that has authoritative answers to those questions and all the semantic context and everything the agent needs. And then you can put a natural language interface on top of it that is literally just their ability to ask and even have shortcut questions. Here's a customer number. What do you want to know about that customer? You know, the order number. Or here's the answer. I already know you're going to ask one. Has it shipped yet? It hasn't shipped. It's due to ship tomorrow. And like, so is self-service really promising in a data product context where you're like, yes, this self-service point works for this user persona who has very frequent needs, very predictable, and I'm going to build a data product behind it that has enough documentation. Yes, I'm very hot on that idea of self-service. I'm not hot on the idea of like, I'll have all of the data products and my users are going to want to go in and pick the table and slice and dice it and come up with their own answers. I'm not— that is still quite far away until what Databricks wants you to think, Databricks Genie, or Snowflake, I can't remember what they call theirs right now. This idea that user can show up and ask any question and we can find an authoritative answer, that's a ways, that's ways away in my mind.

Yeah, and it comes back to what action and outcome does the, the information consumer want to use. So in that contact center, like, we should know that the person who's ringing has an open order. And like you said, we should know historically the majority of the people that have an open order and ring up at this time are asking for delivery information, and we should make that information usable. And wherever the, the contact center person is, it should be in front of them, right? They shouldn't have to go click 5 times to get there. It should just pop up and go, by the way, delivery date was last week. You know, that's, that's enough to know that the kind of call you're getting. Um, so yeah, I think, you know, that product thinking is still, um, uh, a long, long way away from what a lot of data people are doing. Um, and yet then we try and just double down on the new cool tech. So I think it's valuable, right? Um, but, but we're early, we're early in there. Excellent. All right, well, we're almost out of time.

Um, well Hopefully this was useful to somebody who's going to watch it. Shane, I thought it was interesting to talk about. We hit a lot of things. We hit context, knowledge engineering, data products, product practice, self-service. I think the takeaway from today is just like a lot is changing systemically. I think data practitioners need to think in systems. They need to experiment and they need to They need to talk to each other. We have to learn from each other. I think it makes things like content like this or podcasts or videos or going to conferences, like you've got to talk to other data people who aren't at your company. Because hopefully you're also talking to the data people at your company, but not at your company and figuring out like, how are you tackling this, Shane? How are you tackling this context engineering problem? Are you guys building your own catalog? Like I said, I was at the pool with another mom and she's like, oh, we're building our own catalog. And I'm like, tell me all about this. Like, we, we have to talk to each other because there's too much experimentation to be done and we should be learning across companies and not only within companies.

Yeah. And the good thing with the Aura sessions is we get to catch up on— for you and me, it's the third Friday of the month-ish, depending on how our schedules look. So if anybody's got a question, just and they're watching this, just type the question in the Substack article, uh, send us a note on LinkedIn, right? DM us. And then we, we talk to enough people that we can actually go and talk to some others, uh, between you asking that question now and us coming back on, um, and maybe come back with an answer from a couple of people and say, you know, we talked to some people and they were doing this, we found that interesting. Or as always, hop on the show itself and ask us a question live, and if we can, uh, we will, um, If, if like Raul, you've got, uh, a link to a product or a piece of technology or something, uh, maybe, yep, give us a bit of a heads up so that we can both go and do a little bit of reading before we're there. We may have heard of it, uh, and we may not have, but I'm definitely going to go and look up that one now because I'm kind of intrigued. So, uh, yeah, that was great, but thank you, and we'll see you in a month's time.

All right, this was fun, Shane. Have a good afternoon.

Bye.

Okay.