Zigging vs. zagging: How HubSpot built a $30B company | Dharmesh Shah (co-founder/CTO)

Some of the best startup advice I've heard is startups should focus on one thing and be really, really exceptionally world-class at that one thing. And one of our early zigs is we are going to do exactly the opposite of that.

You have no direct reports, and I don't believe you've ever had direct reports at HubSpot.

I could become passably okay at management with some training, with some coaching. I don't want to spend n years of my life becoming passably okay at something.

What was that process like to define the culture?

My co-founder and I were having one of our founders meetings and he said, oh, Dharmesh, I hear this culture thing is really important. By the way, can you go I'm like, okay, Brian, of all the people in all companies, like, I am like the worst possible person. It's not that I don't like people, I just don't like being around them a whole lot.

Something that's really unique and interesting about you is you're obsessed with comedy and keynote prep.

It comes down to this metric that stand-up comedians use called LPM, laughs per minute. I have custom software that I've written that will say, okay, here are the points at which the audience laughed.

Today my guest is Dharmesh Shah. Dharmesh is the co-founder and CTO of HubSpot and also one of the most fascinating and first principled thinkers I've ever met. In our conversation, we cover a lot of ground. Dharmesh's hilarious and ingenious approach to putting together a talk, including measuring laughs per minute. His biggest lessons from being a public company exec for over 10 years now, especially while being a startup guy at heart. How he approached creating and scaling the culture of HubSpot, which you'll find both hilarious and inspiring. Why founders and product teams are all fighting the second law of thermodynamics, how to zig while everyone else is zagging, how and why Dharmesh leans into his strengths, including never having a single direct report during his 18 years of running HubSpot, and so much more. This episode is so fun and will expand your mind in many ways. With that, I bring you Dharmesh Shah after a short word from our sponsors. And if you enjoy this podcast, don't forget to subscribe and follow it in your favorite podcasting app.

Or YouTube.

It's the best way to avoid missing future episodes, and it helps the podcast tremendously. This episode is brought to you by xFlow, a game changer for customer-facing analytics and data reporting. Are your users craving more dashboards, reports, and analytics within your product? Are you tired of trying to build it yourself? As a product leader, you probably have these requests in your roadmap, but the struggle to prioritize them is real. Building analytics from scratch can be time-consuming, expensive, and a really challenging process. Enter Explo. Explo is a fully white-labeled embedded analytics solution designed entirely with your user in mind. Getting started is easy. Explo connects to any relational database or warehouse, and with its low-code functionality, you can build and style dashboards in minutes. Once you're ready, simply embed the dashboard or report into your application with a tiny code snippet. The best part? Your end users can use Explo's AI features for their own report and dashboard generation, eliminating customer data requests for your support team. Build and embed a fully white-labeled analytics experience in days. Try it for free at explo.co/lenny. That's explo.co/lenny. This episode is brought to you by Vanta. When it comes to ensuring your company has top-notch security practices, things get complicated fast. Now you can assess risk, secure the trust of your customers, and automate compliance for SOC 2, ISO 27001, HIPAA, and more with a single platform— Vanta. Vanta's market-leading trust management platform helps you continuously monitor compliance alongside reporting and tracking risk. Plus, you can save hours by completing security questionnaires with Vanta AI. Join thousands of global companies that use Vanta to automate evidence collection, unify risk management, and streamline security reviews. Get $1,000 off Vanta when you go to vanta.com/lenny. That's vanta.com/lenny. Dharmesh, thank you so much for being here and welcome to the podcast. Thanks for having me.

Thanks for having me, Lenny. It's an honor.

It's my honor, and thank you for joining me. You are a wildly fascinating human, and so I thought it'd be fun to start with just a bunch of fun facts that I found about you online. And what I'm thinking is I'll just walk through them. Tell me if they're true as I walk through them, and then this is gonna lead to a bunch of different topics that I wanna talk about. How does that sound?

Sounds great.

Okay, here we go. So one, you have no direct reports, and I don't believe you've ever, ever had direct reports. At HubSpot.

That is correct. 7,000+ employees, exactly zero direct reports from time t equals zero.

Okay. We're going to talk about that. Uh, you also don't do one-on-one meetings as a result. You don't have reports to have one-on-one meetings with.

That's correct.

You built many side projects while at HubSpot, including a product called Wordplay, which at one point made $90,000 per month and had 16 million users.

That is correct.

You also bought chat.com for $10 million and then you sold it 2 months later for, for more money than you bought it for.

It was actually $15+ million, but I had kind of stated 8 figures, but yeah.

Ooh, look at that. Is this, is this breaking news?

It's breaking news. Yeah.

Wow. So that's how much you bought it for?

Yes.

Okay. And you sold it still for an undisclosed amount. Is that right?

Undisclosed amount. And yeah, and more than that. I'll just say that.

Yeah, there was a profit and I knew you gave some money to charity and there's some promises you made where people commented on your LinkedIn posts and you gave more money away. So it was awesome. Okay. Also, you're a billionaire.

That is once again true. It's still true.

Great. Uh, also you were born in a village in India that had no paved streets, no traffic lights, no hospitals.

That is correct.

Okay. Before HubSpot, you founded 2 companies, but I think the, the more important fact there is you promised your wife you would not start. Another company before you started HubSpot and then you ended up and went on and started HubSpot.

Yes. I had promised her that I would not do startup. I had to kind of hang up the proverbial entrepreneurial hat. Best laid plans and all that. I met my co-founder in grad school, which is, that was the plan was, oh, I'll go back to grad school and go find myself. And then the plan was to go eventually teach, not do another startup, but then I met my co-founder there and one thing led to another as these things go.

I hope she's forgiven you.

I do too.

Okay. Final fact. Uh, so, uh, Kip, is that how you pronounce his name? Kip, your CMO?

Mm-hmm.

Okay, great. So he, I asked him what to ask you and he tells me something that's really unique and interesting about you is you're obsessed with copywriting and comedy and keynote prep, that you have a very unique approach to preparing for a talk and how you think about humor and slide design and story arc.

That's very true. This is, um, Public speaking is not something that comes naturally to me. So we're gonna start there. We can talk a little bit about the copywriting, other things that are sort of related. And when one of the, you know, and I try to not do things that I'm not good at and don't enjoy. One of the rare exceptions that has snuck through is the need for me to get on stages as founder when we have our annual HubSpot event, our conference, which at the time, When we did our first one, it was like 150 people at the Marriott, right? And then it's like steadily grown since then. And so now it'll be like 10,000 people in the live audience and hundreds of thousands online, right? So, but as I kind of came to this realization that I was not going to be able to kind of talk my way out of it and I kind of saw how, where this was headed, I'm like, okay, this is something I'm going to have to actually like learn because I can't delegate it, can't Talk my way out of it. And so I'm a big believer in this like talent versus skill, right? So we all understand talent. It's like if someone has a talent for music, someone has a talent for athletics, whatever it happens to be. And that's true, that exists. But the way I think about it is talent basically controls the slope of the curve, but most things are actually acquirable skills. So for instance, if you have a talent for music, let's say you might learn music faster, than someone else and your ceiling may be higher, but does not mean that other people can't learn music, right? It's like an acquirable skill. That's kind of lesson number 1. And lesson number 2 is that there is a process, and this is the engineer in me, of just kind of functional decomposition of a problem to say, okay, in order for me to be a pretty good public speaker, like what are the underlying sub-skills required in order to accomplish that?

Okay.

Skill number 1, you have to be able to stand up on stage and not pass out. Like, yeah, that's kind of the bare minimum, right? And so what I did over the years is to say, okay, I'm going to functionally decompose this skill of public speaking in front of, you know, in what I call like high-stakes speaking. I've got to like actually hold the audience's attention. That's part of the success. So it doesn't matter what the message is, doesn't like nothing else will matter if I lose their attention, which is increasingly easy to do now in kind of short attention span society. And every year I will pick a different part of the public speaking skillset and say, oh, I want to learn about slide design and visual expression, not the actual design. I'm not a designer. But then the one thing that I came up that has had the most impact is humor. Then you break that skill down just like an engineer would do. It's like, okay, well there's humor writing, there's humor execution, like on stage, whatever. There's standup comedy. There's like, okay, so like how do you put all these pieces together? And along that journey I came up with this, and I've always had this. I'm a very kind of data-driven, Quant-based person. I was like, okay, well, how will I know whether something is like actually funny enough or not, whether I'm losing the attention or not? And so in preparation for one of these kind of high-stakes keynotes that I do every year, I will have, you know, I will have my talk, I will do practice runs, I will have increasingly larger actual live audiences that I will practice it in front of. I will record those talks. Everything so far, nothing unusual yet. I will have the talks transcribed. I have custom software that I've written that will say, okay, here are the points at which the audience laughed. Like actually audibly laughed. That's the only way it counts. And this actually, and it comes down to this metric that standup comedians use called LPM, laughs per minute. And there's actually a benchmark that you can say, oh, well, you know, And standup comedians have a very, very high LPM. Business talks have a very, very low LPM. Like the most popular TED Talks, there's a high, strong correlation between the most popular TED Talks and high LPMs. So I have a goal. I'm like, I'm going to have a minimum and I want to improve. And so I have software that will calculate for laughs per minute. And so then you learn these little kind of tools of the tricks of the trade. So it's like, okay, if you're solving literally for that ratio of laughs per minute, there are 2 ways to improve it. One is to add more laughs. 2 is to decrease number of words between laughs, right? So it's like, so when I, one of the things the software measures, it gives me a visual map. It's like, here's the entire talk broken down with a little square per minute of talk or 30 seconds. And it's like, here's what they laughed. It's like, oh, here I went 1 minute and 17 seconds and nobody laughed. So I have to do one of 2 things, shorten that segment if there's nothing funny that can be said without being overt about it. Or I have to say, okay, I'm going to find something funny to try to inject into this and kind of break it up anyway. And that's a long way of saying, if I can get up on a public stage and learn that particular skill, anyone can learn just about anything. It just comes down to practice and measurement and just getting incrementally better over time. That's—

Wow. I feel like I've just learned so much about you and how you think just from that question and how you approach this problem. On this humor piece, I'm curious, any lessons to share on how to be funny?

