Lessons Learned from 9 Years at Heap with Advisor & Former CTO Dan Robinson

Yeah, let's get started. I'm Dan. I was CTO at Heap for the last 9 years. I'll be sharing some lessons learned while building that company today. And also you can think of these as advice I wish I could give the 2013 version of myself when we started building the company. If you haven't used Heap yet, it's a product analytics platform. It also recently became additionally a session replay platform. Come talk to me after if you wanna talk about it. It's not really what this talk's about. So here are some things I wish I knew in 2013 when we were building this. The first conversation I wish I could have with a younger version of myself, it's actually really simple, just about what your job as CTO is and more generally what your job is as a leader of a company. Specifically, your job is to make the company win. So you might imagine that in some fundamental sense, the CTO's job is technical or it involves a certain part of the technology or any kind of other way you might attach yourself to the role, but your actual job as a leader is to make the company win. And the reason that's an important distinction is that what the company needs from you in order to win changes constantly. Like in my case, every 12, maybe 18 months, uh, what the company needed me to be doing if we were going to be successful changed totally. So that means you need to get used to constantly adapting, letting go of the thing that you just feel like you kind of got your your head around and just kind of got good at, because you need to do a different thing now. You need to hire someone else to do that or hand it off to someone else on the team. You need to be doing something new. So you have to get used to letting go. That's often one of the hard parts of adapting as your job changes, but that change is going to be constant. I will say maybe the only piece that didn't change is that at some point your job becomes substantially about recruiting, and that never really goes away. So that was a real constant for 9 years. But other than that, every year or so, the job would change. And it's really on you as a leader to figure out what you need to be doing. Other people can give you input, but it's really for you to figure out what your job should be and what you need to do to make the company win. So I mentioned that one of the hard parts is letting go of something you just got good at. I will share it on a personal level. —some advice that I had that I've seen help a lot of people is to keep your identity, like your personal identity, small and flexible and agile. And the reason I say that is if you attach your identity to any specific aspect of your job, or you get, you know, self-esteem from, you know, writing code well, or writing a certain kind of code well, or being an expert in a certain thing, or any kind of particular aspect of your role, if you attach that to your self-esteem and your identity, it'll be really hard to let go of it. Because it will become personal. And, you know, you can't swing to the next monkey bar unless you let go of the last monkey bar. So that will make it hard. I'll also add that a good coach can help you with this. My coach helped me with it a lot. But if you can recognize this happening, you know, psychologically in yourself or in peers, it can help a lot to let go and then do the next thing that's what the company actually needs. So your job is to make the company win. Try to keep your identity small and adapt because it'll, what you need to do to make the company win will be changing constantly. Second, um, a second conversation I wish I could have with a younger version of myself is, um, about strategy and, uh, what strategy means and what good strategy looks like. Uh, strategy, uh, for a SaaS company, I argue, should look kind of obvious. Specifically, if you have a clear understanding of the business and the market and what customers are trying to do, The right strategy should seem kind of obvious and simple. And to be even a little more provocative about it, SaaS is checkers, not chess. You shouldn't be thinking of yourself as like a grandmaster of SaaS. You should be thinking of this as like a kind of simple game with kind of simple rules. And it's more a question of executing them well and understanding the game board. Or if you want to stretch the analogy a little bit, it's like a game of checkers where if you don't have good context about your company, you won't see the whole board and you might make mistakes. But once you see the board, it's a game of checkers. It's not a game of chess. So it should look kind of obvious. When I was younger, I thought strategy meant really rigorous thinking about first principles, fundamentals, and then figuring out what the second-order consequences of things were and gaming things out and wargaming. If we do X and a competitor does Y and then we do Z to counter and another company comes in and does W, what will that mean for the market? That stuff can be interesting to think through. It can occasionally be valuable. If one of those scenarios does come to pass, it'll be useful to have thought through it beforehand. But I would argue it's not a sound foundation for thinking through your strategy. You don't know what competitors are going to do. They're not going to operate exactly the way you think they are. And even if you don't get sunk by some, you know, detailed unknown unknown, and, you know, any nuance that you're missing about your business or what your customers are trying to do could make your reasoning wrong. Even if you don't get sunk by one of those things you're missing, you might still get the timing wrong. You can reason from first principles about what people should want to buy or should be trying to do, and you may just be early by 5 years and build something that no one wants yet, and you're still hosed. So don't think of this as a game of, as a complex reasoning process, chess-type thing. Try to keep it simple. This is particularly a trap I've observed for people like me who come from an engineering background. Engineering teaches you to find really clever solutions that get around a whole bunch of constraints at once. Cleverness is actually not your friend when it comes to strategy because cleverness will make your strategy brittle. You want it to be kind of simple and unclever. And if you— if I'm being even a little bit more honest, a lot of engineering culture is about showing people how smart and clever you are by your solution to a problem. And that's really not your friend if you let that mode of thinking get into how you do strategy. Because the goal isn't to appear smart, it's to have something that will work as a business. So, you know, be careful. Clever, Fear is actually kind of a smell. You can attach yourself to large tailwinds or important trends, but by and large, I would try to keep it simple, play a game of checkers, uh, uh, focus on the context part. So, um, I used to worry that we would make a strategic mistake because we didn't foresee some second-order consequence of the way our market was evolving or something like that. Never happened in 9 years of working at the company. Um, we did make mistakes because we got the context wrong, because there was some nuance about what customers were actually trying to do and we didn't understand it right. And then we built something that didn't quite solve their problem. It's really easy to make mistakes that way. So, I would focus on getting the context right. That's the hard part of strategy. Remember I said strategy should seem obvious given a clear understanding of the business and the market and what your customers are trying to do. That part's the hard part, is understanding that. So, for example, you know, if you're on a leadership team and you do some kind of exec offsite and you come back from the exec offsite with a big, exciting, grand new strategy about what you're going to do to solve all the problems in the company, you should be super suspicious that that strategy is right because you designed it in, in almost a context vacuum. Like, you have 8 to 10 people on your leadership team, the other 90% of your company wasn't in the room, none of your customers were in the room. You're like, you've designed it in a low-context environment. Like, the hard part isn't standing around a whiteboard and being smart. The hard part is having the context. So an alternative, I would argue, is a much better way to generate context or to generate strategy is via waves of intensive customer feedback where you're testing specific hypotheses that will flush out the gaps in your context or the gaps in your thinking. That's like a way to optimize around what is the actual hard part of the problem, which is the context. So focus on that. The strategy will be obvious once you do that, if you get that right. Another strategic idea I wish I understood 9 years ago is that software is fractal. And what I mean by that is When you look at software, you see features, and if you zoom in on a feature, you'll see sub-features. And if you zoom in on one of those sub-features, you see sub-sub-features, and it's kind of infinitely nuanced and rich all the way down. And the reason for that is that software mirrors or encodes human needs and business process needs, and those are just infinitely nuanced and complex, and the software grows in complexity to match the needs of what you're trying to do. So, this is important for a couple reasons. First of all, any feature that you launch that's successful will generate a whole pile of sub-features and additional investment that seem kind of obvious in retrospect, but you might not have foreseen upfront. For example, in 2015, we launched a feature that let customers get their Heap dataset in their data warehouse. It was great. Customers loved it. Killer feature. You can do a lot of useful stuff with that. And then immediately once we launched that, we found that we needed to support additional warehouses. I'll let people customize the sync schedule. Actually, maybe you only wanna sync some events and not others. Maybe you wanna sync some metadata that we didn't think of. Maybe you wanna customize which properties go through. Like it's 2022, we're still investing in that stuff because we keep finding new ways to better meet the needs. It's 7 years later. So, these things are essentially bottomless. So, you should expect, like if you're thinking of your roadmap as we're gonna do X and then we're gonna do Y, you're probably missing something because if X works, you'll probably wanna do more X. So, it might be better to think in terms of funding areas areas rather than, you know, accomplishing specific features because you discover this as you go. And then a second consequence is that you should expect competitor functionality to have more than might meet the eye. So if a competitor has an important feature and you want to replicate it, you might not recognize all of the sub-features and sub-sub-features because you haven't launched the first thing yet and you just don't have the resolution on it. So it's one thing if you're thinking a competitor does X, but most of the effort went into this piece of it and we have reason to believe that that piece of it is useless or no one cares about it. And we only need the simple part, that's one thing. But if you're just thinking, oh, this competitor has this thing, we could bang that out in a weekend, you probably could bang out a first version of it in a weekend, but you might be wrong about, you might be missing whole pieces of what the feature really does. So, your strategy should reflect the fact that features are fractal, software is fractal. And one more note on this is that for most SaaS companies, this is where the technical moat comes from. Your technical moat is not usually some unique, specific piece of technology. It's, for most SaaS, just an accumulation of ever more nuanced and rich and detailed handling of all— it's this accumulation of feature weight and third-level investments in these features. That's what your moat comes from. [Speaker:QUESTIONER] Focusing on the soup category. [Speaker:JASON M. LEMKIN] The third conversation I wish I could have with my younger self is about tasting the soup. The idea of soup tasting is that you can't fully understand something unless you engage with it in some kind of direct way or you engage with specific anecdotes in a direct way. For example, Let's say you wanna know if you are providing good support to your customers. There are metrics for this. You can look at, you know, NPS and CSAT and response time, and there are standard metrics for this. There are tools that measure those things. They are benchmarkable. That will give you some understanding of what is happening at scale. I would argue that is inherently incomplete. And if you really wanna know if you're providing good support, you should also look at some example support interactions, read some tickets, look at some email back and forth, make some kind of intuitive subjective assessment of what, you know, Is this good? Would I appreciate this as a customer? Were there ways to help them that we maybe missed here? Something like that. If you want to be really sneaky about it, you can, you know, make a fake email and like file a support. You can actually, you know, truly taste the soup and experience what someone experiences with your support team. But this turns out to be important, particularly because as you scale, you'll get a lot of advice about how, you know, the business is adapting and you need to scale yourself and figure out processes and systems that scale. And you can't run the company at $20 million ARR the way you did at $2 million ARR. And like that advice is generally correct. That's all true. But what it usually means is creating processes and systems and layers that create indirection and distance between you and the product, you and customers, you and the, you know, the object-level things in your business. So, if you don't figure out some kind of way to, you know, stay in touch with that stuff and continuously invest in deep, rich context, you won't have the right visceral understanding of what's going on. You won't recognize, like, you won't have good strategic thoughts if you don't make that kind of context investment. So that's the idea of tasting the soup. Another way to think about it is you can't understand what's going on in a sports game by looking at the scoreboard only. You have to actually, you know, watch the game and look at the details. So, you know, figure out ways to continue using the product, figure out ways to continue talking to users. Paul Graham has a great article or a great essay, if you haven't read it, I would definitely check it out, called "Do Things That Don't Scale." I would add you need to keep doing things that don't scale in addition to doing all the things that do scale. We got so into this that we made it a company value. It ended up being transformative. A particular instance that stuck out to me, actually my first project as an advisor for the company after I left the day-to-day in March was to run a product boot camp. And what that meant is the engineering lead, the product lead, the design lead, the CEO of the company, and the chief customer officer cleared their calendars for a full week. And we spent a whole week in focused ways using the product, like doing real customer workflows, trying to accomplish things customers try to accomplish in the product, getting our hands really dirty, actually using it. And by the end of the second day, we were slapping our foreheads and saying we should have done this thing a year ago because it's such a helpful way to enrich your understanding and build a more complete, visceral understanding of what the product is good at, what it's bad at, what the opportunities are to make it better, all that stuff. So, it doesn't mean you're making your exec team into your UX architects or designers or something like that. We have a fantastic team that, you know, comes to a lot of the same conclusions independently. They're the right people to solve these problems. But to the degree that you as a leader need to understand what's going on with your product and your business, this is an important way to enrich the context you have. A fourth conversation I wish I could have with a younger version of myself is about how energy is more important than time. And I'll actually tell you a short story. A couple of years ago, I had a coworker with whom I had probably more friction than anyone else I ever worked with. And it took us a really long time to work out a functional way of collaborating usefully with each other. We did eventually get there, but a couple months in, he told me something that really stuck with me, which was— and this was in the midst of us butting heads. He told me, Dan, "Jason, you're pretty much always right, and you're so difficult sometimes that it's not even worth it." "You're pretty much always right, and you're so difficult sometimes it's not even worth it." It really made me think, because what a weird thing to hear. And actually, to really make it hit home, he told me this right before I went on a vacation, so I had like 10 days to really stew on like, "What does that mean? You're pretty much always right, but..." I didn't like the "but." or and, whatever. So, you know, I thought about it and he was right. In his wisdom, he was totally, totally correct. And the reason he was right is most people end their day when they run out of energy, not when they run out of time. I don't know— I am not this person. I don't know anyone who, you know, productively gets stuff done right up until the moment where they then close the laptop and close their eyes and go to sleep. Nobody works that way. And if you do, tell me how— what coffee you're— like, no one— I don't know anyone who works that way. What you act— what most people actually do is work up until they hit some point where they realize they're not useful anymore. They feel like they've kind of got enough done today. They're out of energy. They're tired. They don't really want to do stuff anymore, and they'll pick it up again tomorrow. That's, that's like how you make a marathon out of building SaaS, or how you make it work as a marathon. So, uh, people run out of energy. They don't run out of time. That's important because, uh, most discourse is— or there's a lot of discourse about how to— about, you know, time efficiency and time But I would argue you should care, given that the real bottleneck is energy, you should care just as much, if not more, about not wasting people's energy. Because that's the thing that they run out of at the end of the day. So, you need to understand the energetic costs of things. For example, let's say there's some annoying chore that people on your team need to do. It might only take like 15 minutes a week, but if it's really, really annoying, it's actually more expensive than it's 15 minutes because it taxes people's energy. Or, you know, if there's a really combative person on the team, you know, the cost of that person isn't the time that goes, that your teammates spend arguing with them. It's the fact that they're exhausted after and they don't want to do— like, that person makes everyone around them, like, finish their day earlier. That's really where the cost of that comes from. And this is also important to think about because as a leader, unfortunately, you can be uniquely exhausting because, you know, for ways that, for all kinds of reasons that you might not realize. And in ways you might not realize, interacting with you for a lot of people will be automatically stressful, which means that, you know, and magnified. So, for example, you might be in some context where you don't understand why we think something is going to work and you're trying to understand why we think this thing will work. And if you're not careful, someone will perceive that as, you know, being grilled or like an interrogator, especially if it's in front of a broader audience. Like, you may have an enormous energetic cost impact on them that you don't realize. So, you need to be really, really careful about that. Even if you perceive yourself to be like innocuous or like a shy nerd, which is how I thought about myself, which is another good example of how you need to keep your identity flexible because these things change. The flip side is that as a leader, you can also be uniquely energizing if you can find ways to do it authentically. What I mean is if you can channel some kind of authentic excitement or enthusiasm about what we're doing, it can be really infectious and positive and you can create almost free energy that means more stuff getting done and stuff going faster. That means, for example, if you're in the midst of a slog, you can remind people why what we're doing is so cool or why something is so valuable and important to the business or something like that. Another great one is you can praise people publicly and it will have unique weight coming from you. And you can do that all the time. And if it's authentic, it'll mean a lot to them. And, you know, you'd be shocked that that means a lot to almost everyone, even people that you don't imagine that it would mean a lot to. So your job is not to be a cheerleader necessarily, and you shouldn't do these things inauthentically because, like, it'll come off. People are smart, they'll know. But, you know, just understand the ways that you create energy and can also kill energy or be exhausting, because that's the actual bottleneck in people getting stuff done. The fifth conversation I wish I could have with a younger version of myself is about experience. And I didn't really When we were building this business in the early days, I thought, okay, we want people who are smart and they get a lot done and they're reasonable and they're good to collaborate with, they're good collaborative partners, maybe they're empathetic. Those things seem fundamentally important. Certainly we don't want people who are missing one of those qualities. And I didn't really understand why experience was such a thing that people talk about or obsess over. I sort of had this idea that the more experience you have, the more knowledge you accrue. And that's sort of right, but there's actually specific things that experienced people can do that you can't, that are really hard to replicate if you don't have experience. And I wish I understood them. The first is experience building companies gives you pattern recognition. What I mean is, if you've seen stuff before, you will recognize it more quickly the next time you see it because it will remind you of previous things that you saw. And in a kind of fundamental sense, it's really hard to do that if you're inexperienced because you just don't have the data set. You can't map it to stuff that you haven't seen. So experience gives you the ability to recognize patterns. If you're inexperienced, you might want to complement yourself with mentors who can augment your pattern recognition or working with peers or something like that. But experience makes this easy in a way that is hard without experience. A particular form of pattern recognition that I think is really important is knowing what good looks like for some domain or some attribute of your company. And the reason is, if you don't have a good, historical data set of scenarios that you've seen in different companies, you can make relative assessments, but it's hard to make absolute assessments. For example, let's say your design team and your engineering team are not collaborating well. They're butting heads, something like that. You can recognize the problem. You can get your leaders in a room and the relevant stakeholders and hammer out a new process and a new way design and engineering are going to work together. You can roll that thing out. And if You can make an assessment about whether you've improved the situation. Like, if you're smart and you listen well and you're intellectually honest, you can assess, is this better, is this not better, is this a lot better? That's a relative assessment. But it's hard to know in an absolute scale if it could be way better because you just haven't seen what good looks like necessarily. So another way to think about it is you can, you can, you can know something's improved, but you don't know Did it go from C- to C+ or C- to B+ or C- to A? If you haven't seen A, then it's really hard to know if you're there yet. So, this is something that experienced people can do really effectively. And a consequence of this is you should look for leaders who have seen, seen good and ideally helped create good in the ways in which your company needs to be really good. So, you figure out what your company needs to do well. And then if you don't have anyone there who has seen doing that thing really well, you might be in trouble because How will you know if you're doing it? So pattern recognition is the first thing that, you know, experience— it's a superpower of experience. The second thing experienced people can do, or an advantage of experience, is that you accumulate playbooks. A playbook is sort of an implicit or explicit way to recognize and solve a problem. And kind of obviously, if you solve the problem before, you'll probably be a lot faster solving it the next time. So this is the reason this is so important. I would say this becomes really important in the growth stage. When you hit— when the company is really early on, you and your team can figure stuff out and, you know, use your wits to solve everything from first principles and experiment. But when you hit growth stage and the company is doubling year on year, you don't have time to figure out everything. Like, the problems are coming so fast and from so many different directions that It's hard to stay ahead of the curve of what the company needs if you don't, if you haven't, or people on your team haven't accumulated some kind of playbooks for how to solve them. Like, you don't have, you know, a quarter to recognize a problem, a quarter to try to solve it and fail, and then a third quarter to try to solve it again a new way and succeed. You need to be recognizing and resolving these things, you know, intra-quarter because the company is exploding and growing so quickly and you need to, like, this is where playbooks are so important. Obviously, you still need to think critically. Like, you can't just trot out the same slides as last time and assume every exact— like, you need to understand contextually what is relevant and, you know, think critically and work hard. Playbooks don't do the job for you, but they help in that you can do stuff faster. And then a third superpower of experience is that experience tends to make people credible. That means that if you hire an experienced leader, either as a manager or a an individual contributor, they should level up the caliber of talent that you're able to attract around them because they're more credible. They have a track record. People want to work— people should want to work with them. They should be able to credibly sell that what we're doing is important or that they will help grow people's careers or all that stuff. So, experience makes people credible. And in fact, I would go so far as to say if you hire a leader and you don't perceive a change in the caliber of talent in their organization, 6 months later, there's a problem. Like, you may have hired the wrong leader, or you should— that's a real red flag because it's so core to leading organizations well, and it's such an important part of what you get out of experience. So, it means you can attract better people. It also means the credibility has an internal aspect. It should make it easier to launch initiatives or create new processes or align on stuff if you are more credible because you have done it before. And the reason is that a lot processes kind of work, or the degree which they work depends on how much people believe that they will work and then buy into them. So it often means that a more credible person can make something work that a less credible person wouldn't be able to make work, even if they had the same ideas. So unfortunately, credibility is just part of the value of experience and is something that you don't just get from, you know, the fundamental of being intelligent and critical and empathetic and all that stuff. So pattern recognition, playbooks, credibility, those are the things that you get with experience. You know, you still need to be, or a person you hire still needs to be smart, low ego, they still need to be a soup taster, they still need to be empathetic, all those things. So I'm not saying, you know, make hires based on resume, like don't get fooled by a resume, but these are things that kind of uniquely come from experience. So this is most of what I wanted to share with you today, or advice for my younger self. Understand what your job is and understand that it will require constant adaptation. Get good at adapting to it. Strategy should be obvious. Stop trying to play chess. It's a game of checkers. Figure out ways to taste soup. Make a religion out of tasting the soup. Be suspicious of people who don't taste the soup. It should be an important part of how you operate. Understand that people's energy is more important than their time. It's the thing that actually runs out at the end of the day and then makes them stop working. Eventually runs out and makes them stop wanting to work at the company. And understand the value of experience and the special superpowers that come with it. And then I will throw in one more thing to share and maybe advice for past self. For God's sakes, please be nice to people. The people around you are trying really hard. They're doing their best to make the company successful just like you. If you're finding yourself frustrated with someone, if you can just dig deeper and find a little bit more empathy and grace, You probably won't regret it. I can say for myself, I never once in 9 years regretted assuming good intent on the part of someone else I was working with. So just try to be nice to people. They're trying their best just like you. You won't regret that.