How to leverage intuition, customer support, and raw effort | Colin Zima (Omni & Looker)

Brett Berson: Colin, I'm excited for this.

Colin Zima: Me too.

Brett Berson: So why don't we kind of start the conversation with sort of your last chapter, which was playing a whole host of different roles at Looker and maybe to kind of give a little bit of context, you could talk about how you originally got connected with the company and maybe your sort of different roles or chapters with inside that long journey that you had at Looker.

Colin Zima: Yeah, sure. So I guess the brief life story leading up was uh, started a company actually with one of my two co founders at Omni. We ended up selling it to a company called Hotel Tonight. Hotel Tonight ended up being Looker's fourth customer. And actually it was not due to me, so I can take none of the credit for finding Looker.

 I believe it actually came through the first round network, via the CTO of Hotel Tonight. But we landed at Hotel Tonight. And Lloyd had just implemented the first data model for Looker. And I think that we showed up and Jamie and I are both kind of very data people. And Lloyd just got so excited because he was like, okay, great.

Now I've got like a super user at this company. And uh, we just ended up loving the product as a customer. So I think both of us were doing like background calls and things like that, but essentially trying to like soft sell Looker as Hotel Tonight employees. And then eventually I was sort of just to Lloyd and Frank, who is the CEO, just said, you know, Hey, I love this product.

I want to come talk to more data people and do anything that I can to help it be more successful. And so I actually joined Looker with the title of Chief Analytics Officer, reporting to Frank. And he sort of was like, I don't have, I don't know where I'm going to put you, but I think that you can be valuable.

And so I started by just trying to sort of figure out what was, what was working and what wasn't. And I actually went and tried to visit every single customer and there were about 70 at the time. And I think I got to, I think by the time we got to a hundred, I had visited 75 customers in person. So I was doing this sort of like, you know, field CTO style customer success.

It was sort of just a, like, this guy knows what's going on. He can go talk to people and figure out what's. What's working, what's not, like how to make the product better. And then I was just sort of offered teams over time. So it started with support and customer success.

Brett Berson: Colin, as you were getting ramped just before you continue on, how did you spend the time with the customers? Was there anything you did that was particularly useful or it was just kind of more open ended, what do you think of Looker, what are the rough spots, those types of things? 

Colin Zima: I mean, I wish to say I had like, I probably got a script slowly where you'd go in and you talk about the problems that were focused on. So it'd be like a soft road map. But really, it was just like a, hey, can you show me how you're using the product? And it wasn't sort of like show me superficially. It was we really tried to actually get into the things that they liked and disliked about the product and sort of what was interesting, who was using it. Um, I, I mean, I wasn't in product at the time, but I sort of now in retrospect, appreciate it as sort of like customer discovery from current customers. It was just really understanding, like, is it good?

And do customers like it sort of superficially, but they're using it wrong, or are they actually using the product like the way that we intend it? It just sort of helped us get an understanding of sort of, was the product actually transformational and interesting for companies, or was it just like another data product that we were selling really effectively or something like that?

So, I mean, I was, I was trying to take feature requests and things like that, because I, I think that gets people talking. Like people that live in the product all day love to talk about the things that could be better or worse. And I feel like if you actually listen in a very engaged way, they'll tell you even more.

So almost like getting feature requests and sort of feedback is a good indication that you're very close to the customer. And so it was really, it was more just actually being curious about the types of analytics that people were doing. And, you know, like we wanted to do some content marketing. We wanted to improve the product, but it was just really going and actively listening, and trying to understand how people were using the product in good and bad ways.

Brett Berson: So what was interesting about that? Or as you got deeper in those customer conversations, what was sort of clear given still, this was long before Looker was like an obvious, you know, uniquely great company. 

Colin Zima: The unique advantage that I think I had, was just that I was a super user of the product. So I had like a very strong point of view over the, the proper way to structure a model and sort of how to onboard users and sort of the, the right way to use a product, quote unquote, which is like.

For a platform, I think if you have a really, really tight piece of application software, I think that you can heavily guide a user and there's kind of only one way to do it. Like you go to Airbnb and either book a room or you don't book a room. There's, there's one way to use the product. Looker was sort of this coding layer where you could do anything.

Like you could use it in horrific ways. You could use it in like incredibly elegant ways. And Lloyd would always talk about like these emergent behaviors. Like people would just figure out ways to do stuff that you hadn't predicted. And so I think part of it was just trying to understand, like, what the heck are people doing with the product?

 And I think back to sort of the question, which is like, what did we see? Everyone was sort of like reflecting the same value prop in the product. And I think that is when you know that you're doing something really special, in terms of like company building, is when you hand them something that can be used in a lot of different ways.

And a lot of people are sort of circling around the same types of ways to use the product or the same sort of magical experiences in the product. And so we went out and a lot of people were saying like, Hey, these couple areas of the product are brutal. Like, I don't want to even tell you the product's perfect.

It's terrible at these other things. But like this core piece is so good at what it does that we love it. And I think that was the sort of, that was the most compelling thing for me as a user, was I just, I personally love the product. And I think what was amazing was we went out. And everyone loved the product.

And so it gave you this confidence. That's like, okay, we're doing the right stuff. We need to keep doing the things that we're great at. But I think we also took away that, you know, like people wanted a BI tool and Looker wasn't necessarily built as a BI tool. It was built as this sort of exploration layer.

And that was like a really easy takeaway. It's like, Hey, people love this, but the reporting is just not good enough. And so you could take away these pieces where, you know, like the core was strong, but there's a lot of pieces at the edge that meant that even if the core was strong, we needed to fix some things.

Brett Berson: Okay, so you started to say that you sort of landed and spent a lot of time with customers, and then I think you were sort of continuing on explaining the sort of teams that you were taking over in the early days.

Colin Zima: So, I think from there it was sort of a, I dipped in and tried to help in areas that aligned with the work that I was doing as an IC sort of spread into orgs. So the obvious sort of complement to those, those things that I listed was supporting customer success. And so the first thing I started doing was, essentially we turned this informal customer success program into like a real customer success motion.

And it was understanding who is likely to renew and who is finding success in the product in a way that they will like, have an ongoing financial commitment to Looker. And we paired that alongside support. So like really trying to build out and scale the support org. Um, and for those that have never kind of interacted with, I shouldn't say today's Looker support, but former Looker support, it was like an incredibly high touch customer experience.

And probably the, one of the concepts, if not the concept that most associates sort of the positive goodwill that Looker has, was this very, very high touch customer support motion. And a lot of that was understanding how customers use the product and being able to build out and sort of train this org of new Looker analysts on how to support customers and how to build out the environment. So it was, it was building those two orgs to start and then sort of eventually, evolved into a product role. So I ended up leading the product team for four years in the middle of Looker uh, maybe five. Um, and that was sort of like a, Hey, we have a couple of PMs that are, you know, doing an amazing job. Do you want to sort of come in and be a sort of more strategic product leader over a lot of the work that's being done? So it was really just almost the continuation of being in customer success, which was like, Hey, you're giving us a lot of good feedback on how people are using the product and you understand them well, can you go from transacting at sort of like a one on one level with customers to making it more global in terms of how we build the product out?

And so started doing that. I was doing a lot of the internal analytics at some point in time, but it's hard to say I sort of like managed analytics because the whole company did their own analytics at Looker. So it was kind of a really unique experience early where we had, you know, 200 people that were building out BI at the company, which was nice.

And then sort of very late in Looker's cycle eventually convinced Jamie, one of my co founders at Omni to come back and take over the product org. And so he was managing product and I kind of moved into like a real pure floater, which ended up doing a lot of sort of like strategic work around the acquisition and then sort of like post acquisition, a lot of the data integration, with Google.

So I got the flavor of sort of like leading teams and then eventually peeled back off into being an IC. Um, sort of like reporting to the GM of Looker eventually.