So, one of the kind of tricks of the trade in humor, and you learn this particularly in standup comedy, but just any comedy, and I just hadn't thought of it this way, is that, and this is very tactical, but it works and it's a very easy thing to apply. So, let's say you're looking at, and most of us in the, you know, we're not standup comedians, we're not going to tell jokes in the classic sense, right? And even standup comedians don't tell jokes, right? Like they actually have stories and they happen to have Punchliner 2. So the 2 tactical pieces of advice. One is when you're telling the story, whatever the funny bit is, those have to literally be the last words of that particular segment, right? So once you deliver it, then you have to stop talking. And the reason you have to stop talking is the audience needs about half a second to react, and then they want the permission to laugh. And if you're continuing to say words, It's gonna make them feel awkward and it's gonna be less funny. So even if like moving a phrase in the sentence that you're about to say, it's like, well, that sounds kind of weird to put those set of words at the end of the thing, do it anyway, even though it's awkward because it will actually work better. So that's kind of tip number 1. Tip number 2 on LPM generally is that have a story such that you can kind of spend the time setting up the story, but then have multiple funny bits, multiple punchlines because you've already made the investment. I've said, 75 words in order to kind of set up this context, say something funny that's amusing, that's whatever, say some more things. You already have the content and you'll see the standup comedians do this all the time. And then say something else that's funny because you just, because a laugh is a laugh. It doesn't really matter that it was still the same story. So kind of leverage the investment you've already made in establishing context and scene and then just squeeze more humor into the end of it in kind of punctuated fashion.

I feel like the entire podcast could just be this one thread, but I need to move on to other topics. One quick question. So you said ideal laughs per minute is 2 to 3-ish. Is that what you said?

Yeah. 2+ is hard for a business talk, right? Because standup comedians, the reason they can do it is that's all they're really kind of solving for is LPM. In business talks, you actually have another agenda other than just being entertaining, right? You actually have a message. You're trying to promote something, promote an idea, promote a product. So anyway, anything in my mind for For like most normal circumstances, even if you can get above like a 1, 1.2, 1.25, you're in the top decile, um, in terms of talks generally given, uh, by non-professionals.

Wow. This is incredible. So after every talk you listen, you run this transcript and audio through your program to see how you did.

Yes.

Yes. And are you ever going to publish and release this program? Because that sounds really cool.

I have this notion of what I call soloware. And soloware is exactly what it sounds like. It's software built for exactly one person. And in my case, that one person is me. And so I've been doing this thing for like 30 years right now. I just build things that I would myself find useful. And the nice thing about solo, one of the many nice things about it is that, you know, the UI is only for one person. You don't have to do a whole lot of testing because it only needs to work for one person. And the most important thing is that because it's only for one person, if it stops bringing utility, You can just turn it off. You should stop using it versus if you have users, even 10 users, and you put it out there and then people would be disappointed if you took it down for whatever reason. Uh, that's kind of hard. So anyway, so that's the calculus I go through is like, is this useful enough to enough people where it's worth the calories of kind of making it non-solo-ware, making it even micro-ware? I just made that up, but yeah. So.

Wow. Okay. Let's see how the YouTube comments react and how many people, uh, would want this and slash pay for it. Let me go in a slightly different direction. We talked about how you have no direct reports. You've never had any direct reports. I know that's somewhat related to a piece of advice you often share, which is to lean into your strengths and to not do things that you're not amazing at. So can you just talk about why this is the case? Why don't you have any reports? And, and then this, I think this idea of just like strengths and the importance of focusing on strengths. Yeah.

Um, let me, I'll tell you the quick story, um, as to how this came about. My co-founder and I had the kind of founding meeting for HubSpot. This is like the week where we've decided we're going to do this. And then we have this list of questions or topics for the kind of founders discussion. One of them, and I, this, I think I've published the list. So these are the questions all co-founders should ask each other in that kind of early period. One of the ones is like, okay, well, who's going to be CEO? This was an easy one because I had been CEO twice before and had figured out I'm not that good at it. I actually suck at that. And one of the reasons I suck at that is that part of the CEO role is being good at managing people. It's not just about leading and having a vision of whatever. You actually have to do kind of the management as a craft. And so that part I already had in my head. I think Brian, my co-founder, already had it in his head that we, that's how this conversation, that was a very quick conversation. And in the moment, as soon as I had kind of had that wind behind me, it's like, okay, well, I don't want to be CEO. Brian wanted to be CEO because he'd never done it before. And like, okay, that was easy. And then I said, oh, and by the way, I don't want to have any direct reports. It just like popped into my head as an idea. I had not like pre-planned it or anything, and I sprung it on him. And the reason I, it's like, and it's like, okay, well, and the reason is because I have learned that I suck at management. I'm a reasonably smart person. I think I could become passably okay at management with some training, with some coaching or whatever. I don't want to spend N years of my life becoming passably okay at something. I would rather take those same calories and take the things that I'm good at that I actually enjoy. Those things are highly correlated. You tend to be good at the things you enjoy. You tend to enjoy the things you're good at. It's like, so, and Brian was like, yeah, sure. And then I'm like, no, no, Brian, you don't understand. Because then I was like, there's going to be a time in the company. It was like, oh, our VP of engineering just quit. Like, just be interim something or whatever and have this team report to you until we find— it's like, we're going to have those things. And you're gonna have to promise me we're not gonna do that. We're gonna, it's like, I am not going to have direct reports. And we had that kind of heart-to-heart conversation. And it was one of the best decisions I've made both for myself and for HubSpot. Had I not made that decision, I'm a startup guy. I don't know that I would've survived at a company at HubSpot scale. And right now I can honestly say I'm having a better time at HubSpot now it's 7,000 people than I was having at 70 people. And the reason is I get all the upside of scale, which is I can make big bets. We can have long-term things and plans, whatever, and plan for global domination without the downsides of scale, which is, oh, you're having to manage all these people and all the kind of mechanics. And that's hard, right? It's a hard skill to have. I appreciate other people that have it. I don't. And so I get all the upside with very little of the downside of scale. And that's what kind of keeps me engaged and energized and happy at HubSpot. So I think it's been both productive for HubSpot and good for me.

I love that this is an example of how you can build a company the way that you want to build it. You don't have to do it the way everybody else has done. I imagine there's a lot of challenges to this too, but I think it's inspiring to just like, hey, I'm going to design a company the way I want to build it.

Yeah, it's amazing what you can get away with in terms of shaping the universe to your liking. I think people automatically assume that things have to go a certain way, especially founders. And first-time founders, it's like, you should at least like try it. It's like, okay, well, I want to do it. First of all, I'll give you another kind of tactical example. Both my co-founder and I are night people, not morning people. That just happens. I didn't pick him because of that. We learned that later. And so we made it just like from the early days of HubSpot in the early years, at least we're like, no meetings before 11:00 AM, period. Like that was it. And then we adjusted it, I think maybe 3 or 4 years and we're like, All right. We can have meetings before 11 AM. You just can't invite one of the co-founders to it. So you're welcome to meet amongst yourselves if you choose to do so. But anyway, it's, but yeah, it's little things.

That's an amazing rule. I have a personal rule where I have no meetings before 3 PM because I don't work anywhere. I can more so create my schedule, but the idea is I create this deep work time in the beginnings of the day. I love that.

Yeah.

Okay. So you talked about you're a startup guy at the same time. HubSpot is approaching its 10 years of being a public company, and I think 18 years since founding.

Yep.

I'm curious what lessons you've taken from that experience, being someone that's clearly a startupy person, being an exec at a very fast growing and large company. And I'm thinking from the perspective of a founder who's maybe thinking about starting a company or starting a company, what advice you might have to share for them. And also for people in the exec role today?

A couple of things. One, let's, since we are publicly traded now and this doesn't get talked about enough, I'm going to go ahead and get this out there and use this as a platform to get this message out, which is I think too many founders, once they hit to it, they are very apprehensive of going public and going through the IPO process and being a publicly traded company because they think, I mean, that's like the beginning of the end. It's going to like change everything and my life is going to suck. And I think they're over-indexing On what they think it's like to be a publicly traded company. In my own personal experience, and Brian, my co-founder, would attest to this. And yes, there's certainly a tax or things we have to do now as a publicly traded company that we didn't have to do as a privately traded company. But there are actually benefits. For instance, if you're kind of venture-backed in private, let's say, you're sort of at a little bit the whim of the market and how VCs perceive your category and all these things or whatever. And you get every now and then when you're out raising a round of capital, you sort of get mark to market, right? Like this, now here's sort of what the valuation is based on what someone's willing to kind of fund the company at. One of the nicest things, and this is underappreciated, is that we know right now what the market values HubSpot at. I can tell you that any business day of the week, right? Like that's, and there's a niceness to that. And there's the other thing I kind of tell folks within the company is that, you know, the valuation, which is We're in a relatively efficient market. Like the public stock market is a relatively efficient, by the economic definition of the term, efficient market. And so, but the, so the valuation will oscillate around the value. So if you kind of focus on creating values, like here's what we're actually building, valuation will sometimes be higher than you deserve, sometimes will be lower than you deserve. But over the fullness of time, those 2 things will kind of move in lockstep, right? That's been demonstrated. That's what happens. That's almost the definition of an efficient market is that information kind of moves asymmetrically and then the valuation catches up with the actual value. But here's the other kind of social reason why I think founders should go public, which is so HubSpot's, and I hadn't thought about this, so I'm not going to take credit for being this kind of generous, magnanimous person, is that in our first pre-public years, I think we were 8 years old when we went public, we had created roughly $1 billion in market cap. give or take. We hadn't been a unicorn, so it was slightly below when we went public. So HubSpot was never a unicorn because that's a privately held company over a billion. In the subsequent years, we went from a billion dollars in market cap to $30 billion, which is roughly what it is now. That first billion of market cap creation, a very small number of people got to participate in. The rest of the $29 billion in market cap, everyone, every public investor got to chance to participate in. And so I like the idea of, okay, well, you believe in your company. There's lots of people that believed in HubSpot. It's nice to let them kind of participate. Our customers, our partners, our well-wishers, and they can sort of now have the upside. And you don't get that in the private markets because it's a very closed, you know, you can't just buy shares in every private company you like. I wish that existed, but it doesn't. So it's a way to let the market at large participate in your growth, um, earlier.

What about from the perspective of just staying excited and motivated and finding things to take on? Is there any lessons there for founders that are, I don't know, at a larger company and just, okay, this is going to help me stay excited about what I'm doing?

