An insight is a piece of information that drives or changes action. But how do you get to an insight? What steps do you have to take? In this episode of The Insights Factory, Host Ian Cook, CTO of Seek, sits down to discuss this with two Seek teammates: Jordan Kassof, Director of Engineering, and Andrew Breton, VP of Data.
An insight is a piece of information that drives or changes action. But how do you get to an insight? What steps do you have to take?
In this episode of The Insights Factory, Host Ian Cook, CTO of Seek, sits down to discuss this with two Seek teammates: Jordan Kassof, Director of Engineering, and Andrew Breton, VP of Data. They dive into the modern data stack and the resulting evolution of roles in the industry, presenting and scaling insights, and more.
---------
Key Quotes:
“If the dashboard is where you lose interest in the problem, then you're not solving the problem. You can't affect change in that business through a dashboarding tool directly.” - Jordan Kassof
“It's really hard to recruit people to work on an old system because they know they have to be investing brain space and time in learning something that is a dead technology that they cannot transfer.” - Andrew Breton
“What I saw a lot of was people making the decision that they were going to migrate to a new modern system and then it taking years to get there….You’ve got to build everything for the old world and then also build it out to prepare for the new world, which you're never really sure is even ever going to come. Business priorities could change before they even complete that project.” - Andrew Breton
“Transparency is incredibly important. Transparency around where the numbers are coming from, how you're calculating them, how they relate back to those source systems, if there are discrepancies or changes over time. Being able to show and explain those to your business users is incredibly important because trust is really hard to earn and it's really easy to break.” - Jordan Kassof
“Insight-driven action...says, Hey, what question am I trying to answer? Why did this happen? What am I going to do? When am I going to do it?” - Andrew Breton
---------
Show Timestamps:
(01:57) Describing the modern data stack
(06:35) Have job functions evolved with the modern data stack?
(09:25) Does everyone love the modern data stack?
(13:36) Steps to take after getting your data stack right
(18:18) Should you pursue a “single source of truth” in your data?
(27:00) The presentation of data: is a dashboard enough?
(30:54) Can you scale insights?
(32:51) Lessons from Jordan and Breton to get better insights from data
--------
Sponsor:
This podcast is proudly sponsored by Seek, the leader in cloud-based creation and delivery of industry-focused insights.
--------
Links:
Connect with Host, Ian Cook, on LinkedIn
Connect with Jordan Kassof on LinkedIn
Connect with Andrew Breton on LinkedIn
Follow Seek on LinkedIn
Ian Cook: [00:00:00] Some days it feels like we're drowning in data, but data isn't knowledge data without context or the expertise to understand it. It's just something eating up storage space in your warehouse. That's where being insights driven comes in insights driven organizations focus on generating actionable insights rather than just collecting and munging data.
Insights drive better decisions. Welcome to the insights factory.
Welcome to episode two. I'm Ian Cook, your host and the CTO of Zeek. In the last episode, we had a long conversation about how an insight is a piece of information that drives change in behavior at a business, a truly useful piece of information that people can act on and not merely just data. There's a lot of technical background before you can get to that insight.
However, things like data collection, where does it come from? Data management, which is the terms we hear all the time about ETLs, now more [00:01:00] ELTs than anything else. And then even presentation and dashboards. There's a lot behind this, and to talk with me about it today are two people from Seek, Jordan Kassoff, Director of Engineering, and Andrew Breton, who goes by Breton, the VP of Data here at Seek.
Welcome gentlemen, thank you so much for joining me.
Jordan Kassof: Hi, thanks for having me.
Andrew Breton: Excited to be here. Very cool to be here, yeah. Very cool to be here.
Ian Cook: Excellent, because you don't see enough of me during the regular workday, you figure we've got to do it here too. Thank All right, so let's get into it. I can't open Medium, Substack, LinkedIn, pretty much anything nowadays without hearing the phrase modern data stack.
It's everywhere. People use that term constantly. Jordan, could you give me a quick description in your mind when you hear that phrase? What do you think?
Jordan Kassof: Yeah, sure. The modern data stack. The way I think of it is it's an ecosystem really of different software tools that work together to streamline that [00:02:00] whole data lifecycle you were just talking about.
So extracting, loading, transforming, analyzing, and visualizing.
Ian Cook: What distinguishes it from the prior data stack, like what makes it modern?
Jordan Kassof: Yeah, that's a really good way to understand it is to focus on what came before. So, legacy data platforms, they tended to be on prem, meaning you had to host it yourself.
They were typically monolithic, just a big app. of tightly coupled components, usually a single vendor was offering that entire platform. And so you got into kind of a jack of all trades, master of none situation, where none of those individual components would be the best they could possibly be, because this one company was trying to offer all of the products.
The total cost of ownership on those sorts of systems tended to be quite high. Because the care and feeding that it takes to maintain the hardware that's needed for such a powerful computing system, it's very resource [00:03:00] intensive and requires a lot of I. T. Professionals.
Ian Cook: So you're saying, and um, Bretton, talk to me a bit about your experience with this.
But from what Jordan just said, what I hearing is the modern version of this is a little more componentized. It used to be a monolith. Now it's much more pieces and parts. Is that the experience you've had?
Andrew Breton: Yeah. I similarly had experienced like in the, in the day with a bank would have an entire data system.
The trading system was also the analytics system was also the accounting system was also the just everything system. So these things were massive. They were huge. And they were maybe like great at one of those things and we're just barely getting by on all the others. So they were expensive, problematic.
So now we get to basically, there's like a handful of best of the breed for each of the tools that you want. You've got your favorite cloud compute offerings. You've got your favorite data warehousing offerings. You've got your favorite ELT systems. You've got your favorite. Visualization systems. And so the engineers kind of get to use what they are comfortable with, what is best for their needs.
They all [00:04:00] tend to work pretty well with each other because there's, there's only a few in each of these things. And so the constellation of modern tools is. Much better to work
Ian Cook: with. Much better to work with. But that sounds like a lot of tools and choice. Is it that the process to get to the modern data stack has been just a simple shift from we had a monolith to now we have a company that helps us?
Do you have background in watching this happen? Because you've been sounds like you've both been in both worlds.
Andrew Breton: Well, for example, I would say one of the big changes that everyone's going into the cloud. And so once people got comfortable using cloud computing, it's kind of like now they had to get comfortable with a lot more Just external tools, external services.
So rather than having to build everything in house and own everything in house and manage everything in house. So we now just have a mentality of going out and looking for what's best. So once you convince people that it's okay to use Azure, AWS or GCP, now you can bring [00:05:00] in whatever other tools you want.
I think that might have kind of been like the big jump that kind of just got engineers. and engineering managers and technology managers to be willing to work that way.
Jordan Kassof: Yeah, the modern data stack definitely, it gives a lot of benefits as Brenton's talking about these targeted tools that are fantastic at the one thing they do.
These tools are scalable because they run on the cloud. They can handle no matter how much data you throw at them. AWS has enough. servers to handle it. They're flexible, they're usually quick and easy to use, they have nice drag and drop interfaces. They're definitely not a panacea though, like the decoupled aspect is kind of a blessing and a curse.
It's nice that you have all these separate tools that do their thing really well. But someone needs to figure out how to make them work together. And while they all have ways to work together, that's still something someone needs to figure out, which, in the old world, when it was all just one widget, you didn't necessarily have to worry about that quite as much.
Things like data governance and [00:06:00] security, are incredibly important. And when you have all these disjoint applications, you need to be really thoughtful about ensuring that you have data security policies that are consistent across the different tools.
Ian Cook: Does that mean job functions or roles have changed along with the modern data stack?
So are these the same people doing this coordination between the tools that used to be the ones doing the old data stack? Jordan,
Jordan Kassof: go ahead. I do think that the roles have shifted a bit. They've become a bit more specialized, kind of following the pattern of those tools. Now you have people who can really focus in just on, for instance, the movement of data, because they're really just focused on that E and L, the extracting and loading.
A really interesting pattern in the space that you're talking about is the rise of a role called the analytics engineer. Over the last couple of years, job posting for analytics engineer has grown exponentially. And what this role is, it's kind of someone who sits in between business and technical users who can use these modern data stack tools.
[00:07:00] They know how to write code, but they also have good business acumen and can coordinate with strategists and turn those ideas that your business experts had into. actual code and models that drive those insights that we talk about.
Ian Cook: Interesting. Bretton, this is actually something we've had you working on a lot here at Seek.
Can you talk a bit about your experience in doing this, putting these kind of pieces together and working in this world, some open source, some custom?
Andrew Breton: Yeah. So we've managed to recruit people who are, well, they're easy to find because the Ecosystem of open source technologies are kind of like commonly used by most people.
So you've got your operations engineers who are great at docker and kubernetes and AWS and deployment systems. Then you've got your analytics engineers like Jordan mentioned. So they're know, dbt. They're gonna know their dashboarding systems. These are the open source systems that you can recruit people to use with you.
So everyone's speaking the same language. They've been using the same tools across different. phases of their life, and [00:08:00] they're all working really well together. So that's worked out very well. It's also just been really great to also be working using the modern data stack. It's great also when you recruit people to tell them that we're using modern data stacks so that they know that the things that they use, the tools that I'm using, the skills that they develop are going to be useful to them for the rest of their career.
It's really hard to recruit people to work on an old system because they know they have to be investing. brain space and time in learning something that is a dead technology that they cannot transfer. So recruiting people to work using all the modern cloud computing, the modern data engineering platforms, the modern deployment systems, those are a way to get better applicants to.
Ian Cook: This all sounds terrific. Modern data stack sounds like a great solution for everything. Everybody must love it. I'm teeing that up for Jordan because I have heard in some conversations that he has some ideas about this. So Jordan, talk to me a bit about the idea that you brought up once that not everybody's in love with the modern data stack.
Jordan Kassof: Yeah, I think the individuals who are using these tools love them because [00:09:00] they're built for them, but there are some realities of operating in a large enterprise that make using the modern data stack a bit more challenging. For instance, it is simply hard and time intensive to onboard new apps at a large enterprise because your legal team wants to review it, your finance team wants to review it, your IT security team wants to review it.
And if you take those reviews and then you multiply it by the five different tools that you have. You're asking a lot from those support teams and that can prove challenging. Additionally, if you're a brand new company and you bring on these tools, that's great. But the reality is a lot of companies are not brand new and they have legacy systems.
And there's simply no way to get away from that. Johnson Johnson has been 100 years somehow, right? And so there's just the reality of you will need to figure out how to either integrate with legacy systems. or undertake a very large digital transformation process [00:10:00] where you get off of those legacy systems.
That is a very, very large challenge. There are these large enterprises, there are dozens, hundreds, potentially even thousands of people who on a daily basis are tapping into these platforms. And so it is not, Just as easy as flipping the switch, unfortunately, to turn these on when you're talking about a big fortune 500 type of company, it can be quite challenging for them to actually turn on a platform like this internally.
Ian Cook: Interesting. Bretton, you used to work at some fairly large organizations doing a lot of work with heavy data. Do you have stories about exactly when this has gone either well or
Andrew Breton: poorly? Yeah, so what I saw a lot of was people making the decision that they were going to migrate to a new modern system, and then it taking years to get there just years.
So they'd say, hey, there's a great new cloud based database. We want to migrate everything onto. We've got everything on our old SQL servers here. Like, we've decided we're going to migrate [00:11:00] and the road map is like 2 or 3 years. So. It's great that you can sort of plan around it, but you still have to build everything twice, right?
But everything for the old world, and then also build it out to prepare for the new world, which you're never really sure is even ever going to come business. Priorities could change before they even complete that project.
Jordan Kassof: You're telling me the business can't stop what they're doing for three years to accommodate our IT projects?
Ian Cook: No, apparently not. This all reminds me of one of my favorite old philosophical thought experiments, the Ship of Theseus. The idea, right, that you have a ship and you replace parts of it bit by bit. You replace a railing, you replace an oar, you replace a piece of floorboard, you replace a mast, and eventually every piece is replaced.
But it looks like it did at the start. Is that the same ship? I see a lot of companies going through this process. They say, well, I don't want to start from scratch and build things over again. So what I'll do is I'll keep working to replace bits and pieces. And eventually you have an [00:12:00] entirely new system.
And maybe you should have gone back and thought, well, If I just started fresh instead of trying to make the new stuff fit the old pattern, there could have been a different path there. So it might not have taken the same amount of time or you don't have to pause everything to start retrofitting and piecing things together.
So I always like when some of my old philosophy classes come back into play.
Andrew Breton: I mean, it's always a constant decision to make when we're making these engineering decisions. We always have to decide if we have a better idea about something, should we just start over and do the better one as fast as we can?
Or should we take little baby steps and just make small improvements because we can't stop everything and we can't afford to wait. I mean, every company has that problem. Even new companies will start something, start a new project and then a few weeks or months or years in realize there's a better way and they have to figure out what they're going to do.
Like. Stop and start over small baby steps happens to all of us. I use this one API. This other one's a little better, but I [00:13:00] already built it on this one. Should I bother changing or not? And what's my strategy going to be? I mean, we all have to navigate each of those ones and you got to weigh the trade offs in every case.
It's not always the same. So
Ian Cook: both of you have spent quite a bit of time working with data, the tools behind moving data, building the kinds of tables, structures, databases, systems that people need to get to that data. But that means you're sitting across often from people who are planning on using it.
Let's say we've installed all of the best of breed, we've started from scratch, we have a modern data stack set and ready to go, the best of breed warehouse. That's it, right? Time to get to the insight and there's nothing else. Or is there another step in there, Bretton? Why don't you start on that one?
Andrew Breton: Oh, boy.
So there are so many things that you can do to that data to improve it. I mean, for one thing, there are often multiple competing sources that are providing very similar data, and you want to kind of provide like fallbacks and waterfalls where you can kind of interchange one for the other. It's like, Oh, this data provider is really good for North American data, but when it comes [00:14:00] to global data, I have to use this other data provider, but I want to like compare them together.
So I want to be able to use one when I have it and use the other one I don't. But then you have to figure out the rules about when and how you can use that data together when it's equivalent and when it's not. Is the granularity the same? Is the timeframe the same? Are the rules about the business logic of what represents the net sales the same?
So There's all kinds of very content specific decisions that someone who understands the content has to make to make that data better. And that's even just to get to the next step to make it usable for some analysis. So as you get away from the technical problem of just moving the data, moving the bits.
you know, from wherever your data provider gave them into your warehouse and then pushing it into some replication system and then adding metadata and columns and naming everything and creating a catalog of it. Then you've got to get into the business logic. It's like, okay, well now which of this data works well together, which is equivalent, which of it fits my data model, which doesn't.
So there's another layer of [00:15:00] data modeling that has to be done this. I mean, every company has to do it, and we do it here at Seek. We have a data model where we, we have experts in our data content that are working to figure out exactly how the different data vendors fit or don't into the different parts of our data model so that we can use data sets together.
So that's just the next step, and that's even before you get it into running an analysis, running some type of algorithm, creating the dashboards, creating the actionable insights. So
Ian Cook: we're actually at a point now where we're talking about somebody different yet again. So there was the people who may have managed and worked on the monolithic data platform.
Now there's much more of this modern data stack. As Jordan noted, some of these roles change, people learn new skills, people devote themselves to a particular area. But now we're adding in a whole other person. The big word that I think Breton used that I want to go back to here is content. What is the content of the data?
Meaning what is it attempting to [00:16:00] inform? What am I using it for? Both of you worked in the financial services area plus other areas. How does that generally go? Who are you talking to in order to understand what the data, the purpose of using that data is going to be? Jordan, go ahead. You're
Jordan Kassof: talking to the end consumer, the person who actually acts in what the business is trying to do and wants to make a decision or effect some change.
They're going to be the people who really understand the problem that you're trying to solve. And they're frequently the people who are familiar, conceptually at least, with the data assets that you're getting. They use these. Inventory management systems, these portfolio management systems, they know the vendors well from that side.
And so talking to them to understand, Hey, I have these three data sets. And when I look at them, they all look a little different. They call candy bars, different things. Is that a difference that is meaningful to you? Or is there some sort [00:17:00] of as Breton was mentioning before like a waterfall logic that you want to rely on across these different data sets.
I said three, but the reality is this gets into double digits very quickly. In an asset management company, you have three different teams, each one of them like their own research system, and then you have alternative data sets because they want to get their unique perspective, and then investment accounts are held across different institutions.
And so just there, I just, I went to double digits and every single one of those vendors is going to give you different formats on a different time frequency. Some are API, some are sending you files through FTPs. There's just this huge array of variability that needs to be standardized in order for one of those.
business users to actually get value out of the insight. Yeah,
Ian Cook: I really appreciate you bringing this up. This gets to something that maybe is a hobby horse of mine, but I want to hear what you two think about it. Tons of times along with, okay, [00:18:00] modern data stack, one of the things that I will hear constantly referred to as a single source of truth.
We need a single source of truth that all the data has to be in one place that has to be true and exact and everybody has to be working with it. I happen to think that's. almost a pipe dream and not really worth pursuing because of the reasons Jordan brought up. I think there are lots of things that end up being hard to do in that situation and almost reverses the process, meaning get the data right in some as though there's like a platonic ideal of the right kind of data as opposed to starting from the business problem.
But I would love to hear Bretton. Am I crazy about that?
Andrew Breton: So I mean, it's funny. I can always think of wanting a single source of truth is like a philosophical impossibility that we're all looking for in life in general, right? Like, sadly, there isn't one, right? You can even imagine just like the work that you would do to shoehorn every possible data set into one universal data [00:19:00] model.
You're going to inevitably end up ruining some of your data. You're going to lose some granularity somewhere. You're going to create some duplication somewhere. Whereas if you start from the actual use case that you're trying to answer and then work your data into those, then every data set will be optimized for the use case.
So I think, though, on the other hand, there are just benefits to centralizing your data, to find commonalities to make them more universal just to create. efficiencies in your system and to maybe create like a query language that you can use and to create a catalog that means something. So you've got to find your balance to how much universality you want to impose.
before you are chasing an impossible dream to do it. Yeah, and it depends on the content, depends on the use cases. How broad of a set of use cases are you trying to meet? Are your traders and your analysts and your accountants and your trade operations and your marketing people and your advertising people and the CEO, are they all trying to read the same database?
That's a very broad set of use cases. Or can you get a small enough people to kind of agree [00:20:00] on what they're working with and what the rules are going to be? So I can see obviously the value of centralizing things and trying to reduce the number of sources where possible discrepancies can arise.
There's a value there. Eventually, though, you will hit limitations and it's not possible to get all the way there. Interesting.
Ian Cook: Jordan, go ahead.
Jordan Kassof: Yeah, I also think it's a bit of a pipe dream. It's not a real thing. By the nature of these platforms, like we're talking about, they are consuming data from other systems, right?
When your CFO wants to know what they're going to file on their taxes, they're going to go into their corporate finance. system. That is the system of truth because that is what actually affects it in the real world. Your inventory management system is what actually knows what's in the warehouse and what can actually ship stuff.
So you're pulling data from all of these, making them make sense together so that people can have a holistic view of their business is incredibly important. But as opposed to [00:21:00] saying, this is. It's the absolute truth. I think transparency is incredibly important. So transparency around where the numbers are coming from, how you're calculating them, how they relate back to those source systems.
If there are discrepancies or changes over time, being able to show and explain those to your business users. is incredibly important because trust is really hard to earn and it's really easy to break. That
Ian Cook: is a great point. Trust becomes a fragile, you could get there. It takes forever to be trusted and takes just a moment to have that trust fail.
And then that ends up happening because people don't trust a number. But one of the things that we're talking about here is, well, if there's no single source of truth, then perhaps there are some different numbers, but it's that transparency. Well, here's how I got to mine. How did you get to yours? Back when I was doing a lot of work in healthcare, I used to have a lot of people presenting to me their analyses.
One of the things to help with the transparency that I would encourage them is to provide read aheads, meaning [00:22:00] send me what you are going to present with all the background information. I will send back questions I plan to ask in the meeting where you're going to present. And start having that back and forth so that we can get to discussions very quickly about where did this number come from?
How are you calculating it? When healthcare, there's a lot of, there's one that anybody, if we have healthcare listeners, we'll know PM, PM per member per month. There is one way to calculate it in one group, one way to calculate it in another group. So long as you. Present to us the way you're calculating it.
I can feel better about the number I see, even if I see different numbers. And I think that's hugely important for how we start getting to that point. I do want to dig in more on something that Jordan, you said people talking at the business level, people talking at the technical level have similar, but not the same languages.
In your experience, are these as different as Gujarati and Armenian, or are they just dialects of a common language? How hard is it to actually have that conversation?
Jordan Kassof: I think [00:23:00] it gets to that analytics engineer role that I was talking about. And so these are people who, in a way, by definition, are sort of generalists.
They both are going to have at least some of the technical skill to do these analysis, but they need to understand. The business terminology that your sales or strategy people are going to use, they need to understand what the KP eyes mean conceptually so that they can look at a data set and translate that into an actual mathematical formula, or they need to understand that when a business strategist tells them we need to maintain a certain inventory level.
But anytime we order something, there's a given lag before it hits the shelves, someone needs to be able to take that business story and turn it into a query or something in the data that will help that business person make the decision of when and how much of X do I need to do out in the [00:24:00] real world.
Not on my dashboard out there.
Ian Cook: Bretton, from conversations we've had about your prior life, it feels like you're very much one of those translators. From what I can recall, you have been the person talking to subject matter experts about what they need the data for, but then you take it back and start building that data model.
Are you coming to be a more common kind of person, or do you still find that your role is pretty unique in the world?
Andrew Breton: Well, so Jordan did point out that It's a very common need to have these translators, right? Someone who can do both things, right? You're not on the trading desk, but you are supporting the portfolio manager, supporting the trader or portfolio or supporting that marketing manager for a product because you also have the skills and the technology, right?
And you're not necessarily, they. Data Ops DBA, but you are bridging the gap. So I've been there similarly to communicate with either the risk manager at a large investment company or, you know, a trader portfolio manager and yeah, [00:25:00] translating what they're looking for into the calculations, the precise data that they're going to need.
And then going out and finding it and then performing the technical lift for that. It's interesting, a lot of people, I think a lot of people are in those jobs are probably hoping to move closer towards the front office. I think that it's like a glamorous job to be like the guy on the desk making the trades.
They kind of foresee that as being like where they're hoping to get. Jordan and I have found ourselves just enjoying the technology piece of it more, making the analytics work, making the data work together, scaling it up, deploying it, defining the problem and turning it into code. It's just, it's rewarding in its own way.
So that's where we've ended up. We still have people in our company who perform that task, though they're talking to. Experts in CPG who are defining an analysis about out of stocks about weather trends about consumer analytics and turning that into an analysis, turning it into [00:26:00] code, turning it into a specific query and then delivering it back to them.
So we still work with people just like that. We have them even in our firm who are doing it. They're sort of specialized in the content that we are currently working with, and that will always be a role that is needed. And that's a role that we have here. Oh, that's
Ian Cook: fantastic. We've talked about data sort of at multiple levels here from the raw through the processing systems up to the point where you're going to start modeling it and doing something with it.
If we think about the full supply chain for data, as we refer to listen to episode one, if you don't know that term. The. The piece we've not gotten to yet is the presentation of the data, the sort of visualization. Now often that is not something that people think of as coding, but there is this question I think of, all right, I have a dashboard now.
Am I done? Jordan?
Jordan Kassof: If the dashboard is where you lose interest in the problem, then you're not solving the problem, right? You can't affect change in that business [00:27:00] through a dashboarding tool directly. As I've mentioned a couple of times, everyone has these different software tools that actually operate their business, that actually sends orders to the warehouse, that actually sends stock trades to the market.
And so that is where people can affect their business and actually make a change that changes their bottom line. And so how you go from that dashboard to actually making a change in the real world is kind of the most important part. Everything else is just, to use your restaurant metaphor, it's just chopping and prepping.
All of the ingredients and then someone has to be there to actually assemble it and make a meal and put it on someone's table so they can eat it. The hot terms in this space are data activation or reverse ETL. That's kind of the process, the reverse process of taking data out of your centralized system and sending it to one of these business operations systems.
You could do a whole episode just on that [00:28:00] topic, given how important it is. And we
Ian Cook: very well might. So you're talking reverse ETL, the idea here being I've got some actionable information or things that I think I want to act on and I'm sending it back to the system to make orders, to make changes, to do a certain item.
The thing that strikes me is Knowing what data that is, that needs to be sent back, you can't just take everything that showed up in the dashboard and send it back right away. Breton, in thinking about a dashboard, the step to insight, is that something you can do directly just from any dashboard? Or does something have to be planned earlier than that dashboard
Andrew Breton: step?
Yeah, I'd say like one strategy that people often do is they get a bunch of data and they kind of just try to imagine all the possible views that somebody might need to help make a decision, right? Well, I have this consumer data and I have this weather data and I have this trade data and I have this pricing data and I have these core company fundamentals and one is like make a bunch of slices here and if I make enough of them When somebody [00:29:00] needs it, it'll be here and it'll help them make a decision.
And that's not really going to help you very much because you have a pile of graphs. So true inside driven action starts from the other end. It says, Hey, what question am I trying to answer? Why did this happen? What am I going to do? When am I going to do it? And comes back the other way. So we do this here where we have kind of a very high bar for what dashboards are worth making, right?
And they take a long time to make. each one because they answer a very specific question, a very specific need, and you have to do a lot of thinking to figure out how to finally get to that answer exactly which stores are going to run out exactly when right and why exactly which consumers are. ready to get this message and you know when and why so that's culling down of things and taking and it takes a long time and I imagine that it takes a certain type of organization or business model to be able to [00:30:00] afford to spend that much time to do it so I'm not sure everyone even can so we're doing it here and where we're starting at the end with these very difficult problems and spending a lot of time to solve them and it's understandable that a lot of people don't have time to do that and what they probably do instead is they take this big ocean of data and they just try to churn out as many views as they can so that hopefully they'll be useful.
I
Ian Cook: think that's really interesting. But Jordan, that sounds like a lot of work to get to one insight. Where does the scale come in? Obviously we're a startup, but people who are listening are probably thinking that sounds great, but I can do it once for me. Is there a way to start thinking about this at a larger scale?
Jordan Kassof: Yeah, so I think the way you start to think about how can I do this same sort of analysis across many different data sets, whether that's data providers or, or retailers or different idiosyncrasies, that goes back to the kind of data modeling thing Breton was talking about before, I think. So if you build these insights to run off of [00:31:00] a data model that you've defined, that you think accurately represents, the activities in a certain business, then that makes it so that in the future, when new data sets come in, that are similar, but different because they come from a different provider, they're about a different entity in that space, et cetera, the exercise really becomes, how do I make this new data look like the standard model that we've defined?
And then once I do that, boom, all 20 insights that you've built out are now available running on any retailer or any data provider. There are a lot of idiosyncrasies with every business, and people have legitimate preferences about these things. And so you need to think about how you can. perform this across many different data sets without having to redo the whole thing every single time.
Ian Cook: Excellent. I had [00:32:00] the great fortune of starting to work with the both of you a little over a year ago now. In that time, we've all been tackling this kind of work in thinking through the data stack and thinking through how to move the data and thinking how to get the data to the state where it could be useful for this notion of an insight.
And I'm going to ask this of both of you, so I'll start with Breton, but it'll be the same question to Jordan. What is a lesson that you've learned over the past year that you can summarize or at least give to people who are thinking about going down this route or who want to say, you know what? I really need better insights from my data.
I have tons of data or I know where some data is from what you've learned. What would you suggest to them as a way to start moving forward or at least to unblock them possibly?
Andrew Breton: Yeah, one lesson that I've seen is. that there are a lot of smart people out there that are thinking about similar things. And so if you can find them and use them, you can save yourself a lot of [00:33:00] headache, right?
Just like we use a lot of open source technology in our data stack, right? We didn't reinvent. every tool that we needed to build. If someone out there is trying to solve a particular type of insight, they should go out and see who else out there can help them, right? To solve that, who is already thinking about that problem, who's already spent the time to build out the infrastructure, build out the data model, build out the analysis to do it and save them a lot of time rather than having to build it themselves.
Ian Cook: All right. Thank you, Jordan. How about you? I
Jordan Kassof: would say that, and this has been spoken to a little bit over the course of this podcast, but it's worth reiterating, that a dashboard that someone doesn't use is a school project. It just costs the company money, and it's not adding any value. So the most important thing when you're building these are solving a real business problem.
And so always starting there, what is the [00:34:00] challenge that you are trying to resolve in your business? And then working backwards to a certain extent is really the right way to do it and be impactful. I love building really cool dashboards as much as everyone. Great charts, as long as they're not pie charts, they're awesome.
But you gotta solve a business problem.
Ian Cook: All right. Well, bombs thrown on the pie chart crowd. That's fine. Hopefully nobody's overly attached to those that are listening. If they are, please consult us, write to us. We will disabuse you of the value of a pie chart very, very
Andrew Breton: quickly. This is where we give Jordan's email address so that people can direct their pie chart related feedback to Jordan directly.
Jordan,
Ian Cook: I would suggest starting an entire Twitter account just for angry pie chart commentary. I think people would love that. It would go
Jordan Kassof: viral pretty quickly on
Ian Cook: data. Jordan, Bretton, thank you so much for joining me on this episode. We covered a lot here. I want to thank you for your insights and your time.
And to say [00:35:00] again, I've especially enjoyed being able to work with you. And I think everybody's going to really enjoy having heard what you had to say. I got a little chance to philosophize in there as well. So I certainly don't mind that. Thank you. And talk to you again soon. Thanks, Ian. Thanks, Ian.
This podcast is proudly sponsored by SEEK, the leader in cloud based creation and delivery of industry focused insights. Thanks for listening. If you like this episode, feel free to rate and subscribe wherever you get your podcasts.