Drill to Detail - Drill to Detail Ep. 73 'Luck, Thinking Different and Designing Looker Data Platform' with Special Guest Colin Zima

Episode Date: October 28, 2019

The Drill to Detail Podcast returns for a new season with Mark Rittman joined in this episode by Colin Zima, VP of Product and Chief Analytics Officer at Looker to talk about luck, thinking differently and the deliberate design choices behind Looker Data Platform.JOIN 2018 - Colin Zima Product Keynote - Part 1GrowthHackers.com AMA with Colin Zima, Chief Analytics Officer & VP of Product at LookerHotelTonight - Story of a Modern Data-Driven BusinessDrill to Detail Ep.60 'A Deeper Look Into Looker' With Special Guest Lloyd Tabb

Welcome to a new series of Drill to Detail and I'm your host Mark Rittman. So it's good to be back after the summer break. And I'm joined in this first episode of the new series by Colin Zima. And they many of our listeners working with Looker will be familiar with as Looker's VP of product and chief analytics officer. So welcome to the show, Colin, and thanks for joining us. Thanks for having me. So Colin, just tell us a bit about your role at Looker. Sure. So my role has actually evolved and meandered over the five and a half years I've been at Looker. It's been sort of interesting as the company evolved that my role has evolved quite a bit as well. So I ended up as Looker actually kind of fortuitously. I just happened to be a very early customer of the product. And I actually wasn't even the buyer of the product. So I had started a company coming out of Google with a good friend of mine and a college roommate

who also is now the VP of product at Looker, Jamie Davidson. We started a company that didn't have a lot of traction and ended up deciding that it was best to sort of sell the company and try to consolidate our skills in another business. And we ended up at a company called Hotel Tonight. And through First Round Capital, one of the early venture firms for both Hotel Tonight and Looker, those two businesses were just in the process of getting connected as we were getting acquired. And we actually became, I think it was like the fifth or sixth customer of Looker. So I've been using the product since you had to model in the command line and became very close with the team. Eventually asked, essentially, if I could go work there and joined as the chief analytics officer.

And I had a team of zero. I reported to Frank, the CEO. And it was sort of this person can go talk to other analytics professionals and we'll figure out what we can do with him. So at the start, I was actually managing support and customer success and documentation and analytics. So I sort of built up teams over time and there was no product org at Looker. The engineers were completely self guided in terms of the product that they were building. And it's, it's pretty incredible to think about the work that they were doing, sort of with no formal product management. But eventually, they decided that they needed a product manager, and sort of a product team. And that's when I took over sort of managing the

product org at Looker. And I did that for about four years. And we just hired, I guess, just in sort of late last year, we hired Nick Caldwell to be chief product officer and manage product and engineering and design. And at that point, I mostly transitioned out of the day-to-day product. And for sort of the last nine months have been sitting in what would probably be best described as a strategy role in the company. So less of the day-to-day and product management, though I still bother the team quite a bit on the work that they're doing, but really focused on where Looker's going five or 10 years out. So trying to sort of think about the market and the business and where those things intersect and how Looker could be successful.

And then that gets complemented by a lot of time spent with customers. So I still am sort of out there in the field talking to our customers and prospects about how they can be successful with data. Okay. Okay. So, I mean, the start of the last series, I had Lloyd Tabb on here. And I was curious when speaking to Lloyd to try and understand what was almost the origin story of Looker, to try and understand what was the original problem that was solved. And I suppose, you know, what was the core innovation in the product that meant it's been so sort of successful? And with you, I want to talk about the futures, really. But going back to kind of when you first saw looker and you first saw the product and you

mentioned it was command line and so on there were there were other products out there that were very kind of well built out yeah the business objects of this world and so on what was it that appealed to you what what what did looker do for you guys that meant that it was that was what you chose and that was the thing that you, I suppose, in a way, selected for your company, but then selected for your career. Yeah. I think the most interesting thing about Looker was sort of these original core bets that the company has that have guided us through the entire lifespan of the company. I think it's probably somewhat rare that you build a company on a few core assumptions. And over a long period of time, those assumptions just do not change and if anything, sort of strengthen. And I think

when Lloyd built the product early, it was a product that he built internally at another company previously that he sort of spun into a business. And I've seen actually plenty of analytics tools even that have done things like that. I think Mode was a version of that from Yammer, for example. But the core things that Lloyd saw, I think, just aligned really closely with what the market needed at that point in time. And that was a technical product for data people. And you've had people on the podcast before that have talked about this sort of concept of analysts sort of moving closer to developers than business people. And this sort of desire for a more code heavy, more powerful platform was really appealing. So