Yeah, I think this is, um, and Bezos exemplifies this, I think the best, which is, um, just because you're a public company, does not mandate that you do certain things. All that's necessary is the kind of transparency that says, here's what the company is doing. Here's what we're about. Here's what we're solving. And he had this with his very first annual shareholders letter, which, you know, he obviously writes every year, which is, this is what Amazon is about. We're solving for the long term or whatever. And he didn't say this in a snarky way. If you kind of reread the letter, it's like, but if you read between the lines, it's like, if you don't agree with this approach, you should not buy Amazon shares. Right? It's like, it's a completely optional thing. You don't have to buy it, but this is the way we're going to run the business. And you stay true to that and you can continue to do that. I'll tell you one quick story. This is once again the anti-dissuade founders that might be reluctant to go public. So one of the core values at HubSpot that's been part of the culture from the early, early, early, early days, literally days, is transparency. And so one of our kind of mechanisms by which we implement transparency is we've had this thing that says, All information within HubSpot is equally shared with everyone in the company, period, right? Like everything. So our balance sheet, what do we raise capital at, you know, whether, you know, we're gonna be able to meet payroll in 6 weeks, all those things, everything was transparent all the time. And with 2 exceptions. One is if it was illegal for us to share, let's say if we were looking at some acquisition or whatever, and we had Non-disclosure, or the information was ours, not completely ours to share. And one example of that was salaries. So we feel that salaries are co-owned both by the company and by that individual, and it's not up to us to share someone's salary if they don't want to do that. Okay. All right. So we had that transparency, and then as we go public, we have this meeting with our investment bankers and our lawyers. This is my In the IPO prep process and they sit down and as part of this all-day meeting, one of the questions is like, okay, so who are your designated insiders? Brian nor I had ever taken a company public before. We're like, we don't know what that is. It's like, oh, it's this kind of group of people that will have access to kind of all the financials and will note, you know, it's like, and we're like, oh, okay. So how long is that list? And they're like, you know, 5 or 6. And so then, you know, Brian says 7. 7? And they're like, yeah, you could do 7. And then I say, 8? Like, could you do 8? And so what we're— and so we discovered through that mathematical induction process, it's like, if it's true for N, is it true for N plus 1? Is that there's no actual legal limit to how many insiders a company can have. And so we ended up doing literally the day we went public is we designated every single employee to be a designated insider. So that allowed us to maintain the transparency thing because there was no rule that said you could only have 5, 6, 10, and it was hundreds of people. And we did not make it optional. We didn't say, oh, because there are downsides to being an insider. There's windows within which you can't trade. There's stuff. But we're like, okay, well, we believe in transparency. Everyone's going to have access to it. And it's not an opt-in kind of thing. You're like, you're, this is it. We're all in it together. And it's been all, and we still do this to this day, right? Even at 7,000 people.

Everybody's an insider.

So, so we can still share all the financials with everyone all the time.

You have many contrarian opinions is what I'm getting from this conversation already. And the way you're pushing the envelope on, can we have 10? Can we have 1,000? Um, curious if there's anything else there, just contrarian ways of running a company. I know there's probably many, but what comes to mind?

So one of the phrases we like to use in our industry overall is this kind of notion of first principles. I don't know who popularized it, but it's used a lot. And I'm not usually a snarky person. I'm not going to say something snarky, but I think most of the time first principles is used, it's actually used incorrectly. Because the way first principles is supposed to work, as Elon would probably describe it, is that it's not first principles like first principles of what we believe. These are our core kind of first principles in the company. It's the first principles of the universe. It's not what you believe is true. It's what do we all collectively know to be true to the best of our knowledge? Science, right? That's like physics, like the first and second law of thermodynamics. Those are first principles. All the layers on top of that are things that you think are true, are your assumptions or the things, the decisions you made. And that's fine. Like you may have made some decisions, like for instance, transparency is not a first principle. It's a founding principle, right? It's not like everyone should do this. It's like a completely core thing. And so yes, I can be contrarian, but you have to kind of limit the dimensions. So the number of things that you're contrarian on has to be greater than zero, but not too high, right? So you want, what I think of is like high conviction, low consensus bets, right? So high conviction is we really, really believe this. And low consensus is that most other people don't. And there are other people have kind of phrased this differently. I think Peter Thiel actually says it more simply and elegantly, which is you need to be right about something that other people think you're wrong about for a very long time, right? It's like, okay, this is the thing that, and you just happen to be right. So one of the early kind of high conviction decisions we made at HubSpot was that we were going to focus on SMB as our target market. I'll make a case both for SMB and for having a high conviction bet. It doesn't have to be a target market, but something. Once you make that bet, because it's low consensus, it's going to be hard and necessary for you to have the conviction because everyone disagrees, including your board, including your investors, including potential investors. So we had that for all, literally all 18 years of HubSpot's history. We have always had the question all during the IPO roadshows, like, yes, we get that you've kind of on SMB, but so what's the path to the enterprise? Like, no, you don't understand. This is not a go-to-market strategy. This is not like, oh, we're going to conquer SMB first. This is not bowling pin. This is not Geoffrey Moore. This is a, we are here for SMB. This is, that's what we're doing. And so we maintain that conviction for a very long time and that kind of helps you make other bets that are secondary, but you don't want to reinvent everything. So I'll give you an example of something that we had in the early years of HubSpot that we kind of forewent. So in the early years of HubSpot, we're like, okay, we believe in a flat organization. One of the manifestations of that flat organization is we had no titles in the company. Nobody had a title, right? So even though, you know, you had business cards, whatever, we had no titles. If you introduce yourself, you know, in a meeting, And we had this up to like hundreds of people. When you introduce yourself, like, oh, I work in product, I work in engineering or whatever. It's not like I'm director of X or VP of Y because that as a thing didn't exist. Then as we scaled, we came to the realization that there's actual value that people ascribe to titles. And the reason they ascribe value to titles is because there were rumors that there was life beyond HubSpot. Like, I couldn't believe it. What? There's a life out there outside of HubSpot? It's like, yeah, but it's like, and then when we go to the Thanksgiving dinner or whatever and I talk to my aunt, I need some shorthand. It's like, oh yeah, like I got promoted to director. I got promoted, like, you know, to show some progression because it's a signaling device. And in this life beyond HubSpot and outside of HubSpot, it's like other people are also gonna want to know sort of where I was in the— it's like, okay. And this was the winning argument. I love this argument because we had a day-long meeting on talking about this one topic. And the winning argument was, Dharmesh and Bryan, I recognize why we don't have titles. I recognize this. And so they made the case of like, yeah, there's value. And it's like, and by virtue of you not giving us titles, that means you're having to compensate us in a kind of economic sense in other ways, right? So you're losing out because it's like, is that value high enough to not do that? That's a strong case. It's like, and so, and then we had it down to 3 choices. We're like, okay, well, we could have chosen to just stay firm as like still no titles. We could have said, okay, we're going to have classic titles. Then I had the option on the table of make up your own title. Like you can be Grand Poobah of X and that can be your like, and then we ended up making a decision to go with classic titles because that actually served the need of there's a benchmark, there's a standard. Otherwise it doesn't mean anything. So having made up titles, is pretty much the equivalent of having no titles because they lack any, any meaning anyway. Um, but that's one of those things that, okay, you sort of iterate, you change things as they go.

Um, yeah. Yeah. I think there's so much to this. Let's just try things differently. Okay. That didn't work. That's okay. It's fine. We're just going to do what everyone else is doing here. And then often you discover a thing that, okay, this is actually better. Just to understand when people have no titles. So someone say is a product manager, what do you call them? A product manager? You're just like, I'm an employee at HubSpot. I have no, literally no title.

At the time it was no title and now we have classic titles. So we have levels of things and—

But back then it's like, you're just here.

No title. Literally no title.

We don't know exactly. That's what he said. I saw somewhere that you paid everyone $5,000 monthly as their salary at the beginning of HubSpot, including yourselves for a long time.

Yes.

Is that right?

Okay.

Another fun fact. How long did that last, by the way?

Trying to think back. It's a long time ago. I want to say probably like the first year, year and a half.

Amazing.

And one of the things that, and this is one of the kind of core, and not everything that, you know, we obviously not everything was right, but not everything is kind of applicable to other companies, but there are some things that I think are. And one of the things that I think are applicable is just this need to solve for like simplicity, right? It's like the simpler you can make things in the early years, the better off you generally are. So part of, and this is It's going to sound weird. So how we wound up with transparency is not because of like some moral, it's like, oh, everyone deserves to have this. And this is the truth. So it was not some moral position. It was a, when we hired the first employee, and this goes to both Brian and I already, when we hired the first employee, we had to make the decision. It was like, oh, so what files do we give them access to? And so Brian, I just like, All of it. Like, why? There's nothing to hide. Like, why would we do that? And so then we kind of, then the output of that was like, okay, well, A, like binary decisions are much easier than non-binary decisions. It's like, okay, like everything or nothing is like much, much simpler. And then it's like, okay, well, if it works for employee, you know, employee number 3 in the company, why wouldn't it work at 4? Why wouldn't it work at 5? Why wouldn't it work at 50? And we just— Kept doing it because it's like, okay, well, until it breaks, we'll just keep doing that, right? And so this is the, and this applies to so many different aspects of HubSpot, but is we try to start with the simplest possible thing that might work, and then if necessary, add the, you know, add the complexity, add the things or whatever. Like even our original, this is actually a tactical thing that everyone should take away, especially early stage startups. Very first HubSpot office. has exactly 4 tables because aspirations for growth, right? We were in a coworking space, WeWork back in the day here in Cambridge, Massachusetts. And so we had 4 chairs and the only distinguishing characteristic of the 4 chairs, there were 2 chairs that were by the window, 2 chairs not by the window. Okay, great. Hired that first employee. Other decision we have to make is like, okay, well, where do people sit? And it felt, this one, it's like, well, it feels unfair to us that we would just get the window seats or whatever. It's like, okay, we Believe in a flat organization, like why? And so what we did is we said, oh, we'll just do a lottery. Okay. And it's not like, oh, whoever pulls the thing gets the window seat. Whoever pulls gets to choose from the remaining seats because different people ascribe different utility to different seats, right? It's like maybe you don't want a window seat. Maybe you like the dark— darker corner, whatever it is. And so we did that with employee number 1, then did that with employee number 2. And we did it every time we hired a new employee. We would do a seat shuffle. We're going to do the lottery. We're going to go down the sequence and of all the seats, that was the algorithm, right? And our investors were like, oh, that's cute and that's funny. It's not going to work at 15, 20 people. It's not going to work at 50. It worked at 25, worked at 50, worked at 100, worked at 200. We updated the algorithm. We did some local optimizations, which we said, oh, there are some groups that should not be next to other groups because engineers like quiet time and salespeople don't. And so we're going to try to kind of optimize a little bit. So it's not completely random anymore. Now it's like within this, but we still would do it. Then we said, okay, we're not going to do it for every hire. We're going to do it every quarter. And that stood, by the way, for hundreds of people. That mechanism still worked, right? It's like, it's— yeah.

Oh my God.

So the moral of the story is that one decision of simplifying Can you imagine the amount of politics we avoided? Like in corporate America, the amount of calories spent is like, well, your office is bigger than my office. Your desk is 1 inch higher or 1, what it's like. No, it's like all of that just went away by virtue of that one decision. And we don't even know, it's incalculable, honestly, like how much grief that like saved us. And then there's all other kind of side benefits to it in terms of, you know, people getting to know each other better, better chemistry. There was like lots of good upside. But just the simplicity is almost always a better answer.

