Nadim Hossain

Rahul Abhyankar [00:03] Nadim, it's great to have you here and I've been looking forward to having our conversations ever since we reconnected again.

Nadim Hossain Likewise, good to see you.

Rahul Abhyankar So you are VP of Product Management at Databricks. You've been there almost three years and you wrote an investment thesis about why you joined Databricks. Is this something that you've done for every company that you've worked for, writing an investment thesis?

Nadim Hossain [00:27] No, not for every company. You can find the post on my LinkedIn or my blog, nadimhossein.com. I wrote it three years ago when I joined and I realized rereading it that this is actually an investment thesis. The same thing would be the reasons to invest in the company. It just struck me that way. At the time I was thinking of it as where do I want to work, just like anyone? But really it is the same decision when you're joining a private company. It's almost like a leveraged investment. It's even more than an investment. You're not making 10 bets or 35 seed bets, you're investing all of your time. Of course, it has to be a bi-directional investment. Actually the same thing with startup investments—the startups have to pick investors as well. So there's a lot of parallels in thinking about that, and no, I haven't done it for every company.

There's parts of my career earlier where it was more obvious I wanted to work somewhere. Other times it was very opportunistic. Later in my career, especially this transition was one where I really wanted to be thoughtful about that. That specific transition, I had followed my curiosity to go to Uber and work on self-driving. It wasn't to open up any new doors. It had no other goal other than I was fascinated and I wanted to work with the best engineers and I wanted to work on the hardest problems. That's why I went to Uber. When I was ready to get back to my roots in B2B, I wanted to be very thoughtful because my background at that point was a non-traditional background, even though I'd done SaaS for so long, because of that kind of departure. That's what prompted my thinking in more depth.

Rahul Abhyankar [01:55] I do want to come to Uber a little bit later, but I want to stay on this topic of this investment thesis. How did you come up with this way of thinking about your career as an investment?

Nadim Hossain [02:06] Really it was trying to prioritize and evaluate different opportunities. Sometimes there are apples and oranges and really thinking about what motivated me. What did I really want to get out of my career as a PM? I think you should ask that question over and over, even later in your career. It's always day one, to paraphrase Bezos. For me I realized that I had been a founder and I have a lot of respect for founders and I wanted to be at a founder-led company. Look at the greatest companies. They've been founder-led for a long time. You can analyze the numbers or whatever. There's lots of great companies that are not founder-led, but for me, I wanted to be at a founder-led company and that was both a gut and intellectual decision.

One thing also informed by my experience both at Uber and as a founder—products are hard, innovation is hard, AI is hard. I wanted to be somewhere with lots of tailwinds, where there's a big market and lots of momentum towards that market, whether the company or the individual products, wherever they were in the cycle. So those are the things that prompted thinking that way about what is important to me personally. And then I wrote it down because I was excited and I knew I was going to be building a team and I wanted one way to communicate my enthusiasm and attract folks in my network but also outside, was to write that down.

Rahul Abhyankar [03:23] I think this way of thinking about career as an investment, applying some criteria to companies that you're talking to, is a great way to approach that process.

Nadim Hossain [03:33] Everyone has a lot to offer. Everyone's got unique skills and backgrounds and it's really about fitting what you have to offer to the person who has that problem. One person, the advice I gave them was, they were telling me what they wanted, and I was trying to reframe it for them, saying, look, that's the wrong question to ask. What do I want? That can come, but the first question to ask for this person was, you have this unique set of skills, what problem are you solving? Someone has a job to be done in the form of a product role and you're going to solve that problem for them.

That's how I thought about coming to Databricks. My skill sets really fit what they needed at the time. As PMs, that's a good way to think about it, where in a world where you might have some urgency, or maybe someone's out of a job or you're excited about a new space, you want to move quickly and there's endless options. The worst thing you can do is to go after endless options. Just really being targeted is really important. Even in generality, in terms of industry spaces, the people you want to work with, those are reasons to let someone know that you want to talk to them.

Rahul Abhyankar [04:32] Many years ago I had read a blog or an article written by Marc Andreessen about evaluating companies on the basis of market, product and team. I don't know if you've read that, but that's a fascinating piece where he talks about which do you choose—a company with a great team, company with a great product or company with a great market?