being in the command line was just sort of normal if you came from data science, because that was a place that you were already working. So it was a lot of these natural extensions of the more technical data analyst. And then I think the bet on SQL was another huge one. Like philosophically for me, I had a little bit of exposure to BI tools. Actually, probably the tool I had the most exposure to was Excel because I was in structured finance even before I came to tech. And I think what Looker did well was it had a very straightforward application of how you get data into a screen on a computer on the internet. And it wasn't sort of pull your data, manipulate it into some sort of cube type thing or some sort of intermediate. It was go write SQL and it shows up in the browser.

And I think that really short trip from the database to the screen was one of the huge advantages of it because I think for any given user, it was just a very simple concept to understand and sort of that simplicity that underlies Looker, that I think it's hidden a little bit by the data model, where people think it's complex. It actually is sort of the shortest path to take something out of a database and put it on a screen. And I think that is what Looker did really, really well. Yeah, interesting. So when we're getting, there's a huge amount to talk about there. And I suppose particularly that I suppose that that I suppose that balance between, you know, I mean, my background was in doing SQL based, you know, BI tools on top of kind of databases, particularly Oracle. was a challenge and and what might be a simple series of sql statements required an awful lot of i suppose optimization and structures and indexing and materialized views and all that kind of stuff there and and you know and then to try and replicate that across multiple day spaces would

be hard but i guess you guys you know you were there at the time that the actual database market changed when i guess it was more of a service than anything else and and and you know probably a very kind of happy confluence there of technology trends and the approach you guys bet on that work really. I mean, is that kind of broadly how you see it really? The luck in timing just can't be understated at all. Like even thinking back to my time at Hotel Tonight,

we were connected up to master the transactional database when we started using Looker. And I remember actually taking down the app for 30 minutes, writing a poorly structured SQL query. And that's when we started setting up sort of transactional mirrors. But when we were using MySQL to start, even kind of one year into really building out our Looker model, we started getting stuff that was too heavy for that database. And if Redshift and sort of these easily adoptable cloud databases hadn't appeared, I'm not sure that Looker could have continued to be successful just because the volume of query, that's not what transactional databases were really built to do, do analytical query at scale. And so I just, it's so important that this bet on the database market just being simple and fast and sort of doing all these things behind the scenes to solve problems so that Looker could just focus on everything upstream of actual query. That is as important as everything that we've done as a

business. So the Snowflake, BigQuery, Redshift, the growth of that market was as important as every decision that we've made as a company. And that's like the luck side of businesses. You need to make a good product, but you need to get lucky a little bit as well. Yeah. Yeah. I mean, I saw you say lucky. I mean, obviously it's a very sort of prescient bet, to make a good product but you need to get lucky a little bit as well yeah yeah i mean i said you say lucky i mean obviously it's a very sort of prescient bet really i mean the other thing for us is in in the business that i first encountered looker we we they were originally using say tableau but that was actually no longer an option for them because by you know if you use a database like say bigquery and you're doing things on a kind of column based approach and you've got huge

volumes of data you know you can't just load it load it all into a mid-tier cache. And so actually, we were kind of, we had no choice but to use Looker in some respects. So it opened up an opportunity. But then obviously, from that point onwards, I mean, you know, there's luck, but there's also execution as well. And I think that people get a chance. But I mean, just taking a step back before we get into the detail of Looker, I mean, what was, where did your interest in analytics and data come from them originally? Yeah, I mean, I think it, for me, it was just sort of a natural inclination that if you can answer a question with information, you're going to do that. Like I started in structured finance working on synthetic CDOs. So I was on just the other side of the world, but essentially just doing applied math and sort of fortuitously

decided to test out tech at Google as a statistician as the financial markets were blowing up. And so- I was about to say, that was probably good timing. So lucky. I just can't even explain it. But I left structured finance in 2007 and ended up at Google as a statistician in search. And I think ultimately, I just see applied math everywhere. Like, if you have information, you can use it strategically to make smart decisions.

And to me, that's what analytics is. And I think the real appeal for me and sort of the way I try to hype sort of young data analysts is I think if you understand how the business is working as a data analyst and view yourself less as a reporting engine and more as sort of a powerful driver of a business moving forward. Because you're when you understand how the business works, you can you can drive the business moving forward. So that's sort of what drew me to analytics is that, like, when I'm at Looker, and I was sort of the main analyst for a while, like, I know how every aspect of the business is working. And if you care about making the business succeed above the specificity of your job role, analytics is the most interesting place to do that because you have the keys to the car in that you can see everything that's going on, which gives you the power to influence what's going on. And so that's like really what excites me about analytics is it's, it's the superpower for managing the business because you can see everything that's happening. Interesting. I mean, but, and the other role you do is, is, is your VP of product role. And, and, and yeah, I suppose an interest in analytics and an interest in the domain area doesn't necessarily