I love that everything often comes back to some algorithm you've developed or this N plus 1 approach of like, let's just keep going until something goes wrong. This is amazing. I'm, I'm excited for many more of these hilarious, amazing examples of how you did things differently. You've been talking about simplicity. The opposite extreme is you could say entropy. And someone told me that you have this kind of concept that as every, that every leader in every business is fighting The second law of thermodynamics, which I believe is entropy.

Yeah. Well, yeah, the actual law is within a closed system, entropy increases over time.

Okay.

And yeah, but we don't have to get into the details. I'm not a physics guy.

We're getting to the real, the first principles of everything. Talk about that. What does that mean when you, and what does that look like when you're running a business?

Okay. So in layperson's terms, um, the second law of thermodynamics, I'm paraphrasing here, is that Over time, unless you intervene, everything goes to crap. I'm paraphrasing, right? Which is essentially the amount of disorder and randomness in a system is going to increase over time. You see this, like when you break an egg, the break of it, like molecules don't come together and form an egg, right? That doesn't happen. It's always the other way around, becomes disorderly and more random. That's the second law of thermodynamics. And this happens in companies as well, right? Like, and it happens in code, like almost every level of abstraction, you will see Some variation of this. And so the way I think about this is that in the early stages of a company, you're essentially fighting to survive, like just trying not to die, right? That's the thing. Like, okay, like priority one, don't die. In the second phase of a company, you're trying not to stagnate, right? It's like you still want to be able to drive growth and be able to do things like, okay, we managed not to die because stagnation is essentially death. So we're still trying not to die. But then The third stage is you're fighting complexity, and that's the thing that you will crumble under your own weight over time, absent some external intervention. And this, you see this happen all the time, right? And it shows up and manifests in different ways, which is everything gets more complicated. Like you need more layers of management, more headcount, more this, more that, more everything. Everything becomes harder. Margins go, it's like just bad things start to happen. You become slower. And that's eventually, it's a slower death, right? Because you're at more scale now. But it's still eventual death, right? Like complexity does kill companies, maybe not as quickly as other things, but much more reliably than other things. And so this is why it's never too early to kind of plant the seeds of simplicity, put them in there, make that part of the kind of culture of the organization. And we have a thing that are part of our kind of culture and guiding principles is around what I call fight for simplicity. It's literally those 3 words, right? And the message we're trying to convey is simplicity is worth fighting for. That's like thing number one, it's important. But the other one is that it requires fighting for it. It does not happen and it will be a fight because the universe is working against you. And it will take calories to fight for that simplicity because everything, even well-intentioned people, will introduce complexity because that's the natural way of the world. We want more tiers in our pricing. We want these knobs and dials in the product. We want these more, you know, it's like, All of it tends towards the second law and entropy increases. So anyway.

I love this. The algorithm for seeding is a good example of this. Is there any other examples either in the product or strategy where you pushed for simplicity and then ended up being right?

Yeah. So on the product side in the early years, and Brian gets credit for the actual implementation of this. So we had a relatively broad product and we can talk about that, pros and cons of that even in the early years. But we were solving for simplicity and we got this from Apple. We'll talk a little, we can talk a little bit more about kind of genesis of this. But so we had a rule in the HubSpot product as the product grew in those early years that every time you added what we thought of as a knob or dial called a feature, you had to take one out somewhere else. That's a net amount of, and this is a very coarse measurement, right? It's like, okay, well, not every radio button, checkbox, dropdown, whatever menu item that you put in your nav is necessarily equivalent. But it's better than nothing. It's better than having no constraints. And so, and once again, this goes to the kind of binary thing is like, it just at least forces you to think about it, right? It's like versus the, because the other mistake I think people make in product all the time, but is that we measure the cost of a feature based on the usually, or even a new product based on the cost of implementation, right? That's the first order of thinking is like, oh, this is going to take 6 months to develop. It's going to be Y engineers and Z designers or whatever. Second order thinking is thinking through the maintenance of that feature. It's like, oh, it's not just the first version that goes out. It's like, now we have this code base that we have to support and improve or whatever.

I get that.

The third order thinking, which is, I think is the most nuanced and it turns out to be the most important, is the other costs that that complexity adds. Okay. So let me, we'll come back to this. So when you go from product number 1 to product number 2, right? It's like, okay, product number 2 is gonna cost us this much to develop. It's gonna have this Risk associated with whether it's successful or not, all these things. So there's going to be this kind of carrying cost for product number 2. What companies don't think through is that that is even the maintenance of that. It's like, oh, we're going to need a team to kind of maintain that new product. No, what actually happens is that now when you go from product 1 to 2, you have added dimensional complexity to your business. What I mean by that, it's not an incremental increase. Like, oh, we went from 1 to 2. It's like, now every decision you make has to be made through the lens of now we have 2 products. We just hired an engineer. Do they work on product number 1 or product number 2? We're going to launch a marketing campaign. Do we spend 5 minutes talking about product number 1 and 2 minutes talking about product number 2? How do we out— like, how do we do anything? Every chart you look at in terms of the growth, revenue per whatever, like it's all of it now. Every chart that you've ever had now has to be sliced by product 1 and product 2 in order to really kind of capture that precision. And so now you have this new dimensional complexity that you just hadn't planned on. And this applies once again, every level of abstraction. So everything you do in your business should factor in the long-term cost of that complexity and it should be worth it. And that, of course you need, and I can make the case that you need to build product number 2 and product number N plus 1 over time, but you should be mindful about the cost of that complexity.

Is there something you've done to help operationalize that? Because I imagine this Everyone's like, yes, this is great. Don't do too many things. Simplify. Hard to do when you're like, oh, we gotta drive growth. We have this awesome idea. We have this opportunity. We have a competitor. I know this is part of the culture, so maybe that's the answer, but how do you keep people to actually this principle?

So it's really hard. Um, I'll, I'll say that. So, and things that have made it easier, it's a little bit idiosyncratic to HubSpot, right? So part of what has made it easier for us to keep things simple is the early constraints we imposed. And we didn't know this at the time. So, because we're building for SMB, we have a freemium product. All right. Well, when you're doing that, there is literally a limit to how much complexity you can add because we don't have like an army of people that are going to spend 18 months implementing something. We don't have like, we have to be able to support a product that's free. Like, that's hard to do, right? Like, it has to be simple enough that someone can get value from this thing. And so there's these kind of self-imposed things. So the lesson I would kind of carry away is come up with systematic ways and mechanisms, as Amazon would call them, of putting guardrails and constraints in to the degree that you can, because you can put words on a page and try to infuse it in the cultures like, oh, we believe in simplicity, we fight for this. And you can have meetings and you can kind of get up in all-hands meetings and kind of reinforce that, which I encourage you to do. But like a really, even a reasonably well-done system will outbeat any other mechanism that you can kind of try to put in and infuse, right? Like that, those things kind of deteriorate over time. It's hard to scale them. So I'm a big believer in kind of systems that impose constraints versus—

I can't help but talk about this SMB piece because I do a lot of angel investing and classically companies that focus on small businesses are very challenging. Because getting to small businesses at scale is very hard. They're often kind of more old school, not early adopters. You sell one and you, that's just like one small customer and they're not going to upgrade and roll it out to this large group. They're not going to increase spend off very quickly. For founders that are exploring SMB or trying to win something SMB, any advice other than just maybe the advice is probably don't do it. It's very hard.

No, my advice is absolutely do it.

Amazing. Great.

A, because it's hard and we'll talk about that. But B, okay, so I'll tell you this quick story in terms of how we chose SMB. And so this, my co-founder and I met in grad school and he had done software. He's on the kind of sales and marketing side. I was on the product engineering side. Didn't know each other before grad school and we met there. But one of the things we kind of, as we were kind of noodling on possible ideas of working together on a startup, we said, oh, we had both done enterprise software before, right? The kind of opposite of SMB. And there are definitely challenges with enterprise software, right? Well documented. One of the biggest ones is that life as an enterprise software company sucks as a startup. Sales cycles are super long. Feedback loops are super long. You have to have sales. Like there's all this kind of, you have revenue concentration, which means you don't completely own your product roadmap anymore because whoever's writing the biggest check will ask for these 3 things. It's really hard to say no, especially as a startup. All these things that go along with that. It's like, okay, we sort of know that game. At the other end of the spectrum, you have consumer startups, right? It's like, okay, the problem with consumer startups is they have very bimodal outcomes, right? It's like either you're going to be super successful, the next Meta, the next Google, the next whatever, Or it's going to be to zero, right? Like, it's very rare that you have like, oh, you made a few million bucks or whatever. I think like either it worked because it's a massive market. The case for SMB is you have almost the best of both worlds. Okay? You have the nicety of enterprise, which is, oh, I can solve a product and people pay me money for it. I don't have to be advertising subsidized. I don't have this bimodal outcome. I can build an incrementally more valuable business that's measurable. So, oh, we went from $100K in ARR to $1 million ARR to $2 million ARR because we're a business software company. But it has the benefit of consumer because there's millions of them out there to sell to. And there is no revenue concentration. You do control your roadmap. You have very short feedback loops. You can try pretty much anything that you want because there's, you know, like, oh, we have 50 customers. What if we do this and screw it up? It's like, there's 5 million more. Like, not, don't intentionally screw it up, but you can experiment, right? You can take on risks. And so, by the way, like when HubSpot started SMB, it was literally like 100 times harder to succeed in SMB, right? And we could not raise capital. Like it was so hard because I mean, the common argument was like, there literally is exactly one company in the history of software that's made a like global brand, billions of dollars of market cap that was into it. No one else had ever created SMB-focused software company before. And we're like, yeah, it's like, we know. But the nice thing about it is once you figure the physics of it out, because it's so hard to do, you end up, and this has played out now, there's lots more proof points. There's Shopify, there's a bunch of companies that have succeeded in SMB. But one of the things about SMB is that in the software market, this, by the way, all I know is software. That's the kind of scope of my experience is that In software, there's what I call reverse gravity, that over time the market will always pull you up, right? Because what ends up happening is that smart founders and smart management teams will look at the numbers and say, oh, well, as it turns out, our bigger customers stay with us longer, pay us more, often have higher NPS, like all these things. And so if you allow yourself to come be led by that, which is seems like a reasonable, smart thing to do, you will get pulled up in the market. And because of this reverse gravity, almost every company winds up being, every successful software company ends up being an enterprise software company over the fullness of time, right? That's what you see. It's like everyone, the kind of byproduct of that reverse gravity is that every software company ends up being an enterprise software company. So you end up competing with literally everyone. In the SMB world, you're only competing with the people stupid enough to stay focused on SMB or try to do that, right? It's like, it's a much, it's a harder thing to accomplish, but once you figure out the physics of it and make it work, it's a much more sustainable, much more fun model. So I encourage particularly startups, and maybe you fight reverse gravity for some period of time and maybe, but at least start there, try to make it work until it gets really, really, really painful and then try some more, right? It's like there's just so much value in SMB.