Nadim Hossain [04:52] That's a great question and you hear a lot of investors talk about that. Don Valentine at Sequoia, his point of view was market, market, market. The very first thing is the market, even if they have a B team. That's the most important thing. Paraphrasing their point of view, ultimately, if you want to build a really big company, you're going to need different ingredients. When people say they don't care about a big market, what they mean is that the market hasn't revealed itself or that in the early stage it might change. So why focus on the thing that won't change? It's the founders. So I think it's a stage-specific thing as well. If you're doing seed investing, market might be stupid because they might be so early that they're going to be bouncing around different ideas potentially. There's nuance in that.

With that said, the later the company is, the clearer the market should be, and you can see signs of that. If a company's struggling, I've met companies that are billions of valuation on paper and they're tens of millions in revenue and it's very obvious they're struggling with market size. It's very obvious because they're doing things that they shouldn't be doing till they're a billion-dollar company, that Databricks, for example, didn't do. We didn't use the word partner—I didn't hear the word partner in the first year I was here. Maybe six months in started really focusing on upping our game on partners, for example, and the company was already 400 plus million in revenue because the market was so big. If you're a 20 million dollar company and you're spending all your time figuring out partners, there's probably something wrong with the market size. If you're a product manager, you should look at that very carefully. If you're working so hard to make your sales efficiency perfect and you're sub 50 million, what's going on there? To me that's a bad sign. Some of the market is tapped out and you're trying to reinvent yourself.

So I do agree with Don. If you were to pick one as an employee, I would pick the market first, because this is assuming you're joining when the company's already got traction. Team is very, very important. A good team's reputation will suffer if they enter a bad market, and not vice versa. So the team is really important, it's necessary, but for me the market is prior to looking at the team. If you're joining as an employee, the density of the talent is really important. If there are 10 people, you look at founders and the first three engineers are really important, for example. It really sets the tone. If there are 100 people, then depending—if you're joining as a PM actually, I wouldn't look at the PM profiles at all. I don't care about that. That's what I'm bringing to the table. If they suck, they suck, but if your engineers suck, then you're screwed. So I would really look at the quality of the engineering team.

Rahul Abhyankar [07:27] But you also talked about culture. When you are in that early stage of the interviewing process talking to leaders in the company, how do you get a sense of culture?

Nadim Hossain [07:37] That's a really good question. To look at a culture, I would look at the budget. To understand a company's strategy and culture, oftentimes the budget tells you. They're not going to give you their budget. But you can look on LinkedIn. You can see where the employees are based, percentage of employees, and you can also see how they operate. What are they good at, what are they bad at? You can assess that from the outside. As a PM, you should be able to assess their marketing. Maybe it's bad and maybe you're okay with that because you don't care about that as much. Or maybe it's really important to you because you want to join a company that has a competence in that. Those are things you can assess.

But I would say both the market and the culture, you should definitely talk firsthand. Just as a PM, if you're evaluating a new product idea, you're going to go to the source and talk to the customers and users for a new product. If you're entering a company without talking to any customers, you're really dropping the ball. You should be first-principle, figure out a way to talk to a customer and say what do they think? It's n equals one or five. But even entering as a VP of product, I talked to multiple customers. Just see what they say. Oftentimes, as a new product manager, as a new executive, that's always going to be the currency that has value. Any good company cares about their customers and any senior executive wishes they spent more time with customers. I found this to be true generally. So if you're coming in as a PM and you already start doing your job, saying, here's something I learned about your customers or your non-customers—both are interesting—I think that's an important part of the diligence.

Rahul Abhyankar [09:03] Let's go to Uber. Looking across your career journey, you've had experience in B2B enterprise market, and then you had your own startup with BrightFunnel that you were the CEO of, that was in the marketing analytics space, and Databricks, which is a data platform. So many interesting domains, so many interesting types of markets. But the reason I am curious about Uber—you were driving product management for hardcore research at Uber. How did you get into that?