make you a good product manager. And yeah, I mean, I've worked in that area and I think I did okay. I mean, I think I was brilliant. But certainly, you know, product management itself is obviously a skill in itself. I mean, where did your interest in product come from really? Yeah. Was that kind of just you fell into it or was that a deliberate thing? No, I mean, I would say I fell into it. My views on product management have evolved pretty significantly over my time at Looker because I still, when I talk to people, I still say I'm not really a product manager. I'm a data guy that happens to be working on the right product. So I'm not sure how much of product management you can sort of pick up and transfer to a

completely unrelated service. There's multiple aspects of it, though. And the most important one, I think, is just understanding your customer and your user. And so at Looker, it's very it was very easy for me to think like a product manager, because if you're thinking like a user of the product and you're thinking critically about what the product could do and what the product should do, and you can empathize deeply with the user of the product, that's what's going to make you a great product manager, because you're trying to understand what the user's problems are and solving them in sort of intelligent ways. I think where analytics practitioners get into a little bit of trouble, and this is something that I think Lloyd and Ben did an outstanding job of at the early beginning of Looker, is I think if you take all of the assumptions and constraints of what a product or market does and sort of take them as a given when you're building, you can get stuck sort of

repeating things and sort of staying at a local maximum. And what Lloyd and Ben did really well was sort of very intentionally not look at the market at all. They sort of said, we're not going to look at any other products in the market. We're going to completely reinvent everything. And just to be clear, like we are, we do not do that anymore. It's really important to learn from your competitors. But I think having that balance of not having to follow everyone in the market and kind of completely doing your own thing and sort of preferentially learning from the market, I think those are the product managers that really do the best. Because if you're copying it, trying to apply it to what you do is not going to work. And if you're trying to rebuild it from scratch,

you're not going to borrow from the lessons that you've learned externally. So it's really this confluence of just learning from all the things around you and trying to understand what's going on. And the last point I'd make is, I think exactly to what you're saying around data, certainly if the product that you're managing is something like a checkout funnel, being data-driven is important because you're really just trying to drive some sort of

conversion rate up. I think in most contexts, overusing or over-relying on data is a huge mistake that product managers make because the data is only going to tell you exactly the question that you're asking for. And the more important problem that you're trying to solve is sort of, is the user's life better? And is this the right way to solve the problem? And you don't really get the negative space when you ask a data question. Like you don't get the alternative. You don't get all the hidden variables that you can't see. And so I think it's really important that product managers don't get too caught up

in trying to have numbers guide everything that they're doing. You want to use it as an input, but it really is just that. It's an input. It's not the answer. Yeah, definitely. I mean, that's actually a topic

I was going to speak to you about. I mean, to what extent do you use data to drive your product decisions, really? But let's kind of i mean i think just to i suppose to summarize where i want to go with this conversation there's two things i wanted to talk to you about one was um your philosophy around the building of looker so and and i suppose in a wider sense around building a product so i think we're all touching on that which is fantastic um so you know i've i've heard you speak at um at keynotes and i've

heard you talk about um about thenotes and i've heard you talk about um about the way that you uh the way that you thought about the product recently and you access analytics and action and so on there and use that as maybe a starting point but then what is driving what is driving how you think about where looker should go in the future and and i'm not i'm not really interested i mean i know there's obviously things you can't talk about it's just commercially sensitive but uh but but yeah. But the way you think is what I'm interested in, really. You know, I think that for me is interesting. And then, I mean, there have been a few things that have been announced in the last 12 months with Looker that probably people aren't so aware of.

I'm particularly interested in around things like where you're doing aggregate management and so on. And just in general, there's been some interesting features there, which I think would be nice to touch on as well. And let's kind of start off then. It sounds like a bit of a stalker here, but I saw your keynote session in London where you were actually attending a keynote. It's not stalking, is it? No, it's more education. But you talked about access, analytics, and action as three words you used

to describe how you thought about the product. Let's take a step back. What led you to that presentation? And what were you kind of, what was the message and the story you were trying to tell? Yeah. So I think a lot of these just, again, fall back to sort of those lifecycle of a piece of data where you've got all of these source systems producing data. And some of them are these SaaS products. Some of them are your business systems like event collectors. Some of them are transactional systems. So you've got lots of things that are recording information. And ultimately, getting that information into people's hands

is sort of job number one. And I think this is sort of one of those interesting, I don't want to call it a mistake, but I feel like the making data available was sort of trivialized by sort of the analyst market, like the Gartner Foresters of the world, where sort of getting data into people's hands, like, of course, that's easy. Like, let's talk about AI and machine learning. And I think one of these core insights that Looker has was just getting data into people's hands and making them understand it actually is a hard and important problem. And simplifying that pipeline is like the most important thing that we can do. So we have all these philosophies about sort of getting data at low latency into a