Okay. So this theme has come up a bunch already in our conversation. I asked Chris Miller, previous podcast guest, what you're amazing at and what I should talk to you about. And he said that you're very good at zigging when other people are zagging and zagging when other people are zigging. And I think that's already come across in our conversation. I guess, is there anything else along those lines that you think might be helpful to people in terms of how you think about that or examples of that in action?

So this comes down to the kind of, kind of high conviction, low consensus bets. And so we had like 3 things that we were zigging. And by the way, it's not just me, my co-founder and I both have that kind of zig versus zag. And we kind of ask ourselves, and we ask ourselves this to this day, right? It's like, okay, well, we understand like this is the way that kind of the world moves. This is the way it's normally done. But have we considered this completely? And I'm not saying we should do it, but have we considered this alternate kind of alternate path? So I would encourage you at any stage of the company, You don't necessarily have to do the zig versus zag, but you should at least know what the zig would've been and have talked it through. So that's kind of thing number one. Some of the best startup advice I've heard and I've ever given is startups should focus on one thing and be really, really exceptionally world-class, better than anyone else at that one thing. And one of our early zigs is we are going to do exactly the opposite of that. So from year one, HubSpot decided to build an SEO tool, web analytics, blogging tool, content management, all of it. And every one of those categories that we were building a product in, literally this is year one, had great products with great companies behind them. And so it's like, okay, well, why would you do that? And the reason is that the one thing we wanted to be good at was solving for the actual customer problem that existed. And the customer problem that existed was not a dearth of tools, lots of great SEO, blogging, everything, all the tools existed. But SMB specifically did not have the wherewithal to put all those pieces together, right? So you and I, it's like, oh, I can throw a website up, I can put Google Analytics on it, I can put a Wufoo form, Typeform form on it. I can do all these things. I can wire it all. No big deal. Like, why is this so hard? But for most people, most SMBs, that's a science project, right? And so we said, okay, in order for us to solve the actual customer problem, we have to solve the actual customer problem, even if it's uncomfortable, even though It's contrarian and every kind of instinct, every advice we've heard or given says we should not do this. We should not go that broad. But once you make that decision, so the other kind of lesson learned, it's like, and we said this in the early years and it's gotten better since. So let's say you do this and this is kind of the all-in-one approach. We're going to have this broad-based product. It's like, okay, we're going to be many miles wide and only so inches deep. One of the, and this goes back to our very systematic thinking, is like, okay, We're going to measure each of those individual product categories that we're now playing in. Are we in the top 3 in the market in that category? If the answer is yes, that means we invested too much in that category. We should not be in the top 3 because our value proposition is not that we are the top 3 blogging tools or one of the top 3 web analytics tools. We have the top 3, whatever. Our value proposition is that everything works so well together that, that being in the top 3 and having those right features or whatever, Doesn't matter. Doesn't matter as much as the all-in-one. And that means we over-index on one individual category by virtue of that was one of our kind of heuristics for being able to tell that we were over-indexed on one particular aspect of it.

That is hilarious. Rarely do I hear we're in the top 3 and we're doing the wrong thing. We are too good.

And by the way, and we've changed that over time, right? Like in the startup world. And now I would argue that most of the categories we play in, we are, as surveys would tell you, that we're in the top 3 in each of those categories now, right? But at the time when we were very, very resource constrained. Um, you know, we were trying to be disciplined and focused and like, yeah.

So we're just racking up all these very, uh, contrarian approaches to company building. I imagine people listening to this might feel like, okay, cool. I'm just going to build a bunch of stuff. This is great. It worked for HubSpot. Do you have any heuristics for when it makes sense to go wide and not deep that you share with founders? When do you think it makes sense versus now you should actually follow the common advice here?

Yeah. So it comes down to, um, What problem you're solving. So I think one of the mistakes I think founders make is that, especially product-oriented founders, is that we kind of fall in love with the solution instead of falling in love with the actual problem. And you need to fall in love with the problem and putting that constraint on yourself forces you to kind of understand and at least label and define what problem you're solving because oftentimes we can describe our product or whatever, but we struggle sometimes as founders to describe the actual problem. So if you can make the case, which HubSpot did, it's like, okay, we've, it's not like we immediately jumped to that, like, oh, we have this epiphany. We're going to build the all-in-one, do all the things kind of thing. We're like, oh, in actually talking to customers, because we've considered doing it like, oh, we'll just do this marketing piece. We'll just do this or whatever. It's like, no, that's not their issue. Their issue is like, it's not that these things don't exist. So If you have, as a result of talking to customers and understanding the problem deeply, you come to the conclusion that you need to do more than just one thing, but then you should force yourself to have the discipline that we did, which is here's why we're going to go a little bit broad and here's how we're going to make sure that broadness doesn't kill us, right? You have to have the kind of self-imposed constraint. You can't have the best of both worlds. You can't say, We're gonna be all in one and oh, by the way, we're gonna be the best. No, you can't be the best. You can say we'll be, we solve this particular problem the best, but we're not gonna have the best product along those, any of those dimensions.

Amazing. I love this advice. Imagine a place where you can find all your potential customers and get your message in front of them in a cost-efficient way. If you're a B2B business, that place exists and it's called LinkedIn. LinkedIn Ads allows you to build the right relationships, drive results, and reach your customers in a respectful environment. 2 of my portfolio companies, Webflow and Census, are LinkedIn success stories. Census had a 10x increase in pipeline with a LinkedIn startup team. For Webflow, after ramping up on LinkedIn in Q4, they had the highest marketing source revenue quarter to date. With LinkedIn Ads, you'll have direct access to and can build relationships with decision-makers decision-makers, including 950 million members, 180 million senior execs, and over 10 million C-level executives. You'll be able to drive results with targeting and measurement tools built specifically for B2B. In tech, LinkedIn generates a 2 to 5x higher return on ad spend than any other social media platforms. Audiences on LinkedIn have 2 times the buying power of the average web audience, and you'll work with a partner who respects the B2B world you operate in. Make B2B marketing everything it can be and get $100 credit on your next campaign. Just go to linkedin.com/podlenny to claim your credit. That's linkedin.com/podlenny. Terms and conditions apply. Okay, I'm gonna go in a totally different direction for now and see where this takes us. I wanna talk about flash tags.

Sure.

So this is something that you came up with that came from a problem of your founder People come to you for feedback, you give them some random thought, and they treat that as gospel, and they go do it and spending months fixing something that you're like, oh, it's just a thought. Talk about flash tags.

Yeah. So, and this is exactly the problem, right? It's not just, once again, most things exist at every level of abstraction. So anyone that manages people, anyone that leads has this exact same issue. It's the megaphone issue, right? Like someone will pass you in the hall when we had offices in halls. You know, they'll ask you like a question. And as it turns out, this is particularly true of founders. Like, I have an opinion on everything, like literally everything. So if you ask me a question, I will have, it won't be thought out, it won't be right, but I will have one, right? And so the challenge is people will kind of take that and over-index on what was an opinion. And because it's inefficient to qualify every time someone asks you something, every time you put an email out there, And say, oh, by the way, it's like, this is just my opinion. And you can put like, you know, IMHO or something like that every now and then. But then like people say, oh, that's just like politeness or something like that, right? Okay. So here's what flash tags are literally. And I live most of my life through email, but I do this in other media as well. It's like the hashtag that we all know, but it's a discrete set of them, an escalating set of what I call the kind of dying on the hill spectrum. Okay, so here's how it goes. The bottom hashtag is #FYI, and the definition of the FYI is, I came across this interesting blog post, or I found this news or whatever, just letting you know. No response expected. Fine, go on with your life. Next level up is #suggestion. I have this thought that came into my head because I listened to the episode on Lenny's podcast with Sam from Microsoft or whatever, and This feels like it could be a good thing to kind of explore. But hashtag suggestion means I still don't expect a response. You don't have to do the thing I'm asking, but it is something that I would do if I were you, or at least I would consider if I were you.

Okay.

Next level up is hashtag recommendation. Hashtag recommendation is I've thought about this a lot. I've done some research, I've done some digging, I've done some soul searching. I would do this. It's still not a, you have to do this, but if you decide not to do this, I would appreciate a response in terms of why you don't wanna do this, what you learned in the process of exploring this particular thing, other alternatives or something. So it's like a response expected, but still not a mandate. And the last one is hashtag plea. I beg of you, we don't have mandates at HubSpot. I have thought about this so much, like to my core in my soul, I believe this is the thing we should be doing. I'm going to plea with you to please just do this. Still not a mandate, by the way, but that's the— and so now it's commonly accepted. It's like, it's on the wiki. You're like, people know, it's like, and I use this multiple times every day. Other people at HubSpot use it. It is remarkably effective because they're self-descriptive. Hashtags are searchable, right? You can go back and it's like, oh, I want to know the last 5 hashtag recommendations that I made, how those turn out. Uh, like it's, there's just so much goodness that comes out of it and it's not hard to understand or describe.

It's really interesting that none of them are just, just do it. You say that there's no concept of, there's no mandates essentially. Why is that? And do you feel like people, do people just treat PLE as, okay, I actually just really have to do this?

So we've always had as part of kind of early manifestation of HubSpot culture, we kind of believe in autonomy. Lots of companies believe in autonomy and we try to carry that idea as far as we can. And for the most part we do that. And that's, and the hashtag plea is part of that, right? This is like, we trust our people, we try to hire the best, we expect them to learn and we still want them to, you know, have the kind of discretion to be able to make hard decisions. And we have, you know, we call them DRIs. We didn't invent that term, a directly responsible individual. And we'll talk more about, we should talk more about decisions and how decisions get made. But the reason I do hashtag plea is that it's a soft way of a mandate without being a mandate, right? It's like, okay, like, and by the way, like the number of times that happens is like, I can count on the fingers of like one hand and still have fingers left over, right? Like that almost never gets to that. Because either I talk myself out of it, it's like, okay, and this goes to the, is this a hill I'm willing to die on, right? It's like, okay, I get it. I may disagree. Is it the end of the world? Is it really going to do that much harm? And is the cost of kind of imposing that kind of founder card, go do this, does happen, just not that often. So yeah.

Awesome. And we'll link to the, there's a post you wrote about how to use these.

It's flash-tags.org if you want a quick way just to get to that blog post. I believe in domain names and shortcuts. Because I believe in simplicity still.

You mentioned decision-making. There's something interesting there. Talk about how you make decisions at HubSpot.

