← The Analytics Power Hour
The Analytics Power Hour
#273: Data Products Are... Assets? Platforms? Warehouses? Infrastructure? Oh, Dear. With Eric Sandosham
01:09:39
Is it just us, or are data products becoming all the rage? Is Google Trends a data product that could ? What actually IS a data product? And does it even matter that we have a good definition? If any of these questions seem like they have cut and...
Loading summary
Transcript165 lines
- [00:06]
Tim Wilson
Welcome to the Analytics Power Hour. Analytics topics covered conversationally and sometimes with explicit language. Hi, everyone. Welcome to the Analytics Power Hour. This is episode number 273 and I'm your host, Tim Wilson. You know, we occasionally get asked how we decide which hosts are going to be on any given episode, and our process for that has varied over the years. One of the considerations is ensuring that we're keeping kind of a reasonably balanced rotation of different co host combinations. There are like various other considerations, more than you think. We're not going to go into it, that sort of prevent us from having a strictly formulaic process. But for the rotation tracking which co hosts are on in any given episode, I built a chart that automatically updates, that visualizes the frequency of different combinations of co hosts it dynamically updates, but it's all within this, like, highly sophisticated platform called Google Sheets. It's kind of a unique chart. It's a derivation of what's called an upset chart, which I'd never heard of until I was trying to figure out what visualization to use, but it turned out to be pretty useful. So does that mean that I built a data product? I mean, it's just one chart, but maybe I did. Maybe I'll know one way or the other by the end of this episode because the topic of this show is just that, data products. I'm joined by a couple of co hosts. Val Kroll, what's your initial reaction? Can a single chart be a data product?
- [01:41]
Val Kroll
I cannot wait to get into this because old Val would have said, no, it's just a chart. But I feel like, I feel like we're going to change challenge that on this one.
- [01:50]
Tim Wilson
So maybe it is, oh, the perfect, ambiguous, ambivalent answer. And we're also joined by Mo Kiss from Canva. Mo, what say you? Can a single chart be a data product?
- [02:03]
Mo Kiss
Well, also, I've been having this exact discussion with my team over the last week, so I think, I don't think I have a strong opinion yet. But let's, let's see where I land.
- [02:14]
Tim Wilson
All right, well, by the end of this show, I'm expecting us all to have a definitive answer one way or the other. Otherwise we really whiffed on our guest. But I know we didn't because we have had Eric Sandersham, founder and partner at Red and White Consulting Partners on the show before. Way back on episode number 254, he was on for a lively discussion about benchmarks. And turns out that it was Mo, Val and me as the co hosts for that episode too in addition to his consulting work, Eric is on the adjunct faculty at Nanyang Technological University, Singapore Management University and the Wealth Management Institute. We're actually capturing him right mid two day session with the Singapore Management University. So he has been talking a lot yesterday and he'll be talking a lot tomorrow. He was previously the Customer Intelligence Practice lead for North Asia for SAS and before that was the Managing Director, head of Decision Management and at Asia Pacific Consumer bank at Citibank Singapore. And he's now well into year two of publishing a weekly article on Medium about data and analytics. I look forward to reading each installment when it lands in my inbox every Saturday. But one of those recent articles was about Shocker data products. We're excited to have him back on the show, so welcome Eric.
- [03:36]
Eric Sandersham
Thank you. Thank you for having me back. Yeah, it was a real pleasure.
- [03:40]
Tim Wilson
Also say that it is early morning for Eric as we're recording this. He said that was fine, but I'm wondering if that was. It sounded fine when we were scheduling it and now if he's second guessing.
- [03:53]
Val Kroll
That decision, he'll still be here for some hot takes.
- [03:57]
Tim Wilson
Yeah. So Eric, in that Medium post that I just referenced, you started off by trying to put together kind of a reasonably tight and clear definition of what a data product is. We already covered that. Maybe we're not all that clear. So maybe we can start there like where you landed. Maybe what you found problematic in some of the other definitions that you found.
- [04:22]
Eric Sandersham
The article actually started in a casual conversation with a sort of a house data lake person. Right. And this is before, even during my time in Citi. And from an infrastructure perspective, they will say, how can we up our game? How can we provide more value, more utility? Can we create products? And I suppose it also fits into thinking about this space in IT and Data Warehouse. If you think about the role in Amazon, for example, in aws, they call themselves engineers. So they are making stuff as opposed to in my time, when I grew up, it was it. We didn't refer to them as engineers and nothing wrong with that. Right? So organization. It got me thinking, do you really have products? If you're part of infrastructure, your role is sort of managing data and all of that. And even then, if we flip it to the front end, if you're a data scientist, are you truly making products or doing analysis? If you're building a predictive model, is that a product? And then it sort of got me into a little bit of a rabbit hole and I realized at the very core of it is this lack of clarity between what would seen as a product versus a feature, even in the physical world. Actually, maybe less so in the physical world because you can touch and feel something. It's a chair. But if I took the chair and I had to replace the legs, for example, and it's not bespoke and it's part of a modularized kind of chair, would that be a product? Like a chair that could be swapped out and so then would that be a product? I think most people said the entire chair should be seen. Maybe those are sort of components to it. Right. But once you get into a virtual digital space, where do you draw the line between something that's physically whole versus a component? Right? Because you can, you can disambiguate almost everything at atomic level. So that then I realized, oh, actually maybe that is the central challenge in the digital space and the virtual space because you don't have this clear distinction between when the product ends or when component begins. So I sort of just took a crack at it myself. From a data practitioner perspective, could I put forward perhaps a much clearer definition? When I scoured Internet, I found some. Two opposing kinds of very. On the extreme end, which I, which I sort of highlighted in the article. One being that if I'm creating some sort of, you know, marked up meta tag table, right? So if it's a, and for lack of a better term, just call it, let's say a database form of database that's referenced and all of that, it's a data product because someone can use and it's curated, it's put together, it's organized and all of that. Great. Then on the other extreme, what someone would also define as a data product is a tool or an application that's processing the data. So I throw some data into it and it spits out some kind of output. Both are fundamentally different. One is a processor, one is an ingredient in a sense of a database. And there was no hard and fast to say which should or should not be a data product. So I was eventually quite fascinated and say, why is there even a need for this term? Why can't we just say the data processor? It's a database, right? Yeah.
- [08:21]
Tim Wilson
Well, if you say data processor, then you wind up in European privacy regulations, right?
- [08:26]
Eric Sandersham
Because there's took a stab at it and said, well, if we define a data product, maybe it had to have these attributes, at least for me. One, it uses data. And data assets in my view are fundamentally different for just data because there's a sort of intentional curatedness to that it's curated data, it's identifiable and reusable and it has its specific utility that this data product of solving or reducing uncertainty for decision making. Right. So if it's just there and it doesn't do anything to fix someone's decision making, then to me, I don't call it a data product, but by making a definition and because of this discussion, I went back to reread the article and all of that, there are sort of a lot of definition because it suggests intention and purpose as opposed to, oh, I made some data and I threw it there. Let's see who can help themselves to it, right? Versus saying I built this for a very specific utility for a specific target audience to specific decision making, uncertainty challenge. And to me, perhaps then that would make a data product.
- [09:49]
Tim Wilson
Imagine this, your data instantly, wherever you need it. Like having cold brew coffee on tap. Ah, yes, data on tap. Giving you that little pick me up, that's the dream. But in reality it's more like data on hold. That is, until now. Fivetran already the kings of automated data integration, they just acquired Census. Yeah, that census, the reverse ETL pros, which means now it's all connected source systems. Check. Data Lake.
- [10:21]
Mo Kiss
Check.
- [10:22]
Tim Wilson
Apps like CRM and marketing tools.
- [10:24]
Eric Sandersham
Check.
- [10:26]
Tim Wilson
It's like your Data finally turned 16 and got its driver's license and stopped asking you for rides everywhere. With fivetran and Census, your data just works everywhere.
- [10:38]
Eric Sandersham
More insights, less waiting, zero headaches.
- [10:42]
Tim Wilson
Fivetran the only pipeline you'll actually want to maintain. Go check out their site with interactive demo demos and more@fivetran.comAPH Once again, that is F I V E T R-A-N.comAPH.
- [11:00]
Mo Kiss
Okay, so I've got to go back to an idea that you mentioned kind of at the start, but VAL started cackling with like, delight and I feel like I need to. I feel like I need to fully flesh it out so I can understand it. So you said that sometimes it's hard to know where the data product and the line is between it and the feature, right? And I love that chair example because I feel like that is such a, like, tactical thing that I can understand. Like the chair is the product, the leg is the feature. But can you give an example of where that line starts to blur and it's hard to know where the feature and the products start and end?
- [11:38]
Eric Sandersham
Because I'm just like, I'm trying to conceptualize history is all in banking, financial services. So that's, hey. And you know, in banking actually that to say, you know, financial products, the products are not physically real. What's a checking account? You never see, you can't touch and feel it, right? So most people say, well, the checking or savings are a financial services product, okay? But in that checking account you could do remittances. Right now in pre digitalization days, your, your remittance would say just be a feature of your checking account because you would have to call up, put out to the branch and wire money. Right? But then we introduced digital banking, mobile banking. Now mobile banking as a platform or application could arguably be said as a product. And within that digital banking product, you have the checking product that is enabled as a, you know, front end to it. But then within digital banking or mobile banking, you could do direct remittances and set it up, which sort of disambiguated from the checking account, obviously has to debit the funds from the checking account. But it could be argued as a standalone capability. Now in that context of a mobile bank, most people would say remittance, the remittance ability would be seen as a feature of functionality because you wouldn't have a remittance product manager in a bank. You would have a digital banking product manager, a mobile banking product manager that says, I want to now create more utility, more functionality for my tool or application. Remittances would be great. And it could reimagine the space of remittances that would have been different from how it would been done in the physical past. Right. When you get to that space. So is remittance not product? If technically you could make that argument, because it could, it could stand alone with its own capability taken out of the mobile banking now and perhaps monetized and white labeled.
- [13:57]
Val Kroll
I love, wow.
- [13:58]
Mo Kiss
Definitely more complicated.
- [14:00]
Val Kroll
I love these examples. And thinking about exactly what you were talking about as well, I was like, can't believe we're already getting into it that early into the episode. But I worked with, when I was in previous role, I supported at two different financial services organizations, a digital account opening team, they were called the DAO team was the shorthand. And it was not even aligned to products. So it wasn't just checking, wasn't just savings, it also was credit card and doing like those soft checks. And so it was the functionality of just the interaction of the customer in the site to even let you into talking with some of the. But that was like one of their largest digital product teams. So even thinking about how it cuts it sideways now and it's not just these nice little categories and thinking about what is the value, the business value and the utility of digital account opening separate from the features and the products that are, you know, that they're signing up for themselves. So I love, I love all the layers and complexity all that.
- [15:02]
Tim Wilson
Well, I mean, not to head down a side path because this was, this is because we've kind of shifted to talking about digital products. I'll throw in the example of like when checkout gets treated, it's a product. Like there, there'll be a product team that is checkout when they're buying products. I mean I was super naive years ago when I had no idea that there were like digital products and that components of an E commerce experience were considered products. I got into a fairly heated argument with somebody else who was completely right and I thought he was. That was the dumbest thing ever. So I have admitted that to him since.
- [15:41]
Val Kroll
More on that later.
- [15:43]
Tim Wilson
So I mean, anybody, if Ryan Garner is listening, I will once again say, yep, I was way on the wrong on that. But we've. Where there's, there's data products and there's digital products and arguably even that starts to be this kind of confusing. Like are we using digital products and trying to get definition around those as a way to get clarity on the boundaries around what a. I think there's some similarities.
- [16:13]
Eric Sandersham
Yeah, there's some similarity.
- [16:14]
Tim Wilson
Is that where we're heading or am.
- [16:15]
Eric Sandersham
I missing Unreal in the sense non physical. Right. And they are sort of understood in the utility. The digital doesn't. You can only understand this checkout process because it serves a particular right. Utility or functionality. Same like the data.
- [16:39]
Tim Wilson
So it's like obscenity. It's like obscenity. We'll know it when we see it. No, sorry, I'm not adding value here, but I'm like, is it a product? We'll know it when we see it.
- [16:48]
Val Kroll
Okay, so I have a way to help us get back on track, I think. Tim. So back to the Medium article, because this is kind of the connection point between the two. When I was first reading it, you had used an example. And if you want to elaborate on it more, I'm sure you'll do a better job than I will about the credit bureau. And I was like, okay, like I'm following. And you were talking about the different API calls and that the API itself was the data product. I'm like, yep, I'm following, I'm following. And then you talked about how it should be obvious that the credit score itself was a data product. And I Was like, hold the phone, hold the phone like a single number. And like my brain wrapped around and I probably just sat there for 10 minutes processing that one. But I was like, yeah. And I go, I went back to your definition about that it's an asset, that it's the curated data, that it has utility first. I'm like, yeah, it works. So anyways, if you want to talk about give a little to our listeners a little bit more of that example. I think that that's a really strong connection and I found it to be an amazing kind of way to.
- [17:48]
Eric Sandersham
I think most people what credit bureaus are, right? And at the heart of it, it's similar earlier definition of a data product. It's a database, right? But in this case it's a database designed for very specific target audience, for a very specific target functionality and all of that. And governed and structured. Yeah, right. To make a decision exist for you to sort of go and just sort of play around the data. And even in the Master Data Bureau you could only withdraw certain types or query certain types of information that's very much again aligned to the entire life cycle of how you would do underwriting and all. So it's not free for all and very specific, very curated and in many cases even transformed information. So it's not the raw form of the information, but they may give you counts like the number of times you've been delinquent, your leverage ratios and those sort of things. But they are sort of post computed in the credit bureau. Now one I think can make an argument that the entire bureau, it's a data product because it has a piano, it has a business model to it, they sell and they upgraded their versions and all of that. But then there are things within the bureau which could then be also bought off as products. So some of the examples I suggest if I had the bureau as a standalone itself and in the days before there were APIs these bureaus, the way you would have done it, you would have to send in a batch request and they could do a single pool or you could batch in hundreds of thousands and you would then wait for the next day or a couple of days later they will send it back this batch query. And that was just a way to formation back and forth. But now you could sort of do it real time, right. And that API with the database structures built intentionally for a specific use case and target audience, I felt qualified in my view as a data products, it is sort of coherent as a, as a single value proposition to give me quick and Fast access to information that I could use for underwriting. Right now, the bureau, over time, in many cases, started to offer additional services. Right. When we call those services products or not becomes the dicey piece. Right. So they could offer a report on market share, for example, that report could be, you know, something on something, you just lock in, view it, and then, you know, print out as a PDF or whatever, or even data is a market share report. Credit bureau a data product. In my view, I tend to lean, maybe not. And we can argue why. But then there's also, on the other side, the data processing definition. The bureau now produces a credit score. And is this credit score a drawdown? I look at it not the output of the score itself, but sort of the entire process of solving a specific problem. So the score required some engineering work, obviously to figure out whether the data was good, valuable, and those sort of things. And it had to be created in a put that could then be immediately used in the decisioning life cycle of the underwriter. So it's in fact almost. Well thought you didn't have to take the score and say, hey, can I take out a subcomponent? I had to do extra lifting and shifting just to make it work. For me, it became really a template in a sense. Right. And because of that templatized approach from start to end, I thought it was a product because now it could be monetized as an asset. Right. The underlying data obviously is an asset, but this core, which is now a transformed abstraction of those raw data, has a different kind of asset value and even arguably a higher value than the original data that it was built upon. And you could just lift and shift it, reuse it in different ways. So when I thought about that, I could say, yeah, it's almost. You could put your arms around it because in a virtual sense it becomes real.
- [22:55]
Val Kroll
It's a really good example.
- [22:56]
Mo Kiss
Okay, I want to take us down a completely different path. One of the challenges I found. So I've been banging on and thinking about data products for a really long time, and there's actually someone new on my team and she shared something with me the other day and it had this like this thinking about data products and I was like, oh, have you been like reading some of my old decks? And she's like, no. And I was like, oh, cool. Then we're just like super aligned. That's amazing. But one of the things that I've kind of experienced as like a bit of attention and I'm curious to hear your thoughts. The reality Is that all products now have such a big component of data that it's really hard to know where the line is. Of like, what is a data product that data folks own and build? And what is an internal product that is a big user relyer of data that should go to our product team. Because, like, I just feel like it's pretty murky because, like, especially when you work in marketing, you know, we have like these huge data sets. They're used for our decision making. And so naturally, anything that our internal product team build to serve, to serve marketers is going to have this big data component. And it's like, I sometimes feel like there is this like, push and pull of like, should it sit with a product manager and software engineers and like, do you embed a data person or is it actually a data product that a data team should build and own? And I just don't know where the line is.
- [24:26]
Eric Sandersham
Let's think about food, right? So let's say that that jar of peanut butter on the grocery shelf, right? Obviously once it's made peanut butter, it's quite clear as a product, you go, you pick it up and you check it out. But behind the scenes, the manufacturer of that peanut butter buys ingredients, buys chemicals and buys stuff. And those companies that sell to the peanut butter maker, in their view, they are selling products, they're selling ingredients, they're selling chemicals, right? And maybe the way we think about products is who's the buyer at the end, you know, because if we think about. And the maker of that data is so like, in this case, I say the peanut butter and you say, I grow my own peanuts in a field, I harvest them, and then I turn it into peanut butter. It's organic, right? From farm to table. Does that manufacturer think of the peanut as a product? Maybe not, because they own the entire thing. In their view, they only have one product which is making that peanut butter, because that's the thing that I eventually monetize. But if I had to buy it from a supplier, then the supplier is going to think of that ingredients as a product because I make money off and I have to figure a way to sell it at scale. I have to figure a way to templatize that whole process. And so if we are sort of thinking in the same data space and we are now sort of buying or ingesting someone else's data, then that data could be seen as a product that supplier provides to our process. But if we are internally managing our data lifecycle, should we think of that data as a product because we don't have a P and L attributable directly to it.
- [26:30]
Val Kroll
Clear as mud.
- [26:31]
Tim Wilson
I mean, I feel like, I mean I feel like, like there's, there's been another layer introduced there. And mo you kind of. That I think where you were heading and it goes back to what's the, what's a digital product? I'm using some online say presentation creation software and there is data that has to be curated to feed into that, to help me use that, to guide me towards how to use the tool better to recommend what templates I should look at or whatever. So there's data flowing into literally unambiguously the product, the digital product that the customer is working with. On the other end, there are data products that are. This is a data asset that is being curated and used to deliver to inform decision making. Like a dashboard to help somebody decide or I guess even, even the credit score. Like this is the data is leading to a decision. And then mo I feel like you brought in sort of a. And something that falls in between that a team is using it and they're saying we're making, we're doing personalized offerings to prospects or customers to cross sell them. And that is bringing in data that's being curated and modeled. A recommendation engine, but it's being used by an internal team. So maybe a recommendation engine isn't the right case. Part of this feels like, oh my God, is this like so academic that it doesn't matter?
- [28:21]
Val Kroll
What's the, what's the value of calling something a data product? I think we should touch upon and talk about that too. Or even moat like the example of if it lived within the data team, what would that mean different from if it went to a product team? Like if it went to a product team, does that mean that a PM is like looking over the roadmap and thinking of like feature enhancements and reduction of tech debt and thinking about extensibility to other teams. And if it was a data product, is it about enriching it and improving it and you know, narrowing the confidence intervals or whatever the goal of that product is like, and I'm obviously using some broad brushes here, but like let's talk about the value of why the name could be helpful or maybe harmful if that's the opinion. But like what's different from the other side?
- [29:07]
Mo Kiss
Okay, the thing that I have observed that I love about this whole concept of data products, I think it really shifts the role of data folks from being like a service function and tickets in Endura queue to really elevating our work and forcing data folks to think more deeply about how they're spending their time. And so what I mean by that is when you're building something, quote unquote, that you want to call a data product, you're normally stealing some of those things from the product folk you're doing. Like, what is the business problem we're trying to solve? Who is, who are our customers? How will we know if we've been successful? Like, you're really leaning on those just like that product way of thinking. And I think that's a really strong thing because you also give thought to like, how do I automate this? What is the type of debt we're going to incur? What's the maintenance for this? Like, and, and the effort we need to put behind that. And, and I, I think that's such a good way for data folks to think about their work. And also, just as someone who is going through this at the moment. I know, Tim, I know, Tim, you're really smart. It's in your book. I bought three of them the other day and gave them to the team. Wait, no, no, no, let me finish when you finish.
- [30:24]
Tim Wilson
But I have a counterpoint. So.
- [30:28]
Mo Kiss
What I'm saying. Yeah, but the, the thing that I find uniquely different as well is I think you have a more sophisticated conversation with your stakeholders because you can be like, here are the quote unquote data products or whatever you want to call it, big rocks, whatever that we're focused on for you. And I feel like you can make trade offs more easily than that. Like service function of like here is just an endless queue of tickets and a dashboard is another one in the, like the line. And I don't know. All right, I'm going to stop.
- [31:04]
Tim Wilson
Well, so let me provide my counterpoint and then I'll let Eric, because the thing that drive that terrifies me about as you were talking and I realized I get triggered at points where it starts to treat the goal to be build data products. And there are data scientists who are out there say we build data products. And the way that you just kind of, I think you kind of perfectly set it up when you said, oh, a JIRA ticket to give me another dashboard, which we definitely want to get out of the ticketing for build more things. But what, what I think is really problematic is when we put data products completely at the center is that it treats it as though that is the, the be all. And if we just build good data products and there are definitely people out There who live and like, where is the value of. I actually need a real, I have a hypothesis that needs to be validated one time and I need the right data scientist or the right analyst to help me validate this hypothesis. And that feels like it's, it's a serious danger of people saying, well, which data product solves that or where. Which is where I think dashboard bloat comes from is people keep saying, if I have a question, you need to point me to the technology that answers it. And that's missing a part of the role.
- [32:34]
Mo Kiss
Okay, this is just my early, like.
- [32:36]
Tim Wilson
How long until we let Eric weigh in?
- [32:37]
Mo Kiss
I know, I know, we'll let Eric weigh in, I promise. This is my very early thinking. But what I have found is that when you try and get the same person to do all of those things, they do none of them well. And so for me, when I talk about like data products, it's about how do you have a team who are really good at that or a person or whatever it is depending on your company. And in some companies it might be part of a person. Right. So how do you allocate a percentage of your time to building those solutions? And then how do you have a discrete bucket for exactly what you're talking about? I think the challenge is that we try and get data scientists, quote unquote, to do all of them. And they do, they end up with a ticket system that just is endless and you can't weigh those things off. And so I feel like you really need to put the, like this is the build work. We're doing the longer term stuff that like fuels that. And then I actually think the hypothesis generation and the quote unquote insights work is like, that is a different thing. And you might be using data products to answer those. Sorry, done. All right, who?
- [33:42]
Val Kroll
Eric, over to you. Eric, can you settle this?
- [33:46]
Tim Wilson
He's like, you're all wrong.
- [33:49]
Val Kroll
Thank God I'm here.
- [33:53]
Eric Sandersham
I think it's a great perspective and question. Right. So I will use this term data analyst, data scientist interchangeably. Right. So it depends on how people want us to view those roles. But regardless of how you want to label the role, actually there are sort of too large hemisphere of work that any analyst or data scientist engages in. So there is a sort of problem framing that ends with a diagnostic output. You discovered something, right? And so you're messing around with data, you're trying to figure out sense make and all of that. And then there's the solutioning piece where it starts from that output of the diagnostic and say now I have to figure a way to extract value or integrate into a decision framework in the organization. In my view, I think when we talk about data product, it really exists in the solutioning hemisphere rather than in the problem articulation or problem framing diagnostic hemisphere. I do take Tim's concern to say that if I think of my job as solutioning, then actually it misses a big chunk of the work of a data scientist and analysts where the solution only comes because I've done the diagnostic and problematic relation piece and I think in many different discussions, even on this podcast, the challenge really is there's a gap there. How do people do that kind of work? Well and the focus, therefore, if you say a data scientist is now ultimately driven and with KPIs on a data product, they are in some sense polishing the apple before figuring out how to grow it. That, that may be a real, a real concern. Right. But there is also something to be said that polishing that apple as a way to say give attention to that last mile. How do you not just say, well you need a dashboard. I pipe in a little bit of data, the charts look, you know, it's sufficiently okay. And then just get it out versus thinking well, can this dashboard be sort of generalized into a different kind of utility? Can I learn something about the way I piped in that data and if that data can be reused as an asset for something else? I think you begin to now think like a product manager because you're trying to think of internal monetization because they look, if you had to sell the company tomorrow, how would you price the stuff that you're doing right? And it should it or should it not be an asset? And I think there's also value in thinking like that. You know, sort of that the engineering hat that they wear in the solutioning hemisphere. Yeah.
- [36:42]
Tim Wilson
So it seems like there is a, there is a, there's a gating point. It seems like it's a very real concern that the, our business partners will, will go to. They just want to give me the, give me the polished apple. They jump to the solution and that having some clarity of thinking in the problem identification to figure out is this something served by enhancement to an existing product? And hopefully those are people who have lived the world of dashboard and report bloat. Is it a new data product which means is there clarity on the decisions that it will support and is that the framing in which under which that product will be built? Or is this something that is way, way upstream? We need to design an experiment to do this, we need to just go commission some research. We need to have a data scientist go and build a model to, to validate this hypothesis. This is not. And be able to sort of push back that if somebody came and said can you add to the dashboard X, that's not what's needed. It's not a data product doesn't play in the here and now solution.
- [38:05]
Eric Sandersham
I suppose for me the trigger point is really just the word product because I think all the stuff that everyone's saying is completely valid. How do I make sure that I get the last mile and do it well, make sure it's integrated and make sure it's reusable, it's scalable and all those stuff. Right? Thinking I'm not just here to produce a piece of report for an end user, but the minute we use the term product, we want to take on a whole universe of product management vocabulary and apply it. Right? Because I could say, look, a data scientist role is also to try and think of creating solution assets. If I didn't want to use that term. It's a data driven solution. There's a data driven asset. Why the choice of the word product? Because in my view, if you come back to the standard literature, then product has a very strong P and L connotation to it. And that P and L is not just about internal monetization. We don't call the help desk a product even though obviously they produce or they generate a lot of internal value to the organization. And they could assign a value in that sense, but within the organization they would have organized themselves vertically to what. What is the face off to. To our market. And that would define product. Right. And so should products only be reserved for an external facing part of that business? Because there is a real external PNL that could be generated from it versus looking inwards and saying oh no, you could always formulate some internal P and L. You can in fact, for every, every function you could do that. But is it helpful?
- [40:00]
Val Kroll
I think about. I was on a platform team internally that supported obviously platform team is, you know, different pieces. You know, there was a part of that team that created email templates that marketers leveraged and used. And so it was all about like repeatable, scalable things that had utility to help teams do their work faster, more efficient, whatever. And so it was really easy for us at the time. And now I'm questioning some of the way we use the term in the product, but to draw a boundary around those discrete pieces that we would we knew when it was clear that we had, you know, define design, develop, deploy and then like that whole adoption phase and then like handed it off. But I think the, like, the thought of platform teams not working on something that's considered a product, I think is hard. Like, I understand what you're saying that, you know, if you were to set up a P and L for every single team internally, but I think that even if you were to take some of the core components of your definition and getting into that like just digital product space, it is kind of, you know, you can atomize it in different ways, like to your point. But I do think that there's like a way to draw a boundary on it that is helpful vernacular to talk about those specific pieces to know when you're done and you can pivot to the next thing and which one are assigned to those big rocks. Because otherwise it just turns into like. It seems like it would be reductive to call it a project. Right. Because it does have repeatability and utility. I don't know, I'm kind of running around in circles at this point. But I think, I think there is, I think there is value in naming it because of the way that people will treat it. Not just what cause I agree with you Mo. Not just because of that upfront, but because of the maintenance that that will get and the attention to make sure that it's supporting the business processes, the decisions that those are being made. Like in the same way that you would maintain a model similarly. But so anyways, I'm on team. Give it a name when it deserves it. That's my camp, Val.
- [42:03]
Mo Kiss
We actually do have platform PMs for that specific reason we've started to delineate because the skill set, especially for like an internal platform pm is much more technical, I would say. Well, not always, but like you're often building, building internal products that speak to different systems and like there's a complexity there that requires a slightly different skill set than an external facing product.
- [42:28]
Tim Wilson
But the. Is the platform PM's is a. Is there kind of key stakeholder the product pms.
- [42:37]
Mo Kiss
It's the wider business in general.
- [42:40]
Val Kroll
Yeah, the decision makers of the business. Right. Most commonly, or at least in my experience.
- [42:46]
Mo Kiss
Well, it's building, it's building product and infrastructure that serves the rest of the business. So like it enables them to do their jobs. Right. And we do actually have a data platform team that sits in there as well. Which is why I'm really curious about Eric's perspective on data warehouses not being A product.
- [43:05]
Eric Sandersham
I tend to think of data well as a, as an infrastructure capability. Right.
- [43:10]
Tim Wilson
Because it, I mean it feels like a platform. Right?
- [43:13]
Eric Sandersham
Yeah, it's that singular. It's not a singular purpose. It's. It's sort of, you know, you could, you could sort of bend it twisted curated to serve multiple, you know, solutioning.
- [43:29]
Tim Wilson
If, if you tried to apply the P L and try to specify P L on a data warehouse, like oh, God forbid. Right. I mean that's like. That would be an absolute nightmare. Like there's there. It's like. I don't want to say treat the data warehouse like the help desk, but kind of in the context of this discussion, maybe that's not, maybe that's a, a step too far. But. And to me platform there, it feels very clearly different that a. That a platform or infrastructure is different from product. I guess maybe that was my misguided question of saying why isn't the platform there to support products and the products are there to support the business. So it's messy and it's complicated. It's why an architect has. They're a more senior person because they got to be kind of saying how do we put something together here that is going to be able to be. To effectively serve a bunch of different needs coming at it from different directions.
- [44:41]
Val Kroll
I think we've hit our all time high for amount of analogies and metaphors on this episode. Credit scores. Peanut butter. I love it.
- [44:52]
Tim Wilson
An apple. We got a chair. So maybe let's. Let's play a little. Let's play a little game that mostly credit to Val on this although I think Mo and I have been contributing like the. We'll play the data product or not a data product game. And this will be a four hour episode because we have like eight things to run through here. We'll see. I mean it'll be interesting under this discussion whether there's a quick consensus.
- [45:18]
Val Kroll
Yeah.
- [45:18]
Tim Wilson
So we'll just maybe run through these. So let's say we have an internally built a B testing sample size calculator. Is that a data product?
- [45:30]
Eric Sandersham
I.
- [45:31]
Tim Wilson
How do we vote? I could I say no?
- [45:38]
Mo Kiss
Okay. We've got to have a system here.
- [45:40]
Tim Wilson
Yeah.
- [45:40]
Val Kroll
What's the game?
- [45:41]
Mo Kiss
So is Eric going first or are we doing thumbs up and Tim's going to report on the thumbs up or thumbs down after?
- [45:47]
Tim Wilson
Yeah, let's do it all visually. Let's just put it in the chat and then we'll all kind of chuckle and not share. Like we could put Eric on the spot for every.
- [45:57]
Eric Sandersham
We Could, I mean we could just all show a thumbs up, thumbs down, you know, simultaneously. Right.
- [46:01]
Tim Wilson
This is an audio format.
- [46:03]
Eric Sandersham
Oh, that's true, that's true.
- [46:06]
Tim Wilson
It's like Michael Elbling is here. I will take it. I will take a strong. I will take a stand that I think it's. That it is not. I'll take a stand on everyone and then you guys can shoot me down.
- [46:19]
Mo Kiss
I think it is.
- [46:20]
Val Kroll
I think it is.
- [46:23]
Eric Sandersham
Damn it. Yeah, I think it's not.
- [46:25]
Val Kroll
Oh, you got the heavyweight on your side too. Okay, so Eric, why is it not.
- [46:36]
Eric Sandersham
I think it's, it's a data solution for sure. You know, with the APIs or if you build into a wrapped around template, maybe even an application. But to say this has reusability, generalizability, I'm not sure because it's very, is bespoke, it's for a specific type of work. Right. And the data, it's also very specific to that kind of use case. Would it not be?
- [47:06]
Mo Kiss
Okay, but what about if you have 150 data scientists and you're running 1,000 experiments a week, would it then meet the criteria and all those 150 are using it?
- [47:18]
Eric Sandersham
Okay, so if you say we built an A B testing again we get to words and semantics. A B testing platform that is like a recommendation engine. An A B testing engine where thousand data scientists can now use, reuse the same kind of functionality and capability then. Yeah, perhaps, because then in itself I could even think about monetizing this commercially outside of the organization.
- [47:46]
Val Kroll
Okay.
- [47:47]
Tim Wilson
But I think it's not a data. This is. You're entering some numbers or maybe it's pulling them, but you're entering numbers and it's doing math like it's a tool for the data scientists, but it's later.
- [48:02]
Eric Sandersham
Right?
- [48:03]
Val Kroll
Yeah. So can I give you my use case, the one that we built when I was on this platform team, because this is one that I had submitted. It was built for marketers to figure out is my list size that I'm about to send an email to big enough to deliver it as a 10, 1080 where you do send it to 20% and then the winner gets the 80%, you know, 24 or 48 hours later or is my sample size doesn't support it for like the type of change or my baseline open rate triggering. It was 10 years ago, but it was for marketers to make a decision about how they could be exploring their hypotheses. So that's, that was the.
- [48:39]
Eric Sandersham
So.
- [48:39]
Tim Wilson
So there's a distinction. I was thinking of the ones that I built where you literally had to enter multiple values and it would calculate it, which I would say is not. It's just a calculator. It's. It's no different from an HP12C that just has an interface built to do some simple math. If the calculator is saying, is a.
- [49:01]
Mo Kiss
Calculator not a product?
- [49:03]
Tim Wilson
I don't think that's a data product. No, it's just a tool. Right. Because there's not a data asset in the calculator. That's the. I am. I am entering some numbers.
- [49:15]
Mo Kiss
Okay. Did you need specialist data expertise or knowledge of statistics to build it?
- [49:19]
Tim Wilson
To build it. But I don't know how to build a calculator that does summation. So. But I would put that different if Val. What you were describing was somebody picking and saying, these are my criteria. And then it was saying, here's your list size. Maybe it's prompting you for a question of what kind of lift do you want? And it's hooking into an underlying data asset. Like, to me, I'm. I'm hinging on. There has to be an underlying data asset, not just code.
- [49:47]
Val Kroll
Yeah. Not just like, oh, I'm dealing with 10,000. It was saying, like, if my audiences have these interests, what type of population size are we talking about? And this is the left expectation. Yeah. So. Okay, so that's a good distinction. Okay, so this rapid fire game.
- [50:02]
Mo Kiss
Not sold.
- [50:03]
Eric Sandersham
I like what Tim talked about. I mean, the calculator, let's say. Right. Comes with an underlying database and it's built as part of the feature of that calculator, then perhaps we can say it's a data product. But today, if that calculator says I bring data to it, but it actually doesn't come coupled specifically with a set of data assets, then release a tool. It's a calculator and not a data product because there's no underlying data to it.
- [50:31]
Val Kroll
Good one.
- [50:32]
Tim Wilson
Mo. You convinced? Is mo.
- [50:36]
Val Kroll
All right, you give the next one. You throw the next one out. Mo from the list.
- [50:39]
Eric Sandersham
What do you.
- [50:40]
Mo Kiss
Which one do you want?
- [50:41]
Tim Wilson
You can pick one and then you can declare what you think it is.
- [50:44]
Mo Kiss
An interactive dashboard containing campaign performance, including targets.
- [50:50]
Tim Wilson
What do you think? I declared what I thought it was. We still haven't specified the rules of this game, I realized.
- [50:56]
Val Kroll
So we're just going with it.
- [50:59]
Tim Wilson
That has to be a data.
- [51:00]
Val Kroll
I think it is.
- [51:01]
Tim Wilson
Right.
- [51:01]
Val Kroll
I say yes, if targets are included. If targets are not included, I think there's an argument that maybe it's not why.
- [51:08]
Mo Kiss
Why is there. Why is the.
- [51:10]
Val Kroll
Because it's helping to make a decision. In my opinion. I think that that's helping in full action. So like that's what makes it more like purpose built. But I don't know, maybe there's. Eric's probably like, oh boy.
- [51:24]
Eric Sandersham
I'm leaning towards not a data product.
- [51:27]
Val Kroll
Dang. This is gonna be a four hour episode. Because we still have so much to learn. Okay, so tell us why on this one, Eric.
- [51:35]
Eric Sandersham
So is it the dashboard that the key value proposition is the front end user interface?
- [51:42]
Tim Wilson
Right.
- [51:43]
Eric Sandersham
How do you visualize that information? If I took that away, I mean the data is still there, right? You always had this stuff anyway, you're solving a visualization challenge, isn't it?
- [51:54]
Tim Wilson
But you're also guiding them into what they should be thinking about and helping them. So I'm not even sure the targets are necessary as much as I want to have targets on it. The targets are required. If there's a process in place where they say I am monitoring campaign performance and I'm looking at it and it is showing that my ROAS is low or my conversion rate is low and I'm looking at this visual thing from curated underlying data assets and that is helping me decide that I need to contact the agency. Shift channel. Shut this off. It feels very much like a data product to me. Yeah.
- [52:36]
Eric Sandersham
Okay. I mean if you're building sort of an integrative layer of capability to it. Right. Triggers off certain red flags and it may trigger off certain downstream processes perhaps then it becomes almost an engine versus just a visualization layer. Right?
- [52:54]
Tim Wilson
Yeah. This is my fear.
- [52:56]
Val Kroll
But also if it's curated. Right. I think this is maybe where you were going a little bit with it, Tim. If like what's in the dashboard is curated to answer the specific questions or actions that that business person is going to take versus just like, you know, whatever is out of the box with whatever tool is collecting or ingesting that data to just show you how it's performing.
- [53:18]
Tim Wilson
I feel like I provided you a visual interface to the data warehouse. So let's see if we can quickly figure out because we're going to do one more and it's going to be just to try to land the plane. So the chart I described at the beginning of the episode, which is a single chart, it is based on a data asset that is just a. I mean it's a 250 row data asset that is used for plant. To me that feels like it is a data product. It's a very simple data product and I am the product manager and analyst and business user of it.
- [53:52]
Val Kroll
What's the monetary value?
- [53:56]
Tim Wilson
Yeah, tied to the P and L since we make nothing. That's a fair point. But I mean, even knowing we pulled it up in one of our planning sessions for a future episode and said, who should be the co host? And it was like two people were like, well, that needs to be the combination. I was like, we just made a decision in way faster time. So I'm going to say that that is a very simple data product.
- [54:18]
Mo Kiss
So one thing though, that has been top of mind for me is if you're building something for one discrete person or one very discreet problem with no way to kind of. So like to me, and we've been thinking a lot about this when it comes to some of the dashboarding ones, is like, is there a way we can prep and put together the data and the dashboard that it could serve the needs of multiple teams? Right? Because then actually you're getting a lot more value from it and you're also not doing that insane thing where you're like building to one internal person specifications and then they leave and it's never used again. What concerns me about the example that you're talking about, Tim, is like you are pretty much the only user of.
- [55:05]
Tim Wilson
It, except the flip side. You try to build something that serves everybody, you're starting to try to build a fricking platform and it blows up. And I will say you were 30 minutes late to the meeting, but we actually did have a group use the used it. So I know some of these things get fallen on me, but I had a conflict.
- [55:28]
Eric Sandersham
So in fact, you know, I. Because you had a sort of preview of some of these questions prior to this call and the specific example, I thought about it actually and I thought it's. As it stands, my answer would be no, it's not a data product. But it could be. And then I had to sort of. I mean, this was just my first initial gut reaction. And then I asked myself, why did I think like that? Right. And I tend to lean towards what MO is saying as well, the sense of scaling, repeatability, reusability. So let's say if you. So now you say I have a scheduling. If the scheduling doesn't come with an underlying data asset, then it's just a tool. But it says that, look, all you have to do is there's a way to set up this database and everybody will put it in, load it, APIs, whatever, and then I can Lift and shift this as a scheduling wrapped solution beyond just for us, but anyone could use it. Then again, with a view for commercialization or generalization, whether you choose to charge for it is besides the point. Right. But it's beyond just a single use intent because then it's repeatable. Right. And when it's repeatable, then you have an asset to talk of. Because if it's not, then yeah, it's useful to you, but it's not really an asset. Right.
- [57:00]
Tim Wilson
Okay, well, so it sounds like we're not going to totally solve this, but we've got a lot of food for thought here and we're gonna. We're running way over, but so I'm. We're gonna have to leave it there. But not before we do what we love to do, which is go around and everyone share something. Maybe not about data products, or it can be about data products that they found interesting, useful, thought provoking, silly as a last call. So Eric, you're our guest. Do you have a last call?
- [57:35]
Eric Sandersham
I've been reading a little bit about these large reasoning models. I mean, when I first heard the term, I'm sure, like many of you, extremely skeptical. It's just a relabel of the same stuff. And in some sense it's really just the introduction of reinforcement learning into a large language model and then were calling it oahas reasoning ability. So in fact, the two papers sort of crossed my path in the last couple of weeks. One was now they sort of have the ability to look at the artificial neural net at the back end and see what notes sort of light up when you've asked the likes of say, ChatGPT to take a step back and argue through why you came to that conclusion. And what the researchers found in that article was that while it does give a better answer, right, it slows it down and it breaks up the workings. It's actually lying. That means because the notes at the back are firing off in a different way, but it's telling you I'm solving it in this sequence of step because that's what you want to hear.
- [58:43]
Val Kroll
Oh my gosh.
- [58:44]
Eric Sandersham
But actually the neural nets are not reflecting that same reasoning logic that is telling the end user. So what can you trust if you did it as a one shot, if you ask it to do it sequentially and break it down, it may look nice and you think it's doing something reasonable, but it's also lying to you because it's telling you stuff you want to hear. Another paper that complements this was they Looked at say a regular large language model, an LLM versus a large reasoning model and a lot of these metrics that they measure in terms of the accuracy and all that are not measured on a one shot case. So they will typically, let's say I run it for 50 times, 100 times and then what's the accuracy level or the correct levels that come back as a response based on a 50 run trial or 100 run trial? The typically that's how they set it up. And so the authors also commented that this is quite nonsense because in the real world we don't run something for fifty hundred times. It's a one shot deal. Either you get it right or wrong. And can I trust it or not? Right. But what was interesting, say okay fine, if you want to use this metric, then let's just run it. And they found that if you run it enough times, let's say from the 50, 100 run, let's run it 5,000 times, let's run it at 10,000 times. They found that the large language models without this reinforcement learning outperform in accuracy the large reasoning models. So the large reasoning models start off well and then if you run it enough times, the large language models overtake and on a long term basis they all perform better than the large reasoning model. Which then the authors concluded two takeaways. So one is that what's happening with the reinforcement learning is it's asking it to be accurate on a minimum short approach. So they are pushing for more immediate specificity but sacrificing long term generalizability. So you're sort of asking it to specialize quickly. Two, it also suggests that the data that the large language model has was already sufficient for it to achieve the same outcome as the reasoning model. There was nothing new that was put into the mix because if enough time, all the data was already essential. The ingredients were always there. Right. And I thought this was. Wow. You know, it's quite interesting.
- [61:19]
Val Kroll
It's deep. That's good. That's so interesting.
- [61:22]
Tim Wilson
They're going to take over one way or the other. Now they have multiple vectors to come at us through brute force of trials or through reasoning. Wow. Somehow that feels vaguely unsettling. Yeah, but fascinating. Wow. So Mo, what's your last call?
- [61:41]
Mo Kiss
Okay, well, last week I had a heap of fun at Snowflake Summit in sf and one of the really cool things I've been playing around. Yes, my team are terrified because I've been on the tools a bit. They have this new thing called cortex, but basically it's all of their AI and machine learning capabilities. But the really cool bit that I've been testing out is basically now they found a way that you can reference the Cortex functionality in your standard, almost like a normal standard SQL function, which is super cool because you don't need to write like all this separate Cortex code. You can just use like. It looks basically like a SQL function. But I've been playing around with this images specifically so you could reference static images at the moment and it will return things like object tags, descriptions, embeddings, all that sort of stuff. And yeah, it's just been really fun because you can do a lot more image analysis without needing extra infrastructure and kind of just build it into your standard SQL workflow. So just been having play with that and it's pretty cool and worth checking out.
- [62:44]
Tim Wilson
Snowflake, still not a sponsor. You're just gonna release cool products. We're gonna talk about them anyway. That sounds interesting, Val. What's your last call?
- [62:58]
Val Kroll
Speaking of interesting. So this is a fun one and it's been a minute since it was released, but if you didn't catch it, Josh Silverbauer, who is an absolute gem, launched the third party show. I'm sure you've seen seen that on LinkedIn and his first guest was none other than Tim Wilson. And it was highly enjoyable. They play like lots of different games and Jason Packer made a couple appearances and so it's a good time. So just wanted to give you a shout out, Tim, because you guys did a great job and I can't wait to watch some more episodes.
- [63:37]
Tim Wilson
And it.
- [63:38]
Mo Kiss
Oh, wow.
- [63:39]
Tim Wilson
And it had lots of canned laughter as well, you know, so.
- [63:41]
Val Kroll
And it was perfect. All right, how about you, Tim? What's your last call?
- [63:46]
Tim Wilson
So mine is, is literally just a simple data visualization with a bunch of data behind.
- [63:52]
Val Kroll
Okay, the upset chart. Forget it, Tim. We're done with the upset chart.
- [63:56]
Tim Wilson
Yeah, no, so this upset chart, so you take combinations of sets. No, this is David McCandless who I have kind of a weird. I have no direct relationship with him, but he is. Its information is beautiful. So I. I've at times had like data just for the sake of making it beautiful. Kind of rubs me wrong. But he does really cool things. And so one of them was Breaking Down. The piece is called Based on a True True Story and it goes through like 18 films that are based on the true story and breaks down literally scene by scene and whether each scene is true, truish, false ish, false or unknown. And you get it. Just in a simple bar that are. That are bands like the red is false and true is blue and unknown is gray. So you get an enormous amount of information and you can click through to the Google sheet that's actually feeding it. I mean there's a researcher. I have no idea. Like compiling this information seems insane. So it is a lot of information, very densely populated and just because I know you're asking. Depending on how you select the criteria, the most true to the true story film of the 18 they they looked at was Selma, followed by the Big Short and Bridge of Spies. The three that were least true to reality were the Imitation Game, which I love that movie Hacksaw Ridge, which I never saw an American Sniper. Those were all like half or less than the scenes were actually true or true. Ish. So it's just a very dense. And when I saw it I was. I could not help but sort of poking around and saying okay, this is. It doesn't really matter. Although I'm always having that question when it says based on a true story of like how. How true is that really? So. But it's just pop culture.
- [65:56]
Val Kroll
It's fun.
- [65:57]
Mo Kiss
I want to know about the Widow Clicko movie.
- [65:59]
Tim Wilson
That's the one, you know, that is not on there. I bet that one's.
- [66:03]
Mo Kiss
I assume it's not. It's very niche.
- [66:04]
Tim Wilson
Pretty close.
- [66:06]
Eric Sandersham
All right.
- [66:07]
Tim Wilson
Yeah. But very on brand for you to wonder about it though. It is so we have. Yeah, we've definitely gone over so. But I will therefore thank Josh Crowhurst for the added bit of editing that he will be doing. A shout out to ken Riverside and 4th Floor Productions as well for their support in this. Eric, thank you for.
- [66:30]
Eric Sandersham
Thank you. Thank you.
- [66:31]
Tim Wilson
Coming on. I feel like we should get a report from you that we can put in the show notes as to whether you survived the rest of the day since you're now going to be talking to a clearer audience.
- [66:41]
Val Kroll
Survived this.
- [66:44]
Eric Sandersham
This actually been. It's been thoroughly great. I think. I think it's a. You've managed to shift some of my positions. I mean I thought I had sort of landed on a position in my mind but I think based on this conversation it's shifted a bit and that's good.
- [67:04]
Tim Wilson
It's on my bucket list to sometime see one of your medium posts and say I think that might have. He might have been saying this guy was completely dead wrong. But here are some thoughts to totally tear it down. I don't have to be held up as Right. But if somewhere one of your posts again I cannot recommend those. They're the right length. So many people are writing and this is pot calling the kettle black. But write really long weekly newsletters that I do read. Yours are like the perfect length like and they always make me think and clarify.
- [67:39]
Eric Sandersham
So thank you. Thank you.
- [67:40]
Tim Wilson
Bonus. Last call will definitely link to your medium content. So if you've enjoyed what you're hearing, we would love to get a review on whatever your podcasting platform of choice is. We recently updated our website now that Google Play no longer exists and itunes isn't a thing. Maybe our subscription page was a little out of date, but we'd love to get a review if you'd like to reach out to us directly. You can do that on the measure Slack or you can do that through LinkedIn or you can just send an email to contactnalyticshourio. If you want a sticker, you can head to analyticshourio and click the sticker Me link in the global navigation and fill out a little Google form and we'll be happy to get some stickers in the mail to you. But really, if you're sitting on a chair, maybe polishing an apple, cutting it up so you can dip it in some peanut butter so you can kind of crunch on it and enjoy it while while pondering a dashboard or some other data product, just always make sure you keep analyzing. Thanks for listening. Let's keep the conversation going with your comments, suggestions and questions on Twitter at analyticshour, on the web at analyticshour IO.
- [68:58]
Eric Sandersham
Our LinkedIn group and the MeasuredChat Slack.
- [69:01]
Tim Wilson
Group music for the podcast by Josh Grohbhurst so smart guys wanted to fit.
- [69:07]
Eric Sandersham
In, so they made up a term called analytics.
- [69:09]
Val Kroll
Analytics don't work.
- [69:12]
Tim Wilson
Do the analytics say go for it no matter who's going for it.
- [69:15]
Val Kroll
So if you and I were on.
- [69:16]
Tim Wilson
The field, the analytics say go for it. It's the stupidest, laziest, lamest thing I've ever heard. For reasoning in competition.
- [69:26]
Val Kroll
Rock Flag and Eric said the upset chart is not a data product. Bird.