database. Again, sort of like thinking like a developer, microservice architecture, where kind of small products are moving data around and then little products are sitting on top of that. So it's sort of like the five trans stitch low latency ETL services are getting it into a database. The database is making it accessible at low latency and fast query. The model sits on top of that and describes the data. You've got other concepts that sit on top of the model, like merge results and calculated fields and all these different things. And sort of at each layer, you're massaging the data a little bit. So the ultimate thing that you're putting in front of a user is something that they can understand. And that's sort of what we think about as that analytics layer.

And that's everything that the analytics market seems to talk about. But it's doing analysis. It's reporting. It's all of those different pieces. So it's sort of get a supply chain for getting data in front of people is step one. And that's an independent problem from doing analysis and reporting on data. And sort of at that layer, I think the important thing that we're thinking about as a company is probably best described as just trying to move beyond the dashboard. So we've had this message internally about sort of what we call the spectrum of analysis. And I think this is another one of these concepts that isn't captured by the market yet,

but I think in five or 10 years will become more commonplace where if you look at the way that someone consumes data now, and this could be in Looker, this could be in any sort of product or in any sort of context. On one end of the world, you've got sort of like SQL and pivot tables, where I would describe that as sort of a blank canvas, where someone that understands the data and the structure of data can ask questions. You can do anything. You essentially start with a table and you end up with another table. And then on the other end of the world, you've got a dashboard. And what a dashboard is, is sort of a highly constrained experience where you can ask a very specific set of questions and the structure is predetermined. And when we see users try to consume data in Looker or in other products, I think what we've

been learning is that there's a lot of white space in between those two sides of the world, in that the ways that people want to ask questions often want to be more guided than a pivot table, but they want to be more open than a dashboard. And I think when you use sort of data products in the world, this is sort of obvious and natural. So when you buy a plane ticket on united.com, you're not doing a pivot table on top of every flight that they have. You don't get a blank canvas, you get a highly structured interface

to ask a question in a very specific way. And the way that results return and sort of the workflow built on top of that result set is highly tuned to what the user is doing, which is buying a plane flight. But when you look at sort of the BI space, you're really constrained to be either in this single page dashboard UI or on top of a pivot table. And so I think in that middle layer, the strategy that we have as a company, and we're sort of working on a lot of the sort of back end concepts and middleware concepts and front end concepts to deliver out sort of these more opinionated, more custom data experiences. So like examples that I think of in sort of the analytics world are like cohort analysis is an incredibly common type of analysis. And a pivot table person can go

build a cohort and you can make a dashboard that has a cohort on it. But there probably is some middle that is a complete UI that revolves around doing cohort analysis that's even better than both of those versions of the product. And I think those mini applications are really where analytics is going to differentiate, where the UI and the data are sort of interlinked in a way that the product is designed for the specific need that the user has. And so I think a little bit of what we're trying to say is sort of moving away from generalized analysis to sort of more specific user experiences. And then that third piece, action, again, I think something that the analytics market in general, I don't want to say has ignored, but it's been like a problem that's been hard to solve

is after you do an analysis, often the output is like a picture or a PDF or something like that. But to go back to sort of what I was saying earlier about data analysts and their role in an organization, like really what you're trying to do is make the business better. And the ways that you make the business better, there's sort of two versions of data analysis. One is just to inform yourself. And that's like, is revenue up or down this week?

And the other, and probably the more important one is to go make a decision. Like, who am I marketing to? Do I need to change the people that my sales teams are talking to? Who is most likely to churn? These are all So the reason that someone would do a sales analytics report is to make a better decision about the next person that they're talking to, or to move pipeline around, or try to understand how to allocate leads better. And so we want to go from just delivering you a report that says, these two sales reps have too many leads, and these two sales reps have too many leads and these two sales reps don't have enough leads to a place where you can actually go reallocate those leads. And whether again, whether or not that's called a dashboard or not is sort of less important than taking all the work that you're doing to make this data accessible and analyze it and put it in front of people

to actually taking the next step to go do something. And that's where being sort of web native and connected to other things and sort of have this microservice architecture where you can just hook up to APIs and use them really seamlessly. We can be very different than the space was before and look more like an application experience than sort of a visual consumption thing. There's a lot in what you said there. And let's, I mean, it's a huge amount of talk there. So let's kind of go back to access first of all.

Okay. So I suppose the LookML model, the kind of the metadata model you have, I guess that's probably within that kind of access layer there. And so that for me, when I saw Looker a few years ago, I mean, for me, it immediately dawned on me, this is, you know, you're reinventing the business model for today's audience. You know, it was a lightweight version of the things I used to use before. But it was in alignment with how people do things now and it was introducing reintroducing this idea to an audience that at that point was you know using very fragmented tools and and was trying to do this maybe with sequel views or whatever i mean there so there must have been a so but look amelie and the way you do things is still i suppose