Like most organizations, HubSpot historically has made decisions poorly. It's just all a spectrum, right? I think decisions are one of the hardest things because it's hard to strike the balance. And we've evolved it over. I think we're much better than we were in our earlier years. The things we get wrong, most people get wrong. And so I'll tell you the things we get right now is that So we like to be, we're very data-oriented. We like to make data-informed decisions, but data doesn't make decisions, people do, right? So there's like, that's like thing number one. It's like, you know, you have lots of geeky founding companies or whatever. It's like, oh, like we have a chart that says this, so we should go do that. That doesn't work. This will work in our slides. Like data's awesome. And we also have one position that we designate to make the decision. And that is not necessarily the executive overrunning that team. It's like, okay, well, so-and-so, like, and we, and they literally own that. And we didn't invent this idea either. This existed long before HubSpot, but it actually works. It's like you have to decide who's going to make the decision. And that is the, like the, almost the number one decision to make. And it's like, okay, don't pick people you don't trust to make the decision. And so that's kind of thing number 2. And the biggest mistake, and we used to make this much more than we make now, And Amazon stated this really well. Theirs is called Disagree and Commit. We have a slight twist on it. I'll tell you why we twist it a little bit. Ours is Debate, Decide, Unite. That's our kind of phrase that we use in HubSpot culture. But the idea here, the core premise of it is that once you make a decision, getting alignment around that decision, because there will always be at any Any amount of scale, people that disagreed with that decision because they were debating the other side, right? Like they just didn't, like they went, they would've picked option A and we ended up picking option B. But it's extremely important that even when a decision gets made and we decide to do something that's contrary to the thing that you believe in, would've debated for and did debate for, you lost on that particular one. Fine. Hard to do, but so important and so valuable. And I'll tell you why we tweaked the Amazon one. So the disagree and commit sounds a little bit harsher than we like, right? Which is like, oh, it's fine for you to disagree, but then effing commit, right? It's like, okay, I get that. I'm biased. But so the debate is, okay, so let's have open debate. Let's get all the options on the table. Let's actually make the decision. And then it's unite around that decision, not just— it's like, okay, let's kind of come together around that. And that, Sounds more HubSpot-y. Um, so anyway, that's—

It is a lot more friendly. I was thinking that as you were talking, debate, decide, unite versus disagree and commit. And then there's like, have backbone, you know, in that one. It's, uh, yeah. So I like that one.

The other thing I'll tell you, and this is, uh, partly a HubSpot thing, but partly a me thing, and this will not surprise, uh, surprise you at all, is I, I like to think systematically, uh, around decisions.

Right.

And so I'll, I'll give you an example. Um, The question I ask myself when faced with a decision or a thing that I'm trying to do is like, okay, if I could write Python code, a Python function to come up with an answer to this, what would the variables or the coefficients— okay, let's say you're not— if you were making an Excel spreadsheet to make this decision, what would the columns be? All right. You don't have to decide the weights. But at least decide the factors. Then the next step is like, okay, here are the factors that I think matter in the making of this decision. I'm going to decide between these 7 options. Here are the things I'm going to look at, right? Like you would do this for picking a school to go to, or, you know, it's like it works, right? And you don't have to take it to the nth degree, but the exercise of going through it, it's like, okay, well, step 1, if I can just identify the factors that I think should impact this decision, that's an 80% win right there. Not because it's just in your head, If the team works collectively to say, okay, here are all the factors that I think should contribute to the making of this decision, then number 2 is, okay, we can't assign exact weights, so we can't write the Excel formula just yet or the Python code, but can we at least stack rank the factors? Like this factor's more important than that factor. Now you get a closer sense of approximation, right? You're still not gonna use a spreadsheet to make the decision, but the human making a decision Has much better information that they had than pre-going through that exercise. One of the mistakes people make around decisions, and Amazon has written about this, I'll give you kind of my take on it, is that the calories you spend on a decision should be proportional to the consequences of that decision. Fair and simple. And he calls them like one-way doors versus two-way doors, which is a kind of a binary heuristic, which is, I love the elegance and the simplicity of that. I'm taking it one level further, which is, It literally should be proportional. It's like, okay, if you have a really, really big decision that's going to be expensive to change, really, really spend a lot of calories making that decision. You might still get it wrong, but it's worth it, right? Like that's, and it's not just around decisions, around activities and bets and things that you're going to do is that the calories you spend should be kind of proportional to the kind of the outcomes and what you're seeking and the value of it. And that's one of the things I try to apply to my life is like, okay, like my geeky nature wants me to go, you know, 9 miles deep and start writing code and do this thing or whatever. But I found that that one simple thing is like, okay, is this like a first-order approximation where I can just identify the factors or it can like— and the other thing that helps, by the way, is, and we'll talk about this. So one of is my default position on most things, and I don't mean this in a negative way, is no. It's like, oh, shiny object. Should I go do this? No. And then I have to sort of force myself, okay, like I need like reasons to say yes. I have to kind of force myself because it's easy to say I love new things, I love new people. Like I love all of that. Is then, so I have a, I have like a sorry but no post on my blog that life-changing for me. And so the idea there is that this goes back to Well, other first principles is time is one of the few kind of constants, right? It's like the, so every time you say yes to something, by definition, you're saying no to something else. And so this goes back to the kind of product heuristic we were using in the early years of HubSpot. It's like, oh, when you put something in, you have to take something out because we want to kind of keep the complexity roughly constant if we can. Same thing. So it's okay to say yes to things, but then you have to force yourself based on the calories that you're committing to, to say, okay, well, What am I going to take out of my schedule, out of my life in order for me to be able to make room for this thing? Because as it turns out, time, I have not been able to, despite my best attempts, bend the laws of space and time. So how do I make room for this new thing that I want to say yes to? Yeah. So.

I love the way your mind works. I'm excited to talk about culture and how this connects in the way you think about culture and through all these frameworks and lenses. Before we do that, you've kind of hinted at this idea of how you pick what to work on. And I know you have kind of an interesting framework for how to decide what ideas are good and what ideas are worth investing in. I think both as a founder and a product leader, how do you think about deciding what is worth investing in?

So imagine the Excel spreadsheet again. So let's say you're evaluating an idea for a startup, for a new product, a new feature, whatever it happens to be. I think this, uh, this applies. Um, so the first thing, uh, you should look at is, and I measure things on a scale of 0 to 10 because I like quantifiable things. I like to be able to multiply X by Y. I don't like letter grades. It's a pet peeve of mine. But anyway, so put a number on it. It's like, okay, if this thing were successful, so let's say we're just picking a new startup idea. Like I'm considering starting this new business. If it were successful, what could it be? What's the kind of magnitude of the outcome? However you decide, it could be impact, it could be revenue, it could be market cap, it could be portfolio, whatever it is, it doesn't matter. I mean, it matters, but not relevant for this discussion. So that's the potential. Thing number 2 is Probability of success. Okay. And now I'm going to pause here and tell you the most common mistake people make is they think through the probability first without actually forcing themselves to think through the potential. And here's what happens is that they apply a filter that says, oh, I only have a like 1 in 10 chance to pull this off. There's only a 10% success rate or whatever. Not going to do that. Well, if it's a 1 in 10 chance at $10 billion, it might be worth it, right? Like it might be, maybe not. Like sometimes it's based on stage of life and things like that in terms of risk you can afford. But like for instance, and so by the way, and when I say probability, that's the geeky side of me. It's like you can do it multiple ways, right? You can say, oh, here's the X percent chance. You can do what in statistics is an event tree. That's like, oh, here's path A, there's a Y percent chance that happens, and here's what the outcome would be. Z percent chance or X. Anyway, here are the possible things and you come up with what's It's called the expected value. Anyway, so let's say we just look at 2 branches, like, oh, there's a 50-50 chance that I'm going to make $10 million. And she says, well, take one branch just to keep this shorter. So the expected value of that is $5 million, right? That's literally the expected value. It's like, oh, you got a 50-50 chance at a $10 million outcome. And let's say you have a 10% chance at a $100 million outcome. Or a 500, whatever it is. So mathematically it's like, okay, well you should at least consider that other one even though the chances are lower because the expected value is higher. Okay? So that's thing number one. Anyway, we'll get through the rest. So start with the kind of potential outcome, then look at probability, not the other way around, because then you're going to apply that mental filter and cast, throw out ideas that may not have been worth throwing out. The third thing is what I think of as either passion or proximity. Do you care about this actual thing that you can actually kind of bring to bear? And then the 4th one is, since I needed a P word, it's like prowess. Like, do you have some assets, something that makes you uniquely positioned? Either if you're building a new product, you have existing lines of code that you can reuse, you have a market that you already have access to. There's something about this particular idea that you have an unfair advantage pursuing, and that impacts your probability of success, right? And this is the other reason, it's like you need to kind of look at all those things. And once again, no one thing is the deciding factor. You're not going to just pick the thing that has the high expected value, take the potential times, whatever. It's like you have to sort of look at all of them and look at your own kind of situation. But it helps to kind of think through that, to kind of have the kind of discipline to say, oh, how big could it be? What are the chances? Uh, how much do I care about solving this problem? Is this something I can work on for 2 years, 10 years, 20 years? Um, and finally, like, why me? Like, why, why me? Why my company? Why would we succeed at this? Uh, why is our chance of success, even low, higher than the rest of the rest of the world?

Like, why? Okay. So I'm already picturing the spreadsheet here. For every idea you have, you basically have a column, potential, probability of success, proximity, you said, just like how—

Passion.

Um, okay. Passion. Yeah.

I started with passion and I have an issue with passion as a word because it's ambiguous because we talk within startup circles. It's like, oh, pursue your passion. Sure. But it's like, you know what? Most of the companies that exist today that are even successful ones with awesome founders, they didn't necessarily pursue their passion. It's like they kind of— Maybe you're passionate, like in, in our, you know, a particular problem or a market segment or something like that. But it's like, it's okay to become passionate about something as you kind of dig into it or whatever. That's fine too. So I thought that anyway, so.

Yeah, I have one of my favorite startups that I've invested in.

It's called Zip.

It's a procurement platform. Uh, the founders were not passionate about procurement when they got into the space. They just saw a huge opportunity. They thought they could build a much better product and they got passionate about it once they started working on it and finding—

And that's, this is the thing, right? So yes. Um, If you can find your true calling, this is what you were meant to do in the world and you have the opportunity to do it, great. That's a tiny small fraction of people, right? Like that's, it doesn't happen. And you may not even know what your passion, like, especially if you're a first-time founder, it's like, okay, well, I haven't seen the world. I don't know. It's like, so yeah.

Okay. So just for people, if they're creating a spreadsheet for all their ideas and for startups, it's potential probability of success. Passion, prowess.

Yes.

Okay. Amazing. Okay. Let's talk about culture. I know you spent a lot of your time on helping build HubSpot's culture, create the original culture. You created this epic culture code deck. I think it's 128 pages. So maybe just to dive into it, what was that process like to define the culture of a company and maintain the culture over time?