Nadim Hossain [09:34] It's a good question. After BrightFunnel I did go through an exercise of thinking about what were my priorities. I was leading as CEO 50 people and all that kind of stuff. It's often a lot of fun being a startup CEO and very hard. I realized what I wanted next was learning. Even though I was whatever, mid-late career, I wanted to keep learning. I also wanted to have impact in a way that in a startup you can't quite have the level of impact I wanted to have in terms of touching number of users and customers. I'd done only B2B in my career until that point. I realized that to go to an environment that had large-scale engineering problems—mostly those are in consumer. Obviously the three big hyperscalers in their cloud divisions also have those kind of large-scale engineering problems. But that's something I wanted to do. I hadn't done in my career really until that point. So the usual suspects were Amazon and Uber and Google and whatnot.

I also wanted to be an IC. I just want to be a senior IC and learn and ship stuff. Initially I went to Uber. They had a team that was building something similar to BrightFunnel, had a lot of similarities. Uber was spending in 2017 a billion dollars a year on various rider, driver, eater acquisitions, promotions, all these things to build this marketplace. The problem definition was how do you make this efficient? One way to make it efficient was to have internal data science teams, internal analytics teams and internal software that would do things like calculating lifetime value or bid on certain ads and not on others.

Originally I joined that team and built things that were new to me. We were trying to use ML at BrightFunnel, but in B2B you'd have less data and it's a little harder to do interesting things. For example, we built this multi-armed bandit model to go bid on job ads and to acquire drivers, even though they're not employees, they're contractors. So you're bidding against UPS for someone looking for a job in Cleveland. You could be a UPS driver, you could respond to this ad from Uber and go sign up as a driver. So that driver acquisition channel is an example of some new things that I was helping with. That was super interesting. It was a great way to get a foot in the door to Uber.

About six months in, I realized that I was exhausted after doing my startup four plus years. I said, look, I want to take a break from managing people. Within six months I was refreshed, my energy was back to 100% and I was a little bit bored. I missed the challenges of leading people and all the things that come with that. I was chatting with the self-driving team, which is something that I didn't think I was qualified for, but turns out, no one is qualified for that. No one had built self-driving cars that were commercial, certainly, but really 2019 was a lot of big problems to figure out.

I looked at that and thought, ultimately BrightFunnel was a software product built on a data platform, and a lot of that we had to create ourselves. Uber obviously was trying to do this bidding on top of this massive data, and self-driving is kind of a similar thing. Ultimately you've got to have the autonomous autonomy software that's sitting on the robot and all the other pieces drive around either in a virtual world or in a real world, and you can test itself and then you make the models better and you ship the new models. So it's this big dev loop that's unique, obviously, in some ways, but in other ways it's just like any other dev loop. One self-driving car at the time, I was looking at some data—it produces as much data as all of Google Photos in a year annually. One car versus all of Google Photos.

Rahul Abhyankar [12:45] This is an interesting challenge.

Nadim Hossain It makes sense that everything from the core data platform and the time the data centers operate to all the models trained, all that stuff has to be rethought. It just seemed very novel and interesting. Looking back, I'd characterize it as I had never worked on frontier tech or research in my career, and it was an amazing opportunity to do that. If you're at a really big company like a Microsoft, I'm sure you can move around and seek those opportunities. But in Silicon Valley sometimes those changes come from job changes.

It was fascinating, and specifically one of the things that my team was leading product for, simulation in self-driving—that's really the whole ballgame. Sure, there's the hardware, there's sensors and those change every few years and then the models have to operate with that sensor kit. So there's a lot of complexity in the system. It's a system integration engineering problem. What I really enjoyed was, in a research environment you have 30 engineers, 40 engineers to 1 PM. It's much more engineering led at that point in the journey and it's a different kind of challenge. I was looking for that challenge at the time and really enjoyed it.

Rahul Abhyankar [13:50] Just to contrast product management in a research or a heavy engineering led area, the problems are really coming from a lot of super smart engineers. They are the ones identifying the problem. So how did you reorient your mental models about product management to that situation?

Nadim Hossain [14:07] It is a different kind of challenge. A software company like a Salesforce or a Workday might have even less than 10 to 1. It might be 6 or 7 to 1, where that kind of organization will also have room for more junior PMs who are feature PMs or specific UI or API. In the case of a research environment, it's not coming from bottoms-up customer research. The user wants to get in the car and get to drive somewhere. That's very clear. The challenge is, how's the maps going to work? How's the navigation going to work? How are we going to detect and classify the different objects, whether it's a stationary object or a vulnerable road user, like a person or a cyclist. So those are more engineering problems.