deliberately um limited in scope compared to maybe the kind of models I used to build that would have maybe sort of multiple layers with hierarchies and so on and so forth. Was there a deliberate choice on your part to go so far and no further? Or is this something that you see is just maybe, you know, a case of just building on this and you're going to take it further? Are you done with Le Camel or is it kind of, you know, or is it just a stage one? No, I don't think we'll ever be done. So, but like the direct answer is sort of yes and no. So again, I think sort of one of these, whether it's lucky or sort of predictive or sort of

whatever it might be, decisions that we made was, I think one of the things that Lloyd did an outstanding job with was making LookML accessible. And when you look at our data model compared to sort of earlier versions of data modeling or sort of more powerful, more complex versions of data modeling, I think the things that we haven't done at times sort of operate like features because the product is very adoptable. For as much heat as we get about sort of modeling being hard, I think we have done a very good job of taking somewhat complex concepts and really creating a very simple way to model data, especially if you know SQL. And so from that side of the world,

I do think we want to be really careful about injecting complexity in a way that is required to be successful with the product. We still want it to be adaptable and simple. I think to your point about creating more power, there's always this endless march to add features to a product. And so I'd be naive to say that we could somehow stop ourselves from adding each net new feature. But I think what we are trying to do is make sure that when we add those things, they don't get in the way of using the model in the basic and simple ways that a user in 2015 might have done. So I do think that we'll continue to add sort of multi-pass query and sort of more complex concepts and things like that. But what I'm trying really hard to sort of drive into the team and drive into our way of thinking

is we want it to be simple and easy to use as well. So to sort of pick an example off the shelf, like PDTs are one of the most popular concepts in the Looker model. You can write a SQL statement. It really is as simple as saying, here's a SQL statement. I'm going to make this a table. And then it gets treated like a table in the system. And you can put persistence on it if you want, or you cannot do that. And we'll build it on the fly. And what's so magical about it is that it's completely trivial to add a view into Looker that looks and feels to an end user just like a table. And the magic of making those things quickly and easily is why it's so amazing. Now, the converse of that is that if you want to manage those with proper life cycle management, do all the things that

DBT is doing on top of a PDT, suddenly that simplicity is a disadvantage. And when I want to go harden how that thing sits in the data model, there's a complexity cliff. And I think what we are trying to solve is how can we still make things incredibly easy to use and adopt, but then give you a migration path to harden that thing, test that thing, promote that thing into a true lifecycle. And so I think that is where you're going to see the model evolving. And that is how we can create complexity and create sort of this richer data model that

can do things more powerfully and scale up with your business to be the full lifecycle management product for all the tables in your database without saying that this new developer that wants to go build a table immediately can't go do that instantly without understanding all of those concepts. So I think that's the balance that we're trying to strike. Someone said to me in product management, the difference between being a consultant and a product manager is as a consultant, you say yes to everything. And as a product manager, your job is to say no to everything.

It's so true almost everything and and i think that that that that ability to sort of like be selective in what you put in and not over complicate things is is is kind of interesting i mean on that topic as well it was actually i'd recorded an episode with uh so called bud andres last night from oracle who who is the person responsible for the in the in database aggregation and OLAP engine within Oracle. And we were talking last night about how hard it is to, I suppose, if you're building a tool that does query multiple databases like Looker does, to make sure that performance

on each of those is good. And I think that I'd be interested to see your thoughts on that. But also, something I've looked at with interest over the last year is some work you guys are doing to add some form of aggregate management or aggregate navigation into Looker, which I think is an interesting, I suppose, balance between handing it off to the database and realizing there is something in there that you guys can do, especially if it's an easy to use way to make it so aggregates can be hacked. Just tell us how that's working or what your thoughts are in that sort of area.

Yeah. Yeah. I mean, actually it parallels back to that PET conversation a little bit where I think, again, the thing that we are trying to accomplish in almost all contexts of the product is create this very

simple, gentle path from easy and fast to robust and kind of hardened. And so what I mean there is Looker hooks up to your database trivially, and we can generate a model on the fly, and you can start asking questions about the database. And as you start building out the data model and building PDTs and other versions of aggregates, an intelligent owner can sort of curate the product experience around things like performance and things like that. And I think the natural evolution of that is sort of to exactly what you're saying, where if I have large tables and I can build aggregates and maintain them, of course, I'd rather go ask for daily active users from the daily active users table rather than hit my five billion row event table. And sort of all of the nuance around that problem is how do I build and maintain these aggregates in a way that the system is cohesive? And so sort of the converse of that is,

I think a mistake that a lot of the market has made is sort of this separation between views of data and the underlying data itself. So as soon as I need to move data around and extract it and optimize it, and it gets completely sort of denatured from the raw data itself, you start building these cliffs where trust in the data might be compromised. And so when we look at the problem, we are hooked up to sort of what I would consider live data. So the data in the database, and of course, lots of the questions that you're asking

don't necessarily need to care about live data. You're asking about users for the last 30 days or sort of anything like that. And I think what that means that Looker can provide is we can understand how you're using data in the system, what dimensions and measures matter, sort of what sort of aggregates and granularities are people looking at data for. And in so much as you're using Looker for all this querying, we can go build and maintain these aggregates where I can look at the fields, the types of questions that you're asking, go build those and persist them in the database and actually tie those aggregates and the caching mechanisms in those aggregates to the data pipeline that you're using. And so really what I'm trying to say is we

have these concepts called data groups, where a data group represents sort of a cache expiration mechanism in Looker. And very commonly, you're working with some sort of semi-batched data set. And data lands once an hour or every 15 minutes or something like that. And you can actually build and explore. So a view of what I would call the semi-live data, this raw data that is tied to that ETL pipeline. And now we can go start building aggregates on the same cadence. So we can understand what the questions that people are likely to ask are,

and we can know that we have sort of the most recent version of that data, and we can go persist those views into the database. And then really, it's just a matter of routing queries intelligently between these aggregates and the raw data. And for those sorts of pieces, we are fortunate to have some very experienced developers around a lot of these topics. So Julian Hyde has been leading an implementation of Calcite into our product that was built to do just these types of questions, to essentially make intelligent decisions about how SQL is generated and how we can reroute queries to aggregates. And so our multi-step version of aggregate awareness is first building these aggregates

like PDTs in the model. So give me a list of fields, I'll go build those aggregates. And then when a user is exploring data, we essentially just have a query optimizer that sits above the query optimizer. And we can set these to the same cache frequencies and things like that. And we can just go hit rollup tables instead of raw tables.

And it's seamless. Sort of V2 of that would be letting you bring your own aggregates. And I think we'd love to get to the point where you could even be using a column in your database sort of paired with a row store. Who knows if we'll actually get to things like that. But again, we're just talking about a query optimizer

sitting on top of a query optimizer where we're working with higher order concepts than the database itself. And the whole idea is that we can take all of the query that's happening and make it seamless to the database. Okay, so I mean, I suppose a meta question on top of this really is,

so this is a feature that, I mean, I've been waiting for this for a long time and particularly, I suppose, enterprise customers would find this of interest. How do you make it, in your role as kind of VP product? How do you make decisions about how you prioritize what's going to go into the product? Because this is something you've obviously invested a lot of time in, but there's other initiatives as well that you could do.

I mean, there's things like, for example, broadening adoption of the product or there are, you know, how do you make those decisions really? And again, what is your kind of guiding philosophy on where you spend your, I suppose, notional kind of points of development really on the product? Yeah. So it's evolved over time, actually. And the thing I would tell all the product managers listening is just,

there are very few right answers to this. They're just philosophies and they all come with trade-offs. So kind of early in Looker's life, we used what could best be described as sort of stack ranking all of the features that we could possibly work on. And we just worked off of them in waterfall style. So a feature in backend modeling would compete against a new viz type. And we're just sort of licking our fingers, sticking it in the air and saying, this one's more important than this one. It was heavily based on sort of the instinct

of the product manager and the product team. So design and engineering as well. But as we've grown, I think we've sort of approached something closer to a portfolio theory style of product management in that we have major areas of the product and we believe that we need to allocate investment across all of them. So that action analytics insights like all those different pieces, but effectively the modeling layer, the middle of the products are

sort of the components that build front end experiences and then the front end experiences themselves. And then inside each of those teams, we're sort of decomposing the problem set that they can work on. So we've allocated some set of engineering product and design resources to the modeling layer and transformation and all of the products in the IDE. And by allocating engineers, we're sort of making a decision about the relative importance of different areas of the product. So you sort of constrain the comparison decisions that you need to make. And then a product manager in that area can sort of make the decision about what's most important at any given point in time. And sometimes that's new features, and sometimes that's performance, and sometimes that's sort

of bug cleanup. When it comes down to it, it's impossible to try to allocate revenue or customer happiness or really anything to sorts of features. And this goes back to sort of having to rely on instinct, but sort of balancing either this portfolio theory where you're allocating people at a high level to a set of decisions, and then inside those decisions, they're allocating resource versus allocating resource across the whole company lets you sort of make decisions at different levels to allocate resource and time. So we might have 20 engineers in the model and 20 engineers on Viz and kind of, you can more instinctually say, hey, Viz doesn't have enough resource. So the next three engineers that get hired are working on Viz and now you're 20 and 23. It sort of prevents you from having to compare building a waterfall chart to building folders