I'll say awful. No, the beginning of it. Okay. So I'll give you the very quick story because I, my co-founder and I were having one of our founders meetings or founders dinners as we do. And he had been meeting with his CEO group and he said, oh, Dharmesh, I hear this like culture thing is like really important. By the way, the word culture had never been mentioned prior to this conversation in the halls of HubSpot, like ever.

And this was how many, how many years in?

This is, I want to say, 3 or 4 years in. I can check the records because, by the way, even like Brian and I, even back when people worked out of offices, most of our communication was over email and async. We've always been big believers in that kind of written form. But anyway, so I can tell you whether the word cultural is used or not.

I love it.

So, and it was not. And so, and he's like, oh, like I've heard, because, you know, talking to Steve, culture is super important. Dharmesh, can you go do that? I'm like, okay, Brian, like all the people in all the companies, like I am like in the literally like the bottom decile, if not like the worst possible person. It's not that I don't like people, I just don't like being around them a whole lot. And from what little I know of culture, it sort of involves people, right? Like that, you know, I don't know, but it seems like I'd be the wrong person. But anyway, I was, I'm— I'm a team player. I'm like, okay, it does feel like it would be important. And so I took on the task. And I didn't really know because it was like, when he said like, Dharmesh, can you go do that? Like, what does that mean? And so what I took it to mean, it's like, okay, well, like culture actually already exists. We have a culture, right? It's like whatever it is. So, and it's working pretty well. Company's doing well. People seem happy. And so I Said, okay, well, what I'm really trying to do is kind of describe the culture that's there. So it's not creating culture, it's articulating the culture so we know what it is. And so then this is the geeky side of me showing up again. So the question I asked myself is, I literally asked myself this question, which is, if I could write a Python function that would measure the probability of success of a new person coming into HubSpot, what would the factors be? What are the things that if I could measure, if I knew, I had a truth function that says, oh, on a scale of 0 to 10, here's how they rank on this and this and this and this and this and this. I could approximate how successful and how good they're going to be for HubSpot. That's my exercise.

Okay.

So I did an internal survey and I'll tell you why this was such an awful experience in the beginning, because this is also a good story. So once I took on this task, I sent an email to the company. It's like, hey everyone, I'm just going to be like, digging into culture. So I was going to send this kind of survey out. I just want to get us an understanding so I can write. And the negativity and the visceral response to that one email was literally up until that point, it still ranks in the top 3, like worst things I've ever, like, people felt so negatively and so strongly and I was not expecting it, right? Like, and I'll tell you the one line that really like just was gut-wrenching was like, Dharmesh, here we're talking about culture. Next we're gonna have like posters up on the wall about excellence. HubSpot is not the company that I thought I joined. And like, oh, and I, it's just like the geek part of me is like, I just not, I did not know how overloaded that idea of culture was, right? And so then when you dig into it, it's like, oh, because So many companies had done it so poorly and just didn't, you know, walk the walk or whatever. This is why there was a reason why there was this kind of negative response. So anyway, so I went back to my thing. It's like, I get it. So I'm going to try to describe what we have and I'm going to write this truth function. So I wrote the slide deck, which had exactly 16 slides, and that answered this one question, which is, If I could write Python code, what are the factors? So what are the attributes that we would look for in humans that— and the reason I came up with that particular question is that I got this when I did the survey. I did the NPS survey, which everyone knows that you would send to customers. It's like, oh, on a scale of 0 to 10, how likely are you to recommend HubSpot as a place to work? And the other NPS question is like, why did you give that answer? As it turns out, here's the thing that I learned, which was troubling. Everyone was happy. And the reason they were happy is because of the other people at HubSpot. That was the number one reason, which is both good and bad. It's like, okay, well that's awesome, but that doesn't tell me anything, right? It's like, okay, well that's like a self-reinforcing kind of recursive loop. And so that's when it's like, okay, well what makes the people at HubSpot the people that are at HubSpot? Let's come up with the attributes that define what it means to be one of these people that makes other people happy. And so we came up with the original kind of set of things that were embodied in that slide deck. And I called that slide deck the Culture Code deck. And the reason I called it the Culture Code deck is not because it was a code of conduct or a moral code, or this is how companies should be run. It was because if I could write code to kind of define the culture of HubSpot, this is what the code would look like. And since that point, it's like the question I keep asking myself is if we could have an operating system that ran the company, it's the geeky geeky part of me. Not that you could do that, but what would that look like, right? And so, and the big kind of unlock, there are very few original ideas I've had that are any good. One of them is this thing that culture is a product, period. And that every company builds 2 products. One is the product they build for their customers and the other is a product they build for their team. That's what culture is. It's the product you build for your team. And let's say we stipulate that that just happens to be true. Just humor me for a minute. If you assume that's true, then a bunch of things kind of follow from that postulate, right? That hypothesis, which is, oh, well, just like we would never build a product without talking to customers, we would never build a culture without talking to the customers of the product, which are the people. Just so we do a repeat of that original NPS survey we've been doing every quarter now forever to figure out what the NPS of that product is, our culture product. The other thing is like, okay, well, there's no product person in the history of humankind that would've said, oh, I built this product, it's awesome, I'm done. No one would ever say that. And this is the number one mistake, I think, I'm biased. I think founders make is that they say, oh, we have an awesome culture and my job is to preserve the culture. That is not the job because the needs of your customers change, the needs of the employees change, right? The culture exists to help the great people do great things for the company. That's why the culture is there. And the things they need later as the company scales are different. And so just like you would never freeze the lines of code of a product, you would never freeze the lines of code of a culture. Culture should be iterated on just like you iterate on product. So that was like the— and there's so many other things that kind of fall. So just like in a product, you will get feedback from the customers like, oh, here are the bugs. And we actually call them bugs. It's like, oh, here are the bugs in the culture. And we, at the all-hands meeting, so we have this survey comes back once again to transparency notion. Every single survey response, it's anonymous in terms of who submitted it. We publish it, right? The quant score, the subjective thing, everything. And then we will categorize it and we will then at the next all-hands meeting, we call them all minds. Anyway, a little—

I love that, all minds.

All minds. And it's like, okay, so here are the things that we heard, just like we would do for a product meeting. It's like, oh, we just did the customers. Like, here's what we're hearing back. It's like, Here's the bugs that you've identified. Here's the ones we're gonna fix. And when we're gonna fix them, we're gonna commit, like, oh, we're gonna, like, you said this was broken. Okay, we're gonna, we're gonna do something about that. Here are the things that, like, yeah, I know you don't like it that way, but it works as designed, which we do in product all the time, right? Like, and you should have the right to do that. It's like, yep, some people are gonna disagree, and there may be any number of reasons why we think that needs to stay the way, and we're not saying necessarily forever, but as it stands, We are not prioritizing this. We are not fixing that thing that you think needs fixing for whatever reason. So the one lesson here is very few things I've learned that I think are universally applicable. That one I think is right. And just so much rightness and goodness falls out of that is if you think of the people as customers, and if you think of the culture as product, it takes away this kind of abstract nature of working on culture and then takes away this thing I heard this back in the early commentary from the HubSpot team. It's like, oh, well, culture is not something you really build because that seems fake. That seems inauthentic that you just go, it's like, oh, we're going to craft this culture. Like, no, it's— we craft in the same way. Like, I'm not saying we're going to impose it, like we're going to do this off in isolation, but we're going to work on it. And it's something you actually do manifest. And it's not just up to the founders. Wow.

What an amazing story. You're definitely getting laughs per minute from me. I think there's at least one laugh per minute so far in this podcast. That's amazing. And I think this point you just made about your job is not to preserve the culture as a leader. I think that's really profound because I think most people don't think that. They think their job is we need to maintain our culture as we grow. That's, it's all fading away. Our culture is changing. But your point is that's, that's good. And that's great.

Bringing it back to product, I think this is an important thing that we kind of let This is the kind of second order lesson learned after you start with the culture as product is that one of the challenges almost everyone will deal with is that you have these things. And so, by the way, just because culture as product does not mean there's not a sense of having what some might label as kind of core values, right? Because we have this in product as well. There are core values that the product believes in, like we believe in about our product that we're going to kind of hold constant through it, right? Like, oh, we're building for SMB, we want it to be easy to use. constraints that we put on ourselves that are intentional, that even though we iterate, we're not going to iterate away from these things that we just, just kind of that high conviction bet thing again. But not everything that's part of your product is a core value, right? So not everything that was part of your culture in the early years. So transparency is one that has endured over a long time, right? As part of our core value. And we preserved it even though it was troublesome through the IPO. And I shared that story. And there are things that we changed that were part of like, oh, we believe this meritocracy thing in a flat organization. But the manifestation of that was a bug with the lack of titles, right? And so we changed that. It's like, okay, well, there are things. And here's the other thing that, and this is a mixed metaphor problem because I haven't, and I won't come up with a good metaphor yet, but there'll be things that you have that are kind of core. And the way I describe it right now, I'm just going to put it out there. I'm kicking myself for not coming up with a better metaphor. Is like federal versus state law. All right. So there are federal laws, right, that we have here in the United States that says, okay, here are the things, and these are the inalienable rights of all citizens of the United States. And these are the things that are core. But then we have state things, right? It's like, oh, for this particular state on these particular aspects, they can kind of optimize for their particular states. Like, yes, we understand, like, this is the core value, but for our state, we're going to do this. So we have something similar at HubSpot. We have a core set of things that are kind of part of the culture. Part of the thing is like, okay, here's what we believe. And then there are things that the individual groups, so our head of engineering could come back. It's like, yeah, I know our overall, like the founder's leaning is X, but for my particular group, that doesn't really make sense. We're going to do this. So I'll give you an example. So one of the core things from the early years of HubSpot is like, we don't care about what hours you work, like from what time to what time. It's like, doesn't matter. Like literally does not matter. And we didn't track it. We don't care. But then over time it's like, well, we have a support organization and that organization, as it turns out, does matter to our customers, right? Like we need to, you know, have coverage and things like that. It's like, okay, well that sort of makes sense, right? It's like, but then you sort of have to kind of A, pick your battles, but then kind of fight back. For instance, transparency. There have been times where individual org leaders like, okay, Dharmesh, I know you believe in this transparency thing and Brian believes in this transparency thing. But it's inefficient for someone that is an SDR in the sales organization to have access to the high-order financials. It's a waste of time. It's a distraction. That was the argument. It's like, you may be right, but the binary decision, the fact that we value transparency so much, we're going to, yes, maybe it is a distraction. Fine. And the other one is like, oh, I don't want my team to have it because I just don't, You know, we were hiring so fast and it's like, and once again, that's a lot of trust to put into people or whatever. It's like, yeah, but then this is one of the other lessons is cultures over time become self-fulfilling prophecies. Is that so? In the early, I'll list the big lesson learned. So when I put the first version, the public-facing version of The Culture Code out there and I got feedback from the team and like, Dharmesh, like you say this in The Culture Code deck, And it's just not true. It was not true enough for us to kind of like state that as a thing. And so the thing that I did is in the deck, I have what I call these little liner notes. It's like stuff going on in my head. It's like, oh, this is not really true yet. So it's more of an aspiration. This is how we want it to be, but we're not walking the walk yet on this thing. So I didn't take it out because I want it to be an aspiration. And here's the thing that I might have not thought it through. cannot take credit for it. What happened over the fullness of time is that those things that were aspirations became increasingly true by virtue of being in the deck. Because as people join, it's like, oh, that's the thing we aspire to. So I'm going to pretend like that's actually the culture of HubSpot, which is exactly what we want. So it's okay to say things that are aspirational, just call them out. Don't present things that are not true, but don't back off of the things that you would like to be true.