How to reorient? First of all, it's expectations. What is the role of the product manager? If you have clarity that ultimately you might have to wear multiple hats, ultimately trying to be truth-seeking, get to a better product. In this case, it might not be a user-oriented truth-seeking journey. It might be more about what are the problems and timelines and different systems that are coming together. That's almost having a systems engineering mindset, or engineering mindset, not just a PM mindset. That thing is important.

For me as a leader—and I've done this at Databricks as well, there's some commonalities—the thing was to reorient on what kinds of people would succeed. One quality that's really important is humility, because it's not product-led, it's engineering-led. What does that mean? Well, you have to be okay with that and take a backseat on some decisions, or enable existing decisions. That's really important because when the domain is moving so quickly like it is in research, you can't be as bottoms-up in terms of customer problem and that solution and all that kind of stuff that we all go through. That loop has to be a bit faster.

Rahul Abhyankar [15:50] You mentioned the word truth-seeking a couple of times. What do you mean by that?

Nadim Hossain [15:55] It's a personal value, but it also aligns well with the product management journey. It also aligns well with the investment metaphor we're using. It's really getting to the bottom of something. Obviously, you care about people, you care about people's feelings, you care about how you get it done. The how is important. You don't want to be a bull in a china shop. Those are all must-haves.

But ultimately, if you're not getting to the crux of the issue—what are the priorities, why are those the priorities—you're not doing your job as a product manager. If you're shipping product, it could be to solve a customer problem, maybe you're looking at a new market, you're improving reliability, whatever the goal is, just really being clear about, this is the goal, this is how we're going to achieve that goal. And then, have we achieved that goal? To me that's also the definition of how you build trust and how you show integrity. You say you're going to do something and you do it. You also have to tell people you've done it. If you go through that cycle over and over, people are going to trust you and you're going to be perceived to have an integrity, which I think is accurate.

Rahul Abhyankar [16:51] Excellent. Let's deconstruct machine learning and AI. You've worked with these technologies in your startup BrightFunnel that you founded, at Uber at a much bigger scale, and also at Databricks.

Nadim Hossain [17:03] At BrightFunnel, the company I founded, it was marketing and sales analytics trying to give you insights into attribution, into all these dozens of marketing and sales touches, which are the ones that are most predictive, most valuable, and where should you put your dollars, whether you have a sales development team or marketing channel. We were working with B2B customers. One thing I remember is, we thought there were large datasets that were large enough that we had trouble keeping up with the data pipeline, doing all the complex joins to come up with attribution logic. But looking back, given the infrastructure that exists today, it's not very large, even though it was all the data. It was basically all the CRM data from 100 enterprise companies, like New Relic, Cloudera, Hortonworks, SAP. These are all of our customers and we'd say, give us the keys to your Salesforce so we can give you this insight. They said, sure, here's the keys. So there's a lot of product-market fit where they'd give us all the data. But pulling it into our system and analyzing it was non-trivial. Initially it was just getting the data in and doing basic analytics and then doing this attribution logic, which was an algorithm and we filed a patent on it. But it was fairly straightforward. Initially it wasn't powered by ML, it was more heuristics.

Towards really the end of the journey, before we sold the company, we were doing some experiments with ML and I remember the first prototype we had. I was so excited about it. But sitting down with a customer, we showed them the weights and we realized the user experience really matters. This is an analytics product. You're telling them something about their data. When we showed them an insight, they said, what does this mean? Well, this means that your field marketing team has zero value, it has no predictive value in terms of the influence on revenue. And they said, well, what do I do with this? We don't believe it. We believe field marketing is important. Our sales team will kill me if we get rid of field marketing. And anyway, I wouldn't shut down a team. These are people. I can't shut down the team. So it was really humbling to realize that he was completely right. That insight doesn't carry any action or weight because it's telling you something that's impossible to do in the near term without giving you enough trust in the product.

If you work backwards from this, any product that's using ML to make a recommendation—if it's a closed loop, it's a different problem—but if you're recommending a human action, you have to build the trust that you trust the recommendation. We realized that we have to bring them along. First they have to believe that we have all their data because we're ingesting it from different sources. Then they have to believe that we did the right things with their data. Humans are distrustful by nature. They're going to say, wait, I don't believe this insight. It must be because you forgot to update the data. So you have to build things into a product to say, last refresh, or data source, things like that. UX is really important.