in the IDE where you can't really parallel those sort of efforts and yields. Okay. So how much do you, I mean, you say you worked at Google and I guess one of the kind of, one of the most characteristic parts of how they work is it's the engineers have a lot of say in what's built really. And, you know, product managers often are more influenced than top down direction. I mean, again, how much of the product is kind of, you know, inspiration top down kind of direction, how much of it is comes from the engineers? Because I suppose the danger with doing it all spreading your kind of resources across everything equally is you end up, you know, you might miss that kind of what you are, how much of it is bottom up? How much of it is top down? Yeah. It's a good question. I think, I think we've sort of gone through phases as a company. So very early in the product's life, it was entirely bottoms up engineering driven.

Very literally, it was what any given engineer wanted to work on or was important in the product, and it was entirely organic. And I think when I took over the product team and sort of the product org, and we created a product org, we swung very far in the other direction, where we became kind of much, much more top down product driven. And it was more waterfall-y, and it was almost kind of instruction from the top. And I think we've swung back pretty far in the other direction towards sort of individual teams. And those teams are built from engineers, product managers, and designers. And those teams are driving the work that they are doing in their area sort of collaboratively.

And there is a top level overlay that says kind of, hey, these are important problems that we're going to work on. So constrain your thinking to this area. But I think generally it's coming more from the bottom up and that sort of necessarily needs to happen as you scale. But to sort of product versus eng, I think ultimately we're an engineering driven company. I mean, we have two engineering co-founders. And if you've ever been to join, for the listeners, I know that you've been, you know that when we announce sort of model features, even obscure features in the IDE, those get the biggest uproar over kind of new viz type and things like that. And so ultimately,

our customer is looking for a lot of those technical products. And that's okay. So the other end of what you're talking about was, was suppose access really not access sorry it was uh action and analytics and and and i'm i'm conscious of time and i can't keep you all day sort of thing but it was i'm interested in the in i suppose you know how this in how your how your product is then turned into applications how it interacts with applications and how you make it actionable and and i mean when i was at join last year there was was talk about the applications you're building, which were, I think at the time, there was maybe JavaScript extensions to things.

And obviously since then, there's been Action Hub and so on. What's going on around, what's your strategy around how you, I suppose, integrate with people's workflows and try to avoid that issue where, you know, I think with a dashboard, a dashboard is almost the worst way to deliver analytics because you have to kind of stop what you're doing, go to another application, you know, ask a question. The more that it's embedded in a workflow, the more it's relevant. What's the kind of you're thinking there and where do you see things going? Yeah. I think this is a great example of

a problem that we know that we want to solve that we haven't completely figured out yet. So you're familiar with the Action Hub. And I think it's this resource that we released that effectively lets you hook up outputs of Looker queries to other APIs. So it lets you pass a result set or a data point or something like that into another service that does a thing. So it effectively creates pass a result set or a data point or something like that into another service that does a thing. So it effectively creates like a CRUD interface into Looker. And I think when we released it, we said, hey, this is an open framework, kind of do whatever you want. It'll be amazing. You'll go build great stuff. And truth be told, a small number of people have done

incredibly interesting things with it. They've built kind of true workflow into the product. But I think what we also see is sort of exactly to your point that trying to jam a small action into a dashboard often feels pretty unnatural. And so like, again, thinking about thinking back to sort of that dashboard versus explore sort of experience creation piece. I think what we did see was when we build more opinionated thing, not sort of an open analysis framework. Those were the people being very successful at the Action Hub because the action itself was deeply tied to the user experience that was built in Looker. And I think what that means for us moving forward is when you just go drop a big complex framework that can do absolutely anything into a product,

you're going to find power users. And often it's folks like you that actually are thinking as hard or harder about the product than even we are internally because you actually have to go deliver it to people. They're doing interesting things, but if we don't go the last mile and really show you the types of use cases and deeply integrate those use cases so rather than delivering a Marketo action that

builds lists we need to go build a product or a product experience that lets a marketer build lists and send them to Marketo that isn't the explore page. And I think that is what you're going to try to see us do in end of 2019, 2020 into 21, where we integrate the UI and the analytics experience with the action that you're taking and the things that you need to do downstream. And so I generally just feel like we have all of the pieces, but again, like delivering a bag of parts is great if you're delivering a developer platform. And again, this is where like consultants and partners do amazing things with the stuff that we do often better than the stuff that we're doing. If we want it to be

there for every single user, we need to go take the next couple steps to deliver more complete experiences. And that's where I want marketers to start using our product and not have to jump to Marketo because the integrated experience that we deliver on top of their data is so much better than what they'd be doing in that other product. And on that point, really, I suppose, again, in my time as a product manager, something that I was thinking a lot about was how do we, you know, you can present people data on what's happened, or you can start to be more prescriptive and more predictive. But then we get into the kind of the world of AI. And every product has to have an AI element. But I've seen with Looker, it's almost like kind of deliberately you've not gone down that route or certainly, certainly it's not been something that you have

been talking about a lot. I mean, so, so where do you see, I suppose, automated I suppose, where do you see that going really? And where do you think there's an area that a problem that Looker could solve and what's your views on, on that kind of sort of thing? Yeah, to your point, we have very literally tried to avoid things like that in the product kind of to date. And I think the reason was we have viewed ourself as a platform. And if you're a platform, you are not trying to make decisions on behalf of your user. You're trying to give them a framework so that they can make their own decisions. And I think, again, this is a recurring theme in the conversation, but what we've learned is that works if you're buying and

you want to use a platform. It doesn't work for a large swath of our users that want to use an application that helps solve problems for them. And so I think where you're going to see us building a lot more intelligence into the product is more productized experiences that use things like AI, ML kind of intelligence. And so an example of that might be something like outlier detection or forecasting, but modules in the product that are opinionated and tailored to a business problem that can use those resources in a way that's much more directed. Ultimately, my belief and my background is in data science is that us trying to be a data scientist is probably a losing battle because data scientists

are really smart and sort of understanding the problems that you need to apply data science to is as hard as the data science framework. But if we can take that first step and understand the right places to use data science, so some sort of image detection product or, again, forecasting, outlier detection, productize use cases that use intelligence. We can go build, again, more opinionated experiences that go solve these problems. So we could go build a churn forecasting model, but we don't want to hand a customer support rep or a customer success manager generalized AI. We want to hand them a churn forecast. And so I think it's our responsibility to try to productize these experiences a little bit more tightly if we want them to be adopted by a typical end user. And then of course, we want to give our developers and sort of the platform owners kind of extension points to add in intelligence. But I think the application sort of experience is probably the driving place that you'll see us doing most of that.

Okay. Okay. Just to round things off, really, I mean, it's joined very soon. It may well be after this episode goes out. But just maybe, again, without giving away too much of what you're going to talk about, but in terms of, I guess you're doing a keynote. I mean, are there any kind of themes that you want to be talking about or things that maybe people start thinking about in advance before they come along that you'll be kind of echoing or kind of raising really in your talk? Yeah, I mean, I think the biggest one moving forward is really this idea of application experiences

and sort of deeper, richer user experiences that are directed. Obviously, we've got a whole bunch of announcements around sort of more tactical features. So we're doing a very major rebuild of our dashboards to sort of improve performance and componentize the experience. All of that is in service of essentially taking Looker and breaking it apart and trying to build and deliver.

And that means we build or also customers build or partners build user experiences that can solve problems more easily for business users. And a lot of the theme of the things that we're building are taking Looker and really trying to break it apart in a way that we can deliver a product experience that doesn't feel like a dashboard or a pivot table. And I am incredibly excited about the potential that that gives us. And it's going to be like a multi-year journey that we're going to have to take people on that's going to feel a little bit unnatural. But I think when our customers and users and when I go out and talk to buyers of Looker, I really want people to stop thinking about everything as a dashboard and trying to deliver data and try to think about what an ideal user experience is to solve a business problem. a marketer make their ad spend better? Or how does a customer success manager deliver a better

customer experience and reduce churn? And what are the right user experiences and sort of UIs to do those sorts of things? And sort of helping us walk along that path with them. So a great example to maybe give away a little too much from Join. But as part of this application framework, we can sort of very quickly build and deliver sort of full UI experiences that are hosted in Looker built on top of Looker data. And we actually had one of our developers go out and build what I would consider a pretty fully fledged data dictionary in a couple of weeks. And he's been building and maintaining it, but we've almost got a standalone data dictionary product that we can start delivering in the application. And I think when you start seeing

the types of things that we can deliver through this application framework, it really opens your mind to what Looker could do. And I want our customers to sort of pull us down that path and sort of figure out the things that we should be building. So when you ask that question about AI, I would love for them to lead us down those things that we need to be doing and should be doing. Interesting. Fantastic. Well, I remember that being

trailed as a new area last year. So it'd be interesting to see kind of where that's going. So that's fantastic. There's a million and one things others talked about, talked to you about, but I'm conscious of time and it's been fantastic speaking to you. So yeah, well, Colin, thank you so much for coming on the show. And it's really interesting to understand the philosophy behind the product. Appreciate you doing that. And take care. And hopefully I will see you at Sort of Join. Have a good couple of weeks.

And thank you very much. Yeah, thank you so much for having me. This was a pleasure. Thank you.