Wow. There's so many lessons there. It reminds me at Airbnb, actually, I was there when they created the original, there's these 6 core values of Airbnb. One of them was simplify, turns out. And then, I don't know, some number of years later, the founders realized we're not actually good at this and values should reflect who you are, not who you aspire to be. And I like this middle ground you found of like, I'm going to put in here, but I'll note this isn't necessarily who we are. We didn't do that. That was, that would have been a smart move. So they picked, they removed that core value. They're like, we're not, we're not actually this. And it went from 6 to 4. There's another one they removed. So I was really impressed because they're like, okay, wait, because it comes up in meetings. They're like, let's simplify. No, we have, it's actually really complicated.

Yeah.

Yeah. Okay. So what I'm going to do, I have one more question about AI, uh, and to make this work timing-wise, I'm going to cut the lightning round. So I hope that's okay. Totally fine. Okay. I know AI is very topical.

By the way, that's, this is my diabolical plan to have to skip the lightning round because that's the thing I'm not good at. Like I just, I'm not good at it. Anyway, the thing I was dreading the most.

Playing 4D chess here. Um, you knew exactly the timing and you're like, I will take this long for all these answers. So it'll perfectly play out. Um, so I know you're spending a lot of time on AI. It's on many people's minds these days. You built this product called ChatSpot. Is it still called ChatSpot or did you, is that the product you changed the name for? That's still ChatSpot.

It's still ChatSpot.

Still ChatSpot. And I know that you've handed that off now to like a team actually that's working on this. It's not like just the Dharmesh project anymore. So I don't know exactly where to go with this, but just why is AI so top of mind and where, where do you think people should be spending time? Where do you think things are heading? What comes to mind around AI?

Yeah, it's obviously I'm not alone in my excitement, but I will say this. So I've been, so I'm about to hit the 30-year anniversary of my working in like commercial software, right? Like, so I've been at this for a long, long time and that's all I've ever known. That's all I've ever done. And the last time I was this both excited, I'll just say excited because it was when the web first came along in the mid to late '90s. And I'm like, oh, like this literally like changes everything, right? And it's like relevant to everything. It's like literally everything is going to be impacted by this thing called the internet. And I was in my early 20s, right? And I've been, you know, here for mobile. I've been here for social. I've seen lots of things that, you know, people got really excited about, but nothing to me has kind of hit the Richter scale to the degree that AI does. And the reason is Okay. So if you think about early computers, PCs, that kind of gave us compute at scale, which was awesome. The internet effectively gave us kind of distribution at scale. It allowed us to take information, products, whatever, and get them out at scale because everything was now connected where before it was not. What AI gives us now is cognition at scale, the ability to kind of literally amplify the human brain, right? Like that's never been done before. Look, not that we haven't been trying, but now we have demonstrable evidence and products that actually work. We've used ChatGPT and products like it. And so it's life-changing, right? And so for the product people out there, which is a lot of you, AI— so by the way, the internet unlocked a massive opportunity because especially for startups, right? It's like, oh, We can just reimagine the world with this new thing called the internet that was not possible a year ago and now is. What can we kind of now unlock? And lots of great companies were created. I think something similar will happen here. And there's a couple of things that I think that are just tactically that I think are possible vectors that kind of satisfy my spreadsheet of if I were going to choose ideas, and this applies across industries, is that— So as software companies and product builders, Most of us have always called our products like, oh, we build intuitive products, where it's like, and we say that, right? As it turns out, it's just not true because as a user of X product, whatever happens to be, it's like, okay, I've got this mental model of the thing I'm trying to accomplish. And then I have to translate that into a series of clicks and drags and touches and swipes in order to accomplish the thing that I want in the software product that I'm using. And what varies is the degree to which that translation needs to occur. But there is this impedance mismatch, right? There's a translation that has to happen from the what's in my head, like, I wanna remove this background in Photoshop, I wanna create this report in HubSpot. And so the opportunity now is that we're going from what was an imperative model. This is what engineers would call like a step-by-step. You give instructions to the computer, like, do this, do this, do this, do this. And then hopefully you get the outcome you're looking for to what engineers would call a declarative model. A declarative model is you describe the outcome you want, not the steps to get there. And the closest analogy that most people are familiar with is SQL, the querying language, right? So before SQL, if you wanted to get data out of a system, you wrote code that says, okay, loop over all my customer records and then filter out the ones that have less than $1 million in revenue and then give me the result. And SQL said, no, just put a WHERE clause on it, describe the data you want and what columns you want and how do you want to order it and what filters you want to apply. And it figures out, it, the database figures out how to get you the thing that you're looking for. Now we have the ability to do that for interfaces, for software, right? So instead of saying, click here, drag here, it's like, I want you to generate a report that's all my customers in Europe that we signed up last quarter that were more than $100K in ARR. And you just literally take the thing that's in your head and express it in whatever medium you choose, text, voice, doesn't matter. And the software now can actually, the, so now the technology exists to pull that off. Did not exist before. And now it exists. I know it didn't exist before because 6 and a half years ago, I built this product called GrowthBot.

Hmm.

That was a chatbot for HubSpot software and business software generally for marketing and salespeople. It's essentially what ChatSpot is now. Amazing product, GrowthBot. And it had just one teeny tiny small problem, which is it didn't work. Really well conceived, really brilliant idea. It just didn't work. And the technology just wasn't there, right? You just couldn't do it with any degree of fidelity because AI hadn't. And now you can. And that's what kind of caused me to go kind of prove out my theory. It's like I had a chip on my shoulder, particularly with that idea, right? But I think, and I'm not suggesting that, you know, web and mobile interfaces are going to go away, but there are a class of use cases across pretty much all software where we can make things easier for the human by not forcing that translation layer and just make it truly intuitive. Yeah. So thank you for coming to my TED Talk.

So what's great about watching you, because you kind of build in public with this AI stuff. That you're just, you're doing it. Like your approach to learning about this is building and doing. When you launched Chatbot or ChatSpot, uh, you tweeted that it took you many, many late nights of work. For people that want to understand what's going on, get ahead of where things are going, build the skills to be relevant in the future, do you have any advice? Is it just build stuff and do it, or is there anything else you'd recommend for people that want to understand what the hell is going on?

Yeah. So, and this is very simple practical advice, and this is the same thing for like engineers and software as well, is don't try to go learn something because you think it's like worth learning. Find an actual problem that you care about and go try to solve it with that new thing, right? Like you have something tangible that you're trying to do. So for instance, you know, going back to my Back to the talk around public speaking. It's like, okay, if I had said, oh, I want to learn about humor and standup comedy, I don't think I would've accomplished the thing, but I had a goal in mind, right? Which is like, hey, I need to be able to get up on a stage and hold up a thing and I have this measurable thing. So whatever it is, whatever line of business you're in, whatever you do as a professional, I guarantee you there are ways AI can help you even with the tools that we have out there right now. So either Use the tools, build tools on top of the APIs that exist, very easily accessible right now, very cheap to just kind of start. Yeah, just do it and iterate. And I'm a big believer also in kind of learning in public as well. That's why I do it. Like, that's why The Culture Code is out there. It's like, okay, well, if you accept the fact that culture is a product, we're gonna learn about things much better. Like instead of just getting feedback from the employees at HubSpot, why don't we put it out to the world? And because the internet is exceptionally good at telling you why you're an idiot, right? It's like, it's one of its core core strengths. Um, so I, I would recommend it's like, have a goal in mind, um, write about it. I'm a big believer in, uh, writing generally, but, uh, yeah, do it in public.

I love that advice. Is there anything else that you wanted to share or touch on or leave listeners with before we wrap up?

We cover a lot of territory.

Yeah, we did. Yeah, we did.

I might do the, uh, quit while I'm ahead thing. I'm gonna, I'll leave it with this.

Yeah.

So I have my definition of success that I came up with years ago that I kind of still stand by and that HubSpot actually stands by is success is making the people who believed in you look brilliant.

That's it.

What I like about that is it's not like an inward-facing thing. It's an, this is the kind of like customer folks, like, oh, all the employees that join your company when you're a founder that were kind of silly enough to, could I join you on this thing or whatever? It's like you respond to customers that believed in the early product that completely sucked. Uh, investors that believe, like all of that, like do what you can to like, when they reflect back on it, it's like, oh boy, was I smart to having, having believed in Lenny and, uh, and what he's doing.

So yeah, I think that's— That is really beautiful. Dharmesh, you are wonderful. Thank you so much for doing this.

This has been a lot of fun. I'm glad we were able to put it together.

Same. We covered so much ground. We got through everything that I was hoping to get through and more. Where can folks find you online if they want to follow what you're up to and maybe reach out if they have questions? And then how can listeners be useful to you?

Sure. So I'm, I'm Dharmesh, uh, D-H-A-R-M-E-S-H, everywhere. Um, I'm not only findable, I'm unavoidable, uh, on, on the internet as it turns out. Um, and follow me on social media and tell me where I'm being an idiot and what I can learn. Uh, and Tell me your favorite. Here's the thing. Leave a YouTube comment and tell me which Lenny episodes were your favorites so I can go back because I've been binge-watching anyway. I'd love to know.

And then speaking of that, I know you have websites of your content, you have your YouTube channel. Where can folks find those things?

Yeah, if you just go to dharmesh.com, that'll have links to the other places. I'm probably most often on LinkedIn, as it turns out, which is a whole topic for a whole other day. But yeah.

Awesome. All right. I'll let you go, Dharmesh. Thank you so much for being here. Thank you.

Bye, Lenny.

Bye, everyone. Thank you so much for listening. If you found this valuable, you can subscribe to the show on Apple Podcasts, Spotify, or your favorite podcast app. Also, please consider giving us a rating or leaving a review as that really helps other listeners find the podcast. You can find all past episodes or learn more about the show at lennyspodcast.com. See you in the next episode.