Brett Berson: I'd be interested to hear more about the early approach to CS that you were just mentioning. Was it intuitively obvious to sort of go above and beyond in this really white glove sort of way with customers? Or was there sort of a strategic decision behind it? And I'm curious kind of what else you can share. I mean, I think a lot of folks talk about in the early days providing a level of support and service that's maybe not particularly scalable and not particularly economic. But I think you all kind of took it to uh, to an extreme.

Colin Zima: Yeah. And I, I would say that we are actually taking it to an even further extreme with Omni as well. Like, I mean, I let customer chats just push to my phone at all hours of the day. So like, it's not uncommon that I wake up and like solve the first couple of tickets on my phone in bed in the morning. Um, no, what's kind of funny here is that actually Hotel Tonight's- one of their core strategies was really around very, very high touch CS.

And it was kind of interesting because coming off the startup, like I'd worked at Google and UBS before, it's like gigantic companies, not really known for, you know, customer support, and then did the startup briefly and then landed at Hotel Tonight. And it was sort of obsessive about customer experience.

Um, like Sam, the CEO just always talked about like how incredible support was actually a driver of the business. And I think he actually convinced me, like the year and a half I was there, you sort of see it where, you know, customer support can go from a bad to a good, with a good experience. And I think there's like lots of examples of brands that do that really effectively today.

But we landed at Looker and Looker had a very similar motion. And I think it was sort of a different twist. It wasn't like CS is good for the business, so we should do great CS. Lloyd always talked about this idea of software as an act of empathy. And it was more the way that you understand how users use the product and the experience they have is by doing customer support.

So we had everyone in the company doing customer support all the way up to, you know, like 100 employees. And it wasn't every single day, all employees, but everyone got a taste of support. And I think that my takeaway having seen that was more the power that sort of the customer got out of a great support experience.

And the idea of sort of SaaS is predicated on this concept that you keep revenue for ten years or whatever. Like the business just doesn't work if people are churning out. And I think it was never strategic that was like, we're doing this for customer retention. It was doing it so that customers had a great experience. And great experiences lead to sort of like retention and virality.

And so I think it just happened to be right, in some ways versus like being a really, really explicit business decision. But I think what was interesting is that we appreciated that this idea that was really centered around sort of like a great customer experience actually was a huge financial driver.

Like it was a reason that people cited for renewing the service and recommending the product. And. We could see user growth through like this really high touch support motion. And it also matched the way that we went to market in the field. Like we did these forward deploy trials where a sales rep and a sales engineer showed up and we built out a use case together with the customer.

And it just became more obvious that the product was great after you got to touch it and feel it. And so I think that it was one of those sort of accidental superpowers that we had that when we realized it was so effective, and sort of so important to our success, we explicitly invested in it. So like we were hiring linearly with support with customers all the way through our acquisition.

And like support was the fastest growing org inside Looker. And I think the really easy thing to do from like the, I don't know, the private equity lens or something like that is be like, okay, support is 5 percent of revenue. That's crazy. Like, how can we do that? And I think it was interesting because like even post Google I wrote up a case study that said Google should retain Looker support because this 6 percent that we spend on support as a percentage of revenue is worth 15 or 20 percent in terms of, you know, like growth, retention, every kind of metric that we could think of. So I think to, to kind of circle back to the beginning of the question, I think a lot of people think they have high touch customer support.

And I think a lot of startups think they're doing great support. But I think that there's a really big difference actually between a sort of high touch customer support and like, I will not let a customer fail with my product, like full stop. And I feel like, especially early, having this mentality, and we used to talk about this at Looker is, that like, we will make customers successful, period.

It was not about Looker or the product. It was just we will make customers successful. And I think if you frame delivering your software as a little bit more, you know, it's become hot to be like, oh, we're so, we're so value focused or whatever. But there are very few products where you're using the product and it's just, it's really obvious that they want your company to be successful, like whether or not you're using their software.

And I think that is when it can really make a difference. And honestly, everyone can do it. You just have to care about it.

Brett Berson: Can you explain in a little bit more detail what that actually looked like? 

Colin Zima: I think in some ways it's almost like the inverse of the PLG doc should be able to solve all problems type thing. Where it's like, a customer can be successful on their own no matter what, I think is almost like the counter example to this. It's like, the product is so good, a customer can be successful on their own.

And I think the, we will make you successful no matter what, is this idea that you can open up such a tight connection with your customer, that they will communicate on an ongoing basis about like, big things and small things they run into, and actually think of you in some ways like an outsource member of the team.

So I'll give you an example. We use a software called Rillet, which, you know, we found through first round, and I swear I'm not getting paid for this. But we had a problem with the connection between Rillet and Ramp. And it's not really terribly important how, but for whatever reason, like, we couldn't pay vendors.

And we chatted Ramp a bunch of times. And to be honest, like, I love the software, and it's been really great overall. We weren't able to pay bills and we sent them a bunch of notes and they're like, Oh, maybe this'll do it. Maybe this'll do it. It was just sort of like a normal, and I don't know whether they consider they have high touch customer support or what, but either way, the problem wasn't getting solved.

And so eventually I emailed real it. And I was like, Hey, I don't know what to do here, but like, I can't get my payments through and I think it's related to accounting and I literally made them a super user in our Ramp system. And I said, like, I've got to go run to a meeting. I'll be back in an hour.

And they were like, great we'll figure out how to get it done. And I came back an hour later, and both the payments went through. And they're like we had sent five emails back and forth about little things. But the net of it was like your problem is solved and whether or not it was my problem, like the overall customer experience was just outstanding.

And I, I think that these are these great, like, do unscalable things examples, where trying to draw a distinction, like whether it's your product's fault or not, or like whether you can do that thing forever is fine. And like, you need to build scale into what you're doing. But the thing that's going to make me go recommend really more is just like having an amazing customer experience like product or not. And I think those are the small, like very, very unscalable things where it's reframing from like, how does my software solve your problem to like, I know abstractly that my software will solve your problem in the long term. And so in the short term, I'm going to make you successful and have you associate that with my product and me and the things that we build.

And the software will take care of itself over time. And so like, that's the philosophy that we have is like, if someone wants me to help them write SQL or like, I don't know, debug something in Excel, like I'll go do something. I do support for other people's products in Slack because I just think it shows, like a positive association with how much we care about their problems and understand the things they're doing.

And I know that the software will show the differentiation down the line, but I don't need every single problem to be solved by our software doing it.

Brett Berson: Were you able to implement that idea through the entire looky looker journey, or did you eventually get to a point where customer either support or success started to look like, you know, more traditional, decent customer support or success?

Colin Zima: I think no matter what, it's going to scale from like, being able to talk to the founder about a problem that you have, or like, the engineer that built the feature about the product you have. So like, there is a gravity to providing support where there's going to be a difference between 100 customers and 10, 000 customers.

So I think that's a reality. I do think that you almost have to evaluate yourself against like, other companies of your ilk at some level. And so I think for companies with 5, 000 or 10, 000 customers or whatever, hundreds of millions of revenue, we retained our quality at the 99th percentile of customer support.

And so I think you have to be comfortable letting some of the perfection go like when you're training your, your 70th through 80th support reps with like support reps that you've hired in the last two years, it's really, really hard to maintain a bar where just everyone knows everything about everything.

So the universal answer is like, yes, certainly the quality went down over time. I think the quality bar that we maintained through the acquisition and even a little bit post-acquisition was very high. And I think for software, like, there are not a lot of G2 crowd reviews where you get like a 10, you'll get like a 9.7 or like, Looker was just 10s all the way. And so it's it's more just that, like, yeah, we maintain a really high bar and people appreciated it. And I think it is doable, but you have to care about it. Like, it has to be the most important thing for that org. And like, it has to be a business strategic choice.