And then, of course, the data freshness is really important. The data pipeline has to be robust and well architected, it has to be fast and all that kind of stuff.

If you look at something like Uber, it's a very different problem. That's one of the reasons that drew me there originally—there's tons of data. It's very unique, this geospatial data, for example, that Uber had. It's combining the real world with the virtual world, which is super interesting. It's got this unique thing about marketplaces and then local cities. The market balance, supply-demand is very important. So it was a good use case for advertising, where you're trying to take the foot off the gas or press it harder, depending on how important a market was to Uber, which is information that only we had. That was super interesting to me. But the difference was it wasn't a recommendation, it was oftentimes an action like a bid. There were also recommendations we were making to marketers internally, but they were internal employees so it was a little bit easier to influence them, or there's more trust. But when we're doing bidding, that was a closed loop. So that sort of influences how you think about the product.

And then for Databricks, obviously this is a data platform, so it can power things like BrightFunnel analytics applications—we have customers building analytics apps on top of Databricks, lots of them—or data warehousing applications. Or it can power advanced AI, things like self-driving, and we have examples of that as well. So it's more horizontal across all different use cases. Here there's both the problem of it's a tool to enable AI and ML, but it's also a product that's powered by AI and ML. Both are true and both are priorities. There's some parallels with some of the things I've done before. There's things that are a bit more closed loop, like where we're using ML to make how we provision compute intelligent for our customers, and that's something where we see the margins, the customer sees the customer experience, of course, like how fast compute spins up and all that kind of stuff. But there's a bit more closed loop. We have AI assistants in the product now. We have recommendations that are going to be more of the other use case, where you're telling someone to take action, where you have to have a certain level of fidelity and trust.

Rahul Abhyankar [21:42] Looking across your experience with ML and AI at BrightFunnel, Uber, Databricks, one thing that has happened with product managers is the number of different functions that they have to interact with in order to bring the product together has continuously kept expanding, from UI UX designers to data scientists, now ML and AI. We're talking about researchers, ML AI engineers and ML AI ops. So how does product management work effectively with ML AI engineers and ML AI ops?

Nadim Hossain [22:17] A lot of companies are in the basic phases, which means it's the data, stupid. Do you have the data? If you don't have your data figured out—what is the right data, who has access to it, where does it live, what does it cost, what are the pipelines—you're going to have trouble doing anything interesting with AI and ML. That part doesn't change, and probably anyone listening to this has experience with data and data platforms. So that's the same skills that you're applying before, just on platform creation and management.

How do you work with these different functions? Just understanding—data teams understand data, data science teams understand data science, but oftentimes there are some insights that the PM has to bring in. Why is there a blip here? The data science team can try new models or predict things, but they might not know that every winter there's a blip because it's an e-commerce company or something. Those are insights that data science teams can have, but they're not domain experts. That's not their job. The PM's job is to be the domain expert, typically, or the engineering leader's job. Just make sure you bring in the insights into each other's process. Not just analytics changing your product priorities, but maybe even PMs making sure they're helping shape the models, shape the process of what data is collected. Because there's judgment calls throughout. It's not all black and white. For example, how do you define a metric, how do you collect it. Those are things that PMs can have influence on as well.

Rahul Abhyankar [23:40] You started BrightFunnel and you were the founder CEO. When you are building your own company, that's where you are continuously looking for product-market fit. But as you go through those stages of growth, you find that your platform needs to be re-architected for a different level, a different scale of growth. There is that inherent tension between building customer-specific features versus investing in the platform. And it's not just that you face these tensions when you are in a startup, but even large organizations have to go through these aspects of what are you going to prioritize—customer-facing features or investment into the platform and retiring the technical debt. Love to hear your thoughts on these tensions.

Nadim Hossain [24:24] For sure. If you look at the crux of the issue, it's about time horizon. What are you optimizing for? The faster the company is growing and the more dynamic the landscape is, like the ground you're standing on, the shorter your horizon has to be, because there's no point trying to predict where things are going. For example, here, horizon in the last few years really has been up to two years. It's been certainly immediate term executing what's happening. But there were no three-year plans on the product team. Sure, you had things in your later bucket—someday we'll build this. But things that have some desire to build, like a specific thing within my PRD, it was really more or less max 24 months.

When I was interviewing people coming from—let's pick on Google because they're obviously one of the most successful companies and easy to pick on—sometimes the PMs were saying, and even the people that joined was, hey, look, we've got to look three years out, we've got to build three years out, because they were trained very well at Google to think that way. First of all, everything's solid. The platforms are already, the dev platforms are very mature and very robust. And then you've got a monopoly generating, spewing out cash, and so you can think long-term, also growing slower than a company like Databricks. So it's a different reframing. What's right for Google isn't right for Databricks. You can't think three to five years out, that's a recipe for not having a job. You're going to fail. On the other hand, as we get bigger, as any company gets bigger, you should probably lengthen your time horizon.

So your question about tech debt and building platforms versus user-facing features—there's not an easy answer. It's always a trade-off of priorities. For a startup, it does make sense to take debt. You value the present a lot more than the future. You've got a high discount rate, back to that investment metaphor. If you have a high discount rate, you are trying to optimize the immediate a bit more than the future. It's just balancing that compared to a much bigger company. As you get bigger, you have to think a bit more and more about how do you make that trade-off.

One framework I think that a lot of people find useful is the idea of one-way doors and two-way doors. If something is a decision you're making that's impossible or very hard to unwind, then you should make it in the present very carefully. You should be very judicious. But if it's, look, we can do this, but the consequence of making the wrong decision will be we throw away the work, we're going to take on tech debt, it's going to result in throwaway work—that's probably fine for a startup. Because, a very simple example, do this work to get revenue or do this other work to build a long-term, stable platform? Well, if you're a startup, your default is dead or default alive, that Paul Graham uses. You're worried about survival.

The CEO's one job is to not run out of money. It's the first job, right? Don't run out of money. Your second job might be to build a good product, but the first job is to not run out of money. As a PM, you're also thinking about that. You're not operating in a vacuum at a startup. You're supporting your CEO, who should not kill the company first and foremost, and revenue is the thing that keeps you alive. So that's one framework.

Now, obviously, if your mission of the company is to serve in-market fintech companies, financial companies, and you have a sales rep that's bringing a million-dollar deal that's a healthcare company in Europe and they want a custom feature, obviously you've got to say no to that. If it's not part of your mission, if that development is going to set you back, not take you forward. So it's not an easy answer how to think about that. But I think a little bit of that one-way door, two-way door mindset is important, and also asking the question, what's going to happen when you do succeed?

At BrightFunnel, for example, I think we did do a good job of trading those off, but they were still painful. We made choices that we knew that if we succeeded we would have to then re-architect. In the case of an analytics platform, it's not just the platform, it's the user experience. If it takes too long to get your data to give you an insight, then your product is bad. So those were sometimes things we had to revisit and rebuild.

I think you should always be asking, are we doing something stupid here? Sometimes you have to up-level. It does have to go to an executive level to see that pattern. If five different engineering teams are doing five different hacks to solve the exact same problem, then the right answer is, we should create a small central team to solve the problem for those five teams. Sometimes those are patterns that the individual PM or engineering manager would not even know about. Only a planning process will reveal it.

A planning process is important for that, both at a team level and an aggregate level. That's when you reveal what are we spending our resources on, are these the right things? You can look at us from an edge team. You can look at things like, what is the KTLO budget and what is the day-to-day like for engineering teams. If they're constantly on call and fighting fires, well, maybe that's a sign of having insufficient investments in some of those foundational things, things that don't even require PMs, like reliability. Maybe the PMs pushed the other way. They were saying, hey, I want to build new features, and the engineers said, fine, here's some more feature person weeks, and then as a result, you've had a couple of quarters of unhappy engineers. So you've got to look at that level of data. Those are all things you can measure in terms of bugs or on-call load or reliability—all those things.

Rahul Abhyankar [29:26] Digging into that planning process a little bit, you worked at Salesforce, Amazon, Uber, Databricks now. Can you compare and contrast the different planning processes in these companies?

Nadim Hossain [29:37] Very, very different. There is some uniqueness. Salesforce, they called it V2MOM. It's their own internal OKR process and it was very religious. In hindsight I really appreciate that Benioff and Salesforce in general were so dogmatic about everyone, individuals having their own V2MOMs, teams having it, and cascading, rolling up. I think they did a really good job of that process. It's one way to drive clarity on company-level vision and how you roll up to it. Now, it does get kind of silly when you have a five-person team having a vision. Company vision really is the thing you're going for. But it's worth the effort. I think it worked out well for them.

Most companies don't have that kind of rigorous OKR process. OKR kind of collapses—the key thing is to be clear on your goals and how do you measure those goals and how you're progressing against them. So I think OKRs are really important. That said, we talked about speed and the landscape of the company. The higher the level of growth, it might become harder to keep up with that.

I'll give you an example that I think people resonate with. We had an executive meeting, nothing super sensitive. Our CEO was leading here at Databricks, and we had just finished our OKRs for the year, and Ali, our CEO, was saying, look, we've got to make LLMs number one priority. This is before we bought Mosaic, which is a big acquisition, before we shipped product features around LLMs. But it really was a top-down thing. I think it's really inspiring that he did that. Even the executive leaders, there was a little bit of eye-rolling or grumbling, like, really? We're in the room together, really? We just locked our OKRs like a month ago, maybe weeks ago. You're really going to change your number one priority? He sort of took some of the tension out of the room by making a joke about, hey, look, you guys, if a meteor hit the planet, you'd be complaining about focusing on the meteor and you wanted to go back to your OKRs. He sort of made it clear that this is important for me as a CEO, for us as a company. We should focus on it.

As a CEO, he had a view into trends that we didn't all have, or we were a bit more in the weeds even as executives, but it was clear it should be a priority. Clearly it was a red call. That's an example where being dogmatic about OKRs would have been silly. If we have a process that's too heavyweight, given how fast this data and AI landscape changes, we would just be shooting ourselves in the foot.

That said, when it's dynamic, there's consequences. You don't have clarity. You have to deal with more ambiguity. It might feel like someone's doing something that opposes your goals because there's not clarity on how everything cascades as much as there might be at something like a Salesforce, even in the earlier days. So it really varies by company.

Rahul Abhyankar [32:08] Excellent. Nadim, we'll come to the rapid-fire round of this discussion. Are you more of an audiobook person or smell-the-pages-as-you-read type of person?

Nadim Hossain [32:20] I do both. I definitely love both audiobooks and podcasts, but I always have a physical book that I'm reading as well, maybe slowly. Audiobooks and podcasts are a very interesting medium because it is very intimate, because it's straight to your brain. It's only one mode of communication. You're not looking at something and hearing something. I think it can be very powerful. I think both are great.

Rahul Abhyankar [32:42] Which is a book that you are reading right now or listening to right now?

Nadim Hossain [32:46] The physical book that I'm reading—I'm blanking on the name. It's the producer. Clearly it's a great cover with a dot on it. It talks about creativity. What's the name of the book? I'm forgetting.

Rahul Abhyankar [33:01] Oh, The Art of, by Rick Rubin.

Nadim Hossain [33:04] Rick Rubin, yeah, exactly. It's very minimalist cover. It's all about creativity. He doesn't put himself in the book at all. That's how much he takes himself out of the picture. He's talking about his ideas. It's one that you can read in snippets. Parts of it are interesting. This is kind of silly, but I have found nuggets to be very applicable to a problem I'm dealing with that week. For me it's more of a slow read because it's reflective. So that's been an interesting one.

Rahul Abhyankar [33:35] Rick Rubin's book seems like you could pick up and skip to any page and you'll have something interesting to read, that type of book.

Nadim Hossain [33:44] Exactly. Because creativity—clearly he's someone who is an expert or is very steeped in creativity. As product leaders, yeah, we're creative, but that's not the number one thing we're good at sometimes. So it's a good reminder of some of the things that are a bit more softer aspects of creating products or inspiration. It is hard to pin down, but he talks about it in a really relatable way.

Rahul Abhyankar [34:10] Excellent. Well, Nadim, thank you so much, really being gracious with your time and your experience and wisdom and the knowledge that you've shared. Truly appreciate it and look forward to talking again soon.

Nadim Hossain [34:22] Likewise, thanks Rahul. Enjoyed it. Thank you.