Like, you can't be like, okay, we're gonna, we're gonna increase efficiency by 100 percent and assume that it's at the same level. And so like, it changed. And had to scale, but we cared about it enormously. And I think that mattered 

Brett Berson: you think most software startups should strongly consider executing on this idea? Or there's like a set of parameters that should be true in the company for this to be kind of the globally optimal strategy.

Colin Zima: I think it's the latter for sure. So, I mean, I, the, I think the flip side of this is sort of the PLG motion where docs solve all problems and community solves all problems. And assuming that your ACV can support it, I strongly believe that it's optimal for a software company to have a very, very high touch support model.

And the reason I say that is, I'm combining ACV with margin here, there needs to be a level of dollars per customer that you can get out that you can actually reasonably support it. So, like, if you're spending 50 percent of revenue on support, of course, that is not going to be a sustainable business model.

And so, like, if your users are $10 monthly seats or something like that, you just you can't talk to all of them. So, like, the community has to solve that problem. I think at like a $25k ACV 90 percent margin software business, so like a classic sort of like high end SMB, low end mid market sales, everyone can afford this.

And you need to understand sort of like, who am I talking to about what? So like, are you helping people navigate docs? Are you actually working on sort of more value add services? it's not signing up to be unscalable. The caveat that I would make here is that we had KPIs in support, which is like, how often could we drive someone to a doc to resolve a problem?

And we, that was like literally a metric that we followed where we'd look at our Zendesk tickets and we would count URLs that pointed to docs. And yes, that could probably be gamed. Cause you could just drop a doc in that wouldn't answer the question. But the point was we tried to offload as much of the non scalable stuff as we could, but the idea is you're working in a platform and it is complex and there's a lot of degrees of freedom and the way that you can use it and you're spending a lot of money, then we can afford a very high touch customer support model.

So I think if those are parameters for your business, I think it's a, it's an opportunity to not think about support as support, but to think of it as sort of like account based marketing in a very indirect way. And again, like you need all the scalability and you need people that can solve a whole variety of problems.

Like as soon as you need to start routing issues to specialists and things like that, the model gets a lot more complex, but assuming that like generalists can solve problems, ACVs are high enough. And there's this like sort of platform motion to it.

It's a very reasonably priced like high touch motion that you can have where you can turn customers into advocates.

Brett Berson: So I think it's intuitive in the early days where the founding team is sort of all hands on deck with this idea. I'm curious, can you explain, you talked a little bit more about sort of KPIs, but like with early scaling and maybe at scale, how did you actually operationalize the function? So like, let's say it's 250 customers or 500 customers.

What did the department actually look like? Or if someone's original sort of reaction is yeah, Colin, that's fine. When there's like 10 employees and you are all up at all hours of the night doing this, what's kind of the, some of the kind of cheat codes or ideas that worked really well as you actually started to have some level of scale in the business. 

Colin Zima: So I mean, a couple things. So like, one is that it helps to think about the economic model of it early. So like, how much are you hiring people for? How long are you retaining them for? Do they need to be trained? You need to do baseline math to understand what percent of revenue you can dedicate to support before you go through this exercise.

This goes back to like, what types of customers can you think about? What types of products can think about doing this for their customers? Like, go do some napkin math over how many people can support how many customers. The next thing it leads to is sort of like a couple layers of thinking.

So one is that you need a pipeline to hire these people. Um, So assuming that your business is growing extensively, like our support team, I think in like the three years that I managed it, went from two to 15. And then I think by acquisition was about 100 people. So this is an org that went from two to a hundred over eight years, which is pretty quick.

And so you need to have like a really clear, almost like an ICP for what a support person looks like in your company. And for us, it was like STEM right out of college. There was like a profile for that type of user that we could interview really clearly, we could understand, we could train and we could ramp.

The other kind of this gets into like sort of one of these knock on benefits that I think people forget about is that it was a huge talent pipeline for us. So between like SDR and support at Looker, we were feeding the sales org, the sales engineering org, the engineering org product, like we were literally piping these super talented people, like training them from zero and then pushing them throughout the org.

And it was effectively like an onboarding talent pipeline for kind of the next tier of job, which is amazing because they have all the context on the business as well. 

Brett Berson: Is that how you got people that maybe you wouldn't traditionally think about us as support folks to take the role?

Colin Zima: I'm kind of frozen on that one because like, I don't know what the traditional support rep kind of role is. And I, I think there is like a marketing to jobs that is important for all this stuff too. Like, I remember that Looker went through a phase where sales engineers didn't want to be called sales engineers.

They want to be called like data analysts because they didn't want sales in the title. And I think some of it were like our support reps were data analysts. And so like there's a little bit of marketing to it, but I think part of it was like that the problem was intellectually interesting enough.

And the idea was not support reps helping you find a doc or like resetting your password for you. They were helping architect more complex SQL problems and they were doing like higher value work than what I would consider like row level support work for like Bank of America or something like that.

And I think that's again, Mike. That's an important part of the tilt here is if your customers are emailing you about support because they need password resets and we had some of this too. So I want to, I'm sure someone will listen and be like, you didn't build those things and support had to do it.

Like we had some ugly versions of these things too. But a lot of the work that they were doing was much higher value and sort of much more nuanced and much more interesting. And I think eventually we did market this idea that like. This is a route to become a sales engineer, or I think that we have a few engineers.

Like we literally have an engineer who started at Looker in customer support at Omni right now. And so like, there are fabulous people that have gone this route too. And it, they just sort of needed to develop their career. on campus interviewing for Goldman investment banking is not the route everywhere for everyone.

And this was like a way to see startups and do a startup thing and sort of see a high growth company. So I, I do think that we were able to sort of pitch something more interesting than support if that has like a negative connotation.

Brett Berson: And all of those folks were new grads or it was a mix?

Colin Zima: It was a lot like we, we did have more senior people. So like that was the maturing of the support org meant that we also had sort of a tiering where we had sort of like the early grad learning ramping support team. We also have experts in different product areas. So like API, JavaScript, SDK type stuff requires a certain level of expertise. And a lot of those people had been at sort of like high touch customer support customer success at other software companies as well.

And so like you do build a hierarchy in it as well. So like it, you have these sort of generalists underneath that can do a lot of different things, and then as you grow, you can move and sort of find expertise in different areas of the product. And again, there's space to become managers and things like that if it's working well.

So some of the support folks stayed in support, became managers, managed large teams. Some moved into customer success or like more technical IC roles. But you can provide a variety of paths if you're sort of thinking about it proactively.

Brett Berson: So one piece in terms of scaling this high touch uh, CS function is, is the hiring model. I think you were going to sort of continue on with sort of the other um, tenets that made it work.

Colin Zima: I would say the single biggest thing that made it work was just sort of like the culture of sort of working with everyone else at the company. So one of Looker's cultural values was called the kitchen table. And it was this idea that the support team literally used to physically sit next to each other.

And this was up to, you know, like it'd be a 50 person long table and everyone would be sitting next to each other. And that was literally how you ramped. It's like you'd be sitting on support your first week, I might be exaggerating here so someone can correct me, but your first week you'd start taking chats and like you'd essentially just be like, you know, lightly drowning on your own.

You'd have to go get into the docs and try to figure it out on your own because you can kind of do a lot of this on your feet. But the advantage there was you could turn to your right and say like, Hey, I'm a little stuck. How do I solve this problem? Can you help me? And so it was just like active learning by doing next to each other that I don't think could be replicated in any other way. And it meant that someone could do this sort of like active training where you were unqualified for nearly everything that you were doing at any given moment. But by solving that problem, you pushed yourself and you kind of learned while doing with the person next to you.

And that was a really big deal in sort of like the informal side. On the formal side, there's a ton of training that we built as well. And so like you have to get great at teaching people. You know, SQL and the product and the culture of the company and sort of like how we show up in front of customers and things like that.

And that one, I don't think there's a lot of rocket science too. It's like, you need to build formal training programs and have people meet each other and be comfortable talking to each other. And then we did a lot of reviewing of people's, you know, conversations and said like, Hey, you did a great job here. Hey, you can improve on these things. And that became just sort of like a piece of the process was, you know, like evaluating how the work was getting done on an ongoing basis. So like that training part was huge.

Brett Berson: So you mentioned this a little bit, but how is this sort of CS concept manifesting itself in the context of Omni?

Colin Zima: The simplest answer is just that we care enormously about it. So, we try to make sure that our customers understand that kind of no matter what they are doing, they should feel like they can ask us any question that they have. I feel like kind of similar to like the the sitting down at the dining room table and starting to take chats.

We are really trying to encourage people with as low friction as possible to ask us any possible question that they have, like good questions, bad questions, complaints. And I think the really interesting thing is when you reflect that back at the customer. So we've had a couple people that have started using the product and they'll ask a question and we use Slack for chat support right now, which is nice because it's just really low friction and you will be surprised at the difference in the conversation when you respond in one second versus one minute versus ten minutes, because when someone asks a question, and you respond in one second, it immediately turns into a conversation and it is very likely that you will get 100 more back and forth, you know, like slack messages than if there's a one minute turnaround or a 10 minute turnaround, because that sort of sets the tone for how quickly you can have that conversation.

And so this idea that we are always on and kind of these early field facing employees, and like the handful of us that are doing it are really always on. So like, there's a lot on the five of us that are doing it. It used to be two of us. It just means that customers are more comfortable giving us feedback.

And part of the approach that we had with the product is, you know, like the company is 18 months old now, and we started putting the product out there when it was definitely not ready. Like we're entering this really deep space where the products that people expect to do absolutely everything. Like you get a 700 a line RFP about features in the product.

And we know that we're going to have any is on 500 of those, but we know that the slope of the product is going to be way higher than anything that anyone else is dealing with. And we know that that's not the entire decision making process for working with the product. Like you want to understand how to use it and be effective and do deeper things.

And if we can engage with the customer on sort of like trusting us as a partner. We have time to go build that product and sort of show them something magical later, but we can actually sort of be a teammate in the interim. So what's crazy is that we will actually get, I remember this one customer was using the product and he used the product for like 10 hours the first day he touched it.

And he probably sent us 600 slack messages, like good and bad. And I we probably responded to, you know, like five or six hundred of those also, where it's like, Hey, we're thinking about that or like, Oh, I've never thought about that or Oh, tell me more about that. And it turns it from like a support conversation to a customer development conversation to like something strategic about how you're building the product.

And you can't really like you can't buy that really, no one's going to give you that effort without you reflecting the effort back to them. And so I think that's where it's really important to us is that we're still in this stage where we can win by being hungrier than everyone else, even though we think we can build a better product and we have a better product in many different ways.

I know that I can out effort people and I can care more about people's problems. Um, so like I was sort of jokingly say, like, I do a lot of lookers uh, support in dbt Slack because one, I can answer the questions and I kind of want to see what people are asking. And so I might as well answer them while I'm there.

But two is like we can also just sort of like reflect what good support used to be like and should feel like, and it helps people sort of understand like what a good customer experience could or should be.

Brett Berson: I wanted to talk a little bit more about product strategy and product prioritization. As it relates to kind of the chapter of Looker where you were driving a lot of the product. Obviously, kind of one of the benefits that you were talking about of this support model is that you're very close to customers. You're constantly hearing about all of the issues that they're having.

And so that's one input for product strategy. Um, sales and presales is another one. And you kind of always get into this question. Are you trying to satisfy your current customers or build functionality to get the next marginal customer? Um, then you have long term product roadmaps. I think you did a bunch of theme based work at Looker as well, where you had annual themes. And so maybe reflecting on it, are there big ideas for kind of other early starting to scale B2B software companies, data companies, et cetera, some of these ideas that might be useful as they're thinking about product strategy, features and functionalities, ordering, sort of that type of stuff.

Colin Zima: So I mean, my, my first kind of most overarching point of view here is that being a product leader is, is having a deep product strategy. Like if your product strategy is, my customers will tell me what to go build. I just have no more deep disagreement with a product strategy than that one.

Like, I think that great products are built with, with opinions and they need to go merge with reality. But kind of the single most important thing that I think the product leader needs, and often this is the CEO for a company like our stage, is a really strong point of view on what people need to do their work.

As you start scaling, like I was really a huge fan of the Looker years when we could sort of stack rank completely independent features and say we're going to work on like a new viz type and then something completely esoteric and like the API layer and those are like priorities one and two and you could kind of wholesale shift sort of like engineering priorities based on feature work because I think you get this agility to adapt and move quickly.

This is going to sound obvious, but really like the easiest way to define product priority is by resource allocation. And I think what I learned as Looker started to scale was that we implicitly reflected some level of our product prioritization via the allocation of engineering and product and design teams.

So if you have one team that is working on the dashboard layer and another team that is working on the modeling layer, and each of them are five individuals, then you have expressed some level of equality between the problems that exist in both of those layers. And so, it provides a framework where inside a team, they can have a lot more autonomy to decide sort of what is right in a given sort of smaller area where maybe apples to apples comparisons between feature work makes sense. And the allocation of big decisions is left to be sort of a resource problem, which is like, we need more focus in the dashboard layer and more focus in the backend. And so like, I don't think there's a huge amount of rocket science for how you balance inside a given area. So like, how do you pick out the next dashboard thing that you need to do? Um, I, I just, I really think it's hard to come up with a great, like scoring framework for how to pick out the next 10 features, because I found that every single time that we tried to apply some sort of rigorous, like scoring framework to difficulty and reach and, like customer tiers, it was just like a silly exercise in trying to create structure to something that was ultimately unstructured underneath it, which is like someone was gonna make a decision that was essentially cost and effort, versus, versus payout. So, what, what I would say to sort of counterbalance all of that is that that doesn't mean that you could sort of throw your hands up and say that the product team makes all the decisions, even though I think that ultimately that's how like, great product is built.

Singular accountability on the product team to prioritize things. But I think it is then that team's responsibility to be aggressively seeking input from every single area of the business and be able to defend their decision making. So a simple example is, I do not think the field should get to vote on features and the product team and the engineering team and the CEO or whatever.

Like, I don't think that creating a rigorous scoring framework to balance those four people should be how a product gets built. But I do think a product team should be able to say, we're doing these three things and the reason that we're doing them is because X, Y, Z and we're not doing these three things.

And the reason is because of X, Y, Z. And being able to defend that decision to the sales team or to the customer support team or to another team is very important. So it's all advanced common sense, I think, like what I'm describing is not really crazy. But I think the most important thing that you need to be able to do as a product person, especially as a scaling org, it's wrong word- is like, say, defend yourself, but you need to explain why you're doing the work that you're doing, because I think the really easy trap to fall into is to just sort of say like the teams are making their decisions, this is how we're going down this route. Whereas like I had to go to the support team over and over again for probably a period of two years and say, the app crashing is not a priority right now because I want to do more feature work and we can suffer through this and I know it's bad, but I don't think it's bad enough yet.

And so like, you guys can argue with me about it, but I will sort of eat this decision. And then eventually there came a moment where it became such a huge problem that we decided that we had to kind of stop and go fix that thing. But there's you're, you're never going to get the sort of quantitative framework for how to make that decision.

You just need to really be aggressively seeking input from all these different teams, I think. And then, you know, go the benevolent dictator route and make good decisions.

Brett Berson: So when you were running product, what was your optimization function? I, I get sort of single threaded ownership. Heavily reliance on, on good instincts and judgment as opposed to some sort of democratic scoring system. But like, how did you figure out the North Star? There's so many different things you could be optimizing for as a product owner.

Colin Zima: uh, it's funny to articulate this, because I've never really said it. I never really thought about myself as trying to allocate resources from zero. Like, it's almost the inverse of first principles thinking. Um, the way I would describe it is like there's an inertia to how we built things and the inertia was kind of these allocations of people.

So like a third of people in the model and a third of people on the dashboard and a third of people in the other area. And I viewed my most important role as trying to really push resources at the margin to things that I thought that we were missing. So this wasn't like uh, we're going to blow everything up and sort of really think about every single project from zero and where they go.

But to your sort of question of, you know, annual themes and these other sort of background things. The way that I felt like I could exercise the sort of most voice was to try to really emphasize one or two problems that sort of in a steady state were not getting handled well. And those often became like either a thematical or like a thing that I was constantly fighting for resources for.

So I kind of, a throwback to sort of the early part of the conversation. I really think that one of the weaknesses of Looker is that we never really wanted to be a BI tool. Like we wanted to be an exploration tool, like something for deeper, more interesting work. And I think the almost the reason that I was hired into the product role was to sort of convince the company that we had to be a BI tool.

And so I spent an enormous amount of my time as a product leader, trying to drive or allocate more resources to like the front end reporting areas of the app. And I get that that sounds almost trivial, or like, you know, just go pick them up and move them. But I think when you start getting big, like the influence that you can have is sort of like these really big marginal repositionings. Like I can't change the the DNA of what Looker is or sort of the core of the platform. But I could say, like, we need 50 percent more resources on dashboards, or we need to completely rebuild dashboards to go do them better, or like the reporting is not good enough, or one of the examples was like, we weren't a good enough product for really, really big deployments.

And so like you're looking around the corner strategically and saying, like, we're great in the mid market in SMB. Enterprises and unlock that gets the business successful. So back to the objective function, it's like, how do we get to a billion in revenue? That's pretty abstract, but it was like obvious that enterprise was a big one.

So one of these things was the app just was non functional if you were over 500 employees. And it wasn't non functional as an exaggeration, but it just wasn't built to handle those things well. And so this thematic goal that you could drive through was like, let's, we called it Looker 500, but like, let's be great for really big orgs. And I feel like being able to really crisply state a small handful of unpopular priorities almost is, I think, a good description of product leadership at scale. It's sort of like, where am I reallocating resources from steady state?

Brett Berson: What was the process by which you all decided that now was the time that we're going to put real resources into, basically going up market versus all the other things that you could build. That's sort of the gap that I'm kind of missing. And it was a just, basically intuition and taste, and it just felt like now was the time, or was there something else going on? 

Colin Zima: hate to say yes, but I feel like it is just sort of intuition And taste at some level. 

Brett Berson: And do you think that things worked because of, or in spite of, or somewhere else?

Is that way of building product, what you're taking with you to Omni because you believe it's really important, to build sort of a really phenomenal product and or company?

Colin Zima: I think so. Like, I really do think that there's, I can't believe I'm saying these things, but like a je ne sais quoi to like building product, you know, where if you really try to get super analytical about like resource allocation or things like that, you end up with a sort of like you end up with booking.com, which is like a great product if you're, you know, click rate optimizing it. But you don't end up with something like strategically interesting. And I think it's some level like. You need to, you need to make big strategic bets, but a lot of these things are at the margin. Like we're not going to pick up the entire engineering team and move them into enterprise.

We're going to like start allocating resources on bigger problems that companies have. And then we're going to slowly allocate more and more resources. And so I, I, I really do feel like a lot of these decisions are sort of at the margin and then you just need to lean into what the customer is telling you and sort of how it's received and whether it's doing what it needs to do.

It's like an example of this is Looker didn't, Looker was always about embedding the product. So you could pick up a dashboard and go drop it into Salesforce or something like that. We were always a little bit afraid of launching an embedded product for customers to embed. So delivering reporting for customers' customers.

And I think uh, I think Ben would probably confirm this, who was running the VP of engineering when I was running product. I think both of us just thought it was going to be a bad product. We were just like, you know, the architecture doesn't work. It's going to be kind of slow, which it is. But we just didn't think it would be great, but we did it anyway with like a little bit of resourcing.

And then we launched it. And then customers essentially said, this is amazing. I want more of this. And. Like, lo and behold, four years later, it's 30 or 40 percent of Looker's business. And so I think at some level, overthinking the exercise of putting resources into these small bets and things like that, like, yeah, you could come up with a framework that's like, we're going to put 20 percent in bets and like 40 percent in maintenance and 40 percent on other things.

 And, and this is obvious in the way that I speak, but it's like I think that's probably a little bit too organized in terms of like approach for me. And I am more in the camp of sort of doing things and then responding to what, what is happening and trying to adjust. And so like I probably lean towards a more experimental way of allocating resources and then, you know, things that are good and producing get more resources and things that aren't good and don't produce get less resources.

Brett Berson: What do you think the, the explicit downsides of this approach are?

Colin Zima: I think it's pretty easy to not be thoughtful. You know, it's the downsides of the benevolent dictatorship. Like, if the dictator is bad, then you will build bad things. And I do think that's true. Like, I, I think that it's, it's sort of similar to taking big risks. It's like, if you have a really rigid framework or you're taking really big risks, you can be wrong.

And you can't respond to those things. Or like, you either fix the framework or you go make better decisions. And I think if you're not listening to your customer, it's very easy to just sort of keep doing what you're doing. And I think that we actually made some of those mistakes, even like, I think that we could have taken some big risks to align more closely with dbt or to acquire possibly, or to like move into different areas of the stack that we didn't do because we were comfortable in our area of the product. But like what I would say is that was done thoughtfully. Like we, we calculated how much revenue we could get in our area of the product. And it's kind of nice when you set up a company and you're like, we can get to a billion dollars in revenue doing exactly what we do today, just more of it.

And so that led us down this sort of path of let's focus and make a very, very good product. And if that very, very good product continues to sell well, and the market continues to be there, we'll just keep trying to build a very, very good product. And so like, in some ways it was like a very simple sort of business strategy because it didn't require a, a 200 product strategy or something like that or like incrementally releasing two products every quarter to hit revenue numbers.

It required that as the customer base continued to grow and the maturity of the customer that we talked to continue to grow that they continued to be as happy as our early customers were. And so I think that this whole strategy was sort of implicit on this idea that one, people already like the product, and two, that as you evolve and check whether new customers like the product, you can actually sort of execute on closing the gap if that's not true. So I think the whole thing revolves around this sort of like incrementalism of decision making as opposed to like a very hierarchical top down sort of rubric for doing things. Which to me is like it more closely aligns how people actually work. Maybe some people are sort of like picking up and reallocating resources a lot more sort of first principles-y down from zero.

But I think at least when I looked around, it was sort of like engineers were sort of implicitly allocated throughout the organization. And you could sort of marginally touch or nudge the work that they're doing towards different topics. You're making me think I'm not analytical enough about this stuff.

Brett Berson: Well, what about 1 downside? And I'm curious to get your, your take that sort of comes to mind is, is maybe it's a little bit harder to create clarity and alignment internally. That, like, when you lean on judgment and taste, it's maybe a little bit less of like, here's the mountain in front of us.

Here's how we're going to get up the mountain. It's going to feel great when we're at the top. Here's our exact path. And everybody sort of understands their role. Did you find that at all? Or is that sort of a false trade off?

Colin Zima: No I, I think that probably could be true. I think that absolutely could be true and I think I always personally struggled with this when we had to come to some sort of like three product goals for the year type thing. 

Because I would always say but like I want to do 12 different things and four of them don't align into those three bullets and I would say that there's kind of two ways to solve that problem which is one you drop those four things and you align under your three bullets. Or two you do the 12 things anyway you. And I'm definitely in the do the 12 things anyway camp, personally, just because I feel like, if we can, we should.

And it's just a more ambitious way of building things. I would agree that it comes with like, probably some challenge over like, why are we doing this versus that, or, I mean this happened when we got bigger too, which is like, hey, this doesn't align with the thematic goal, why are we doing that project, and it's a good question because like, if it doesn't align with the thematic goal, can you find something that does align with the thematic goal?

But I would say, like, the underbelly underneath that, again, it goes back to this sort of, like, nudging resources at the margin towards a thing that you think is higher value. And sort of, like, if you try to do that at every single level of the organization, so, like, high level and even project level, you will end up with some churn for sure.

And I feel like that's also probably led to, you know, me not wanting to do it forever because it is very tiring if you're trying to be kind of everywhere all at once.

Brett Berson: One of the really interesting things about the Looker journey, that certainly we were exposed to since the very, very early days of the company is I think in, in the history of first round across 450 businesses, it's the only company that didn't miss a number all the way through sort of massive exit or sort of somewhat directionally that's the case. And I'm curious, kind of, maybe have you talk a little bit about that or your own reflections. I think you could probably argue it as it's an epically good thing or in some ways epically bad thing. And what was sort of the philosophy around goal setting or specifically number setting and kind of what do you make of it? 

Colin Zima: Yeah, I oscillate back and forth on this one. In some sense, it's just, it's so exceptional. And this wasn't, this wasn't like hitting okay numbers. We sort of just pick like the 80th percentile of a great business. And we said, that's our goal. And then we, we drew that line out for 24 quarters and hit it, which is, you know, no, no startup founders going to be like I, I am not happy with that.

Brett Berson: Colin, was it also, was it explicit? We never want to miss a number. That's the culture here or it was less explicit.

Colin Zima: I wouldn't say we talked about never missing the quarter, but we, like, everyone had so much pride in it implicitly that we were never going to miss a quarter. So like, I think it was, like, at least on the management team, it definitely was we're never going to miss a quarter type thing. It's funny to juxtapose against Google because I worked at Google, you know, before the Looker acquisition, and they have this idea of OKRs. And like explicitly, you're not supposed to hit your OKRs. Like 70 percent is great. And I think at my core, I believe that is a better way of doing things because it like unlocks you to overachieve a little bit more.

And so I think in some sense, it constrained our ambition in some ways, and it constrained it to, you know, like, again, the 80th, 90th percentile of what a great business looks like. So it's hard to say that, like, it's significantly constrained what the business could be. But um, I think to, to, like, things that I will not be keeping, like, I want to miss some quarters because we're aiming too high for sure.

Because I think it unlocks people to find new ways to do more. And I think like the downside to that, like Looker hitting the quarter every single quarter is like, I don't even think I think that we might have beaten it by more than 105 percent like three or four times out of those 24. So it was like it was a machine.

It was a machine. And that is so commendable. But I think the same way that you would argue that like a runner that hits their target every single time they go out probably can push a little bit harder, I think that we probably didn't give ourselves space to make mistakes and try to do things, and it probably made it more difficult to unlock another level because we were so afraid of failure.

Brett Berson: How was it even possible for that number of quarters?

Colin Zima: I mean, we just had a, we had a sales process that worked through a spreadsheet really effectively. Like we did a really good job of understating our sales pipeline and what needed to get created. So our close weights are incredibly consistent through the life of the business, and we were able to generate meetings really effectively for the life of the business.

And so like the biggest thing that you can do is understand where your business comes from. Like we, we closed 30 percent of our business intra quarter, which means that there were leads generated intra quarter. The 70 percent was generated pre quarter and like, I think 40 percent of it came from the previous quarter and 30 percent of it came from the three quarters previous.

And so like at a certain level, we just really had a very tight understanding of what sales pipeline looked like. And then we just did a good job of, you know, getting through trials, understanding close rates and things like that. And I think to some level it was, you know, like we managed pipeline really effectively.

 I, I think we had a very, very good understanding. I did not appreciate at the time that like management through a spreadsheet was not how every business ran either. So, um, I now appreciate the difficulty a little bit more.

Brett Berson: We got into a little bit of this, but now when you reflect on the Looker journey, what's your answer to like why the business worked? 

Colin Zima: I think ultimately the answer for me is just the product was outstanding. It fit a problem in a market with a solution that just did what it needed to do. And then it was surrounded by very competent operations.

And I know competent is not like the most superlative word, but it was a unique product in a gigantic market that did a thing that it did really well and uniquely. And then we did a good job of hand holding it all the way through. And it's why kind of my strongest belief is that you have to have a really good product to succeed.

And that's, that's not to say that sort of like ineffective sales is going to carry a good product in the same way that like a good product is going to carry ineffective sales. I think you need to do all the things. So it's kind of like the, when you get the question of like, were you lucky or good in life?

Like you need a little bit of both. But I think a lot of it was just like right place, right time and a product that executed on that right place, right time really well. And then it got surrounded in a business machine that was really effective.

Brett Berson: When you say great product, can you be more precise in kind of what you mean by

that? 

Colin Zima: So I think there are probably two aspects to it. So one is that there was this market opportunity in data specifically. Which is, there were these old school products that were very centralized. Tableau was really the sort of canonical decentralized product. And Lloyd had this very keen sort of observation that people wanted to move data less.

And this was right at the rise of Redshift, BigQuery, Snowflake. And we were able to hit this gigantic platform shift in data to the cloud data warehouse and this idea of centralizing all your data in the cloud data warehouse, and we delivered a product that connected to that platform shift in a very unique way.

And so it was like, it's got all the like, yes, it was delightful to use for what it did. But really, it was just a product that was architected for the new way that people were doing things in a completely unique way. So it was, it was very code heavy. It was cloud native. And there are like other aspects to it, but like, those were really the kind of two most important concepts, but it was the centralized data model.

And so there were a lot of conversation that we were walking into where we're the only product that did anything remotely similar to what we did. And so in some ways, just like finding a level of uniqueness in a crowded market is very difficult. But when you do, if you're executing properly on it, and the market is gigantic, like that's the lightning in the bottle.

And that is sort of like what made Looker special because it's like, it wasn't that the product was gorgeous in every way because it wasn't like the original product was literally a model that you had to build in the command line. It just was technically elegant for the exact problem that it was solving.

And it really aligned well with the user that we were selling it to.

Brett Berson: So I'd love to hear more about the founding story of Omni. You spent the last meaningful percentage of your career at Looker and you're obviously building something in a similar space. And so what was the path in? 

Colin Zima: I mean, I sort of mentioned this before, but, when I started the last company with Jamie, after I did that, I probably have told 500 people that I would never start a company again. And then I hated it. And the reason was because like last time we started a company because we wanted a company.

That was our product thesis, which turns out it's not a very strong product thesis. This time It just felt like the product in the company had to exist. And in some ways that makes it very easy to go build the product. So like to what made Looker a great product, there's like a similar, but different backdrop for us, which is, you know, Looker and Tableau got acquired within a week of each other.

And so again, now this gigantic market that is BI that has existed for the last 40 years has a pretty large sort of strategical, in terms of, there's not a new generational company that exists in BI. So nice market opportunity, good foundation. The second part of it was, there are some of these I shouldn't say like a complete platform shift, but this idea of like doing data in the browser and something like DuckDB. There, there's a mild platform shift in the way that people are using data, but kind of more significantly, the idea of Looker has become commonplace.

And so this idea of a cloud based data model and doing transformation in SQL via something like dbt, there was this product positioning that had sort of adopted a lot of the ideas from Looker, but Looker was not able to adapt to the changes that it's sort of founding and popularization had resulted in.

So the really simple example is like the idea of a cloud data model and sort of compiling SQL and transforming it and doing these building blocks the modern version of it has become commonplace. But now we've sort of become decoupled from SQL. So you've got like. dbt on one side and BI on the other side.

And when it came down to it, these were actually a lot of the personal frustrations that I had with the product myself, which is I liked the organizational side of Looker, but I really did not like the sort of rigidity of it. And so we had this market opportunity. We had this sort of product insight, which is like people want to write SQL and do Tableau stuff and use Looker at the same time.

And then we had a competent group of people that had built all of these things that loved working together, that wanted to go build more. And so it was actually one of these opportunities where I just felt like we had to go do it because like almost the world was demanding the product come into existence.

So, let's go test that hypothesis. And I think I've gotten a lot more comfortable with this idea of, sort of like startups as hypothesis tests, you know, like, we don't know if we're going to be right.

And I think that's a- that's completely okay. But we can go take a really big swing at this bet. This is like we're not running a bootstrap company that is going to sort of do it slowly. We're going to take like a gigantic swing at doing everything in the BI space all at once. And it was sort of like a too fun to pass up opportunity, which is like, okay, let's go see if we can actually do this.

Brett Berson: Now that you're so much more of a known quantity, how do you maintain intellectual honesty as a founder?

Colin Zima: I think the, this is probably like, just from a personal standpoint, just something I happen to be good at, I guess, which I know sounds funny. But I remember doing the 360 at Looker and the feedback that I just kept getting is like, Colin really likes to be right. And so I feel like one of my def- my, my most sort of defining characteristics is I'm definitely confident, but I really like being right. And the nice thing about really like being right is that when you're wrong, the way to be right is to change your mind and go do the right thing. And so I feel like as long as we're honest with ourselves about what the product is doing and whether it's doing it successfully and whether customers like it, then we're sort of in this learning mentality where we can go be wrong and, and sort of adjust.

So I, I think it's been kind of funny because even as we've launched the product out, like the core thesis for the company has not shifted even an inch since founding. It was just this idea of centralized and decentralized analytics at the same time. But we have launched and unlaunched different areas of the product, like three or four times where we've just gotten it wrong.

And customers have told us, and frankly, like we have told ourselves that it hasn't felt right. And so I do think that the really nice thing about sort of founding a company versus working at a big company. Is the market sort of decides your fate. It's like what I liked about finance the most is it doesn't matter if you're right or wrong, if you're a trader, like you either made money on that day or you didn't make money on that day.

And in some ways we get some of the incorrect lessons by being in the space because like, you know, we get some projection as the Looker people building a new company, but at some level, like people either love the product and want to continue using it and giving us money or they don't. And if they don't, then we're wrong and we need to fix it or we don't get to exist.

So, I think as long as we're humble in that sense we can't really be wrong because there's no other option.

Brett Berson: How did you figure out what are the big ideas you want to take from Looker versus it was right for the Looker machine or the Looker time and we actually have to rethink these things and not just do copy paste, copy paste, copy paste?

Colin Zima: Yeah, we're still figuring it out to be honest. On the product side, it was actually the easiest. Because this is like the joy of the benevolent dictator is like, I like these things. I don't like these things. So we're going to take these things and not take these things. On the company building side, it's harder because, I mean, I think one interesting aspect is our company as, is 28.

And I think 20 of us spent time at Looker and five of us spent time at our co founders company. So we are borrowing a lot of, certainly like a lot of culture, but also just like a lot of understanding. My point of view, and it's going to be kind of unsurprising given the product backdrop, is if it worked before, we'll go try to apply it this time and see if it works this time, and if it doesn't, then we'll go fix it and try something different.

And like, you try to understand whether these concepts work from first principles at some, some level. Like, I believe in a high touch support model because I've convinced myself that it is the 2023 version of account based marketing. So we're, that's going to exist forever, whether we like it or not.

 Like some areas it's easier to take risk, like in marketing, I will literally try anything. So, like we're going to go try absolutely every possible idea that we can to get people to demo the product. And then some of it is just like, you know, go look at what other people are doing and try to do things.

Like I never wanted to be a LinkedIn influencer. I hate the idea of it, but now I post three times a week on LinkedIn and you know, I'm reluctantly leaning into it. So I feel like that's sort of the fun is we get to go see what is different and what's the same and we have a lot of smart people to talk to, too.

So, part of it is asking people why they chose these ideas and then seeing if they apply for us.

Brett Berson: I think what's really interesting is obviously you joined Looker very early, but there was kind of still reasonable amount of product surface area that was built. And I think that you coming into this company. There's so much product that you could build. I mean, you, you probably have a five to seven or 10 year roadmap kind of roughly outlined in your head. And so how did that map to at what point you were building something that was ready for an early customer to use and in what order?

Colin Zima: We've sort of tested this in multiple layers. So first we tested the messaging, like product messaging fit or whatever, if there's a word for that. And we kind of got that on day zero. We started talking about these problems. And again, like we have the advantage of we're just sort of building the product for ourselves.

Like we're really building the product for me at some level. So the messaging wasn't the hard part. 

I think the thing that's been kind of crazy for me that in retrospect was obvious, but I, I think I wasn't expecting as much when I started is, I think that literally in the past year I've done probably 500 demos, like literally more than one a day, maybe like some days, probably like three or four.

And I do think that the most valuable way to understand whether the product is doing enough and sort of what people actually want is just to talk to more people and have like a real meaningful conversation. So I think our takeaway was that people wanted the totality of the vision that we have, but like there is a, there is a small version of the totality, which is like this idea of the SQL runner and Tableau for Viz plus Looker.

And so it was sort of like, okay, what is the smallest possible version of that, that we could release. That someone could actually live in all day and have as a BI tool. 

Brett Berson: So I wanted to switch gears a little bit in the last sort of section of time that we have together and do a little bit of a grab bag lightning round with a bunch of different questions that I was excited to sort of get your take on. 

The first one is, what are some of your thoughts or advice on folks thinking about how to pick which startup to join?

Colin Zima: So the, what I always tell people is think of it like a really concentrated startup investment. So you get to be a VC except you only get to pick one company every four years. And I think when you put that hat on, you need to think about the types of questions that an investor is asking a company, which is like, how are its strategic prospects?

Like, what does the business look like? Because I think my strongest held belief about young companies and jobs is success solves all problems and creates like the most interesting companies by far.

So your job is going to be more interesting if the company is growing successfully and the business is doing well. And so take a lot of time to think about the company instead of your job, because if the company is moving quickly, your job will change.

I am shocked at how few candidates actually try to learn about the business in any deep way. And like anyone can go take the time and I'm not talking like go spend time on Google. If you go on LinkedIn, there's probably 500 employees and you definitely have connections into a lot of them. And you can learn a lot more about how the business is working and what people like and dislike by just having all these conversations with people.

And so I think the people who are actually doing that sort of legwork on average are making much better decisions about the business, they're not going to become superlative investors, but they will know a lot more about the leadership style of the company, how the product is doing.

And at least what the vibe is from other employees, which might sound trivial, but that is more work than a lot of people are doing to figure out sort of where the company is going. Like I don't think that those are hard things to figure out and they will tell you a lot about sort of the state of that business.

Brett Berson: What are some traits of being a stellar early stage startup employee that maybe you think don't get enough attention?

Colin Zima: I continue to think caring is the, is the single most important trait. And I don't, maybe it does get enough attention. Honestly, like effort solves nearly every single problem in a young company. And I'm not talking like go work 120 hours a week type effort. Like my brother is in private equity and does that and I don't think that is the, that is the necessarily a way though.

Like it probably can be good. It really is just like caring about how things work and trying to understand how everything works and just raising your hand a lot. Like the most effective people in every company that I've been at are doing a lot of stuff that's not their own job and they figure stuff out, and they just go do things, and they raise their hand a lot.

And those are the people that I love working with. Like, a great example is just our PM lead, Arielle. I sometimes just, you know, call her, and I'm just like, I have an idea, and it's, it's very often a very bad idea. And this one was like, Hey, we should build a browser extension that might be interesting.

And she was like, I had a weekend and I just went and built a browser extension because I wanted to see if it was cool. And like the way that she shows it off is just like a full demo of it. And it's the kind of stuff where it's just like, you can't ask someone to do that. But when you do that, you level up everyone else around you in such a significant way.

Because everyone looks around and they're just like, Oh my God, like that person did that. Like I can do a little bit more. And when everyone is doing that. Just the pace goes so fast, so it's just like it's this combination of just speed and caring that I think is by far the most important quality.

Brett Berson: Do you have a way of explicitly interviewing that in the context of Omni? 

Colin Zima: I haven't had to do very much interviewing, so I'm probably not the guy to answer this, but like I will tell you one of those three people that we've hired. His name is Jack and I've probably told this story to many people, so he'll be embarrassed, but this is funny.

Like he literally sent me a cold email and was like, hey, I want to work at Omni. Which, I think I probably responded with my classic, like, appreciate the thought, not a fit for now. I think he emailed like six or eight different people at the company again. Like he just kept pinging. Including me just over and over again.

And eventually I was like, okay, fine. Like I made him an account in our demo instance. And I was like, okay, play around and tell me if you see anything. He wrote up six pages of notes and like literally was in the product for four hours. Like I watched his session, it was after that where I was like, okay, go talk to Anika who runs customer success.

It's like, fine, you can, you can talk. And Anika talked to him was like, this guy's amazing. And so like he just showed effort. And it's crazy because since he joined, he acts the exact same way. Like he raises his hand all the time. He just does it. So my takeaway from that is I can see it when it's superlative, and maybe I don't hold the bar high enough because I just need to wait for that more and more.

I think that when it becomes just glaringly obvious, you can see it. And otherwise, it's, I don't know, it's probably all the same tropes of like, go ask the people that they worked with at the last company, like, were they great type stuff. I, I tend to like, really like social recommendations and things like that, which I'm sure are biased in other ways.

But like, if 10 people tell you someone's outstanding, then they're outstanding.

Brett Berson: How do you think about the topic of founder market fit?

Colin Zima: At least for me personally I would not be able to start a company outside of data. So I think it's just most important that you're honest with yourself as a founder. So like, there's the founder hat and the investor hat. Like I can't answer it from the investor perspective, like which type is better.

But I think that as a founder, what I can say is that If I am not like obsessed, if I don't feel like I have a competitive advantage, thinking deeply about the problem set, I probably don't want to be working on that problem. Or I don't feel like I'm the best person to work on that problem. So I think that you have to understand what your embedded advantage is as an individual.

It could be that you are willing to outwork everyone. Like, I don't think I'm going to win on hours of work. I think that my embedded advantage in data is like, I have a very strong network. I have really strong points of view, and I'm the user of the product. And I continue to think that sort of like being a super user of your own product is the single most valuable trait that you can have, as long as you can build other people around you that can fill in the other things.

I mean, that said, I listened to your conversation with the Vanta CEO, and it's like the exact inverse. It's like exactly how I would imagine a consultant building a company or like an HBS grad building a company. And I'm sure that companies can be built successfully that way as well, like hyper analytical.

It's just going to be a different type of company. And so I think the biggest thing is that for the individual, it needs to match sort of like your expectation of what you need for success. And so for me, founder market fit is like the single most important quality. And I think that that may be true in other areas, but it might not.

Brett Berson: What have you figured out about either becoming a PM or hiring excellent PMs that maybe is a little bit counterintuitive or kind of part of the way that you see the world?

Colin Zima: Yeah. I mean, my most unpopular point of view here is like, I don't think PM is a craft at all. Which is probably evident from my previous answers about, you know, the process. Like I think a PM is literally the intersection of caring a lot and then having some domain expertise. So I loved PMs at Looker that were sales engineers that just had like really deep product knowledge.

Because I think that you can't replace an intuition for sort of like the customer conversation with the analytics. And this is just my point of view personally. But I uh, kind of jokingly say, like, I don't like listening to customers. And I only say that because, like, I really like listening to customers, but through my own context.

Like, I want to hear what they're saying, but then I don't want to listen to what they're saying. I want to apply it to, like, my point of view on what they're saying. And I think it's really hard to be an effective PM if you cannot build that point of view. And so, to me, the intersection is, like, a real obsession in the product area that you have.

And I guess it's just a real obsession because it's like it's the combination of the extreme interest and then just wanting to do it. Because like, I do think that you're responsible for plugging all the gaps in everything that's happening in the building process, like you're not writing the code, but you're, you're responsible for everything else around that.

And it requires this sort of depth of obsession that I think is very hard to sort of develop without the equivalent of a founder market fit for the thing that you're doing.

Brett Berson: Do you think raw intellect matters? I mean, going back to like your early days at Google, sort of highly emphasized in the role of product people. 

Colin Zima: I think there's a bar, but I think above the bar, there's, there's no value to it. So like, yeah, you need to be above average intellectually. I think like that's true to do a lot of different stuff. But, I, I think that you need to be above average in a bunch of different stuff. And then what you need, where you need to have all your, your points as a character is just in like, caring the most. It's not a very satisfying answer, because it's like, I, I agree it's hard to test for.

Brett Berson: The takeaway of the conversation thus far is just be excellent. Have good instincts. 

Colin Zima: Honestly, uh, I wrote down our values, like, I, we can talk about this another time, but I was trying to write down the values and the first value that I wrote down, which my wife gives me such a hard time for, these are not our official values yet, but the first value is just be good. 

Brett Berson: Yeah. Don't don't be bad. 

Colin Zima: it really encapsulates like my point of view, it's like, just be good, like, you have a lot of control over being good, and like you, again, like, you can't fix whatever the underlying intellectual horsepower is, or like your height, or I mean, like there are personal attributes that you can't change.

 A lot of that stuff is in your control. And so like effort can plug the gap.

Brett Berson: Maybe a place that we could end is, is the place that I always basically like to end, which is when you think back to your career thus far, who would you say has had an outsized impact or what few people have had an outsized impact and sort of what way, what are sort of the ideas they imparted on you that you kind of keep coming back to? Or attribute to some of the success that you've had thus far?

Colin Zima: I mean, obviously Jamie and I have worked together. I think this is our sixth job together. He's the one that got me out here on the West coast of Google. So I'm very appreciative just to like, I think that we've learned from each other a lot, which has been really interesting. The example I always give for this is kind of the most trivial example, which is my boss at UBS.

This is my first job out of school, and I was like a quant, and used to build these like really complex spreadsheets. And the whole goal was just like, you know, get the analysis right, like make people money. And he always imparted on me this idea that sort of like the way that you appear matters significantly.

And it's sort of, it's the interpretation of the work that you do. It's the only soundbite piece of advice that I ever got that I think about all the time. It's sort of like, it's not always enough to just do the work. It's like how you present the work that you do that matters really significantly as well.

But I, I mean, I always wished I had a mentor and for everyone out there that doesn't have one, I feel like it's, you know, maybe you just won't find one and you take little pieces from every single person that you talk to, because like, I think that's almost the way that I think about things is like, that's the thing I took away from him and like from Lloyd, I took this just like extreme obsession with how your user is doing. And from like, say I'm at Hotel Tonight, it's like this sort of product quality ethos of like just making stuff that feels amazing and the outsized impact of that. And so I feel like I'm just trying to borrow these little snippets from every single person I meet with.

Brett Berson: Great place to end. Thanks, Colin.