Waseem Daher:
I like to ask three questions about a business that I'm evaluating, or an opportunity I'm evaluating, and this is principally geared towards like a business to business product, but I think the spirit of it applies generally. And those three questions are basically, "Is this a niche problem or a general purpose problem? In other words, how many people or how many businesses have the problem?" Question number two is, "Is this a nice to have or is it a need to have? Are people's hair really on fire about this?" And the third question is, "How much does it cost?"
Brett Berson:
Welcome to In Depth, a new show that surfaces tactical advice founders and startup leaders need to grow their teams, their companies, and themselves. I'm Brett Berson, a partner at First Round, and we're a venture capital firm that helps startups like Notion, Roblox, Uber, and Square, tackle company building firsts. Through over 400 interviews on the review, we've shared standout company building advice, the kind that comes from those willing to skip the talking points and go deeper into not just what to do, but how to do it. With our new podcast, In Depth, you can listen into these deeper conversations every single week. Learn more and subscribe today at firstround.com.
Today's episode of In Depth, I'm really excited to be joined by Waseem Daher. Waseem is the co-founder and CEO of Pilot, a company that specializes in bookkeeping, tax prep, and CFO services for high growth startups. Prior to Pilot, Waseem co-founded Ksplice, which was acquired by Oracle in 2011, and Zulip, which was acquired by Dropbox in 2014. He studied computer science at MIT, where he met his two future co-founders, Jessica McKellar and Jeff Arnold. What's particularly unique about this founding trio is they've managed to stick together, not just through the turbulence of one startup, but three.
In today's conversation, we pay particular attention to the earliest days of Pilot. Waseem takes us behind the scenes of the ideation for what would eventually become Pilot, and how the founding team gained conviction to actually start building. This includes unpacking his framework for what he calls the calculus of the head and the heart. He explains why Pilot landed on its human plus machine model with a software component in addition to employing full-time accountants and tax preparers to partner with customers. Next, we talk about building out Pilot's ICP, and how he started getting the product into the hands of paying customers.
He's got some great tips for framing conversations with potential customers to make sure you're building a must-have product, not a nice-to-have. Finally, he shares how he prioritizes which offerings to add to Pilot's product suite. Today's conversation is an absolute must-listen for founders and those who have goals to start a company someday. Product folks also won't want to miss learning from Waseem's playbook, honed over the course of building three companies. Waseem is a very problem-oriented founder with a knack for simplifying really profound frameworks and ideas. I hope you enjoy this episode, and now to my conversation with Waseem.
Thank you for joining us.
Waseem Daher:
Of course, thanks for having me.
Brett Berson:
The place I think we wanted to start was to go back to the origin story of Pilot, and I think the first three to six months before a company even gets started, and the three to six months after a company gets started, is one of the most under-explored or misunderstood parts of company creation. And it's generally glossed over, somebody came up with an idea, they had some problem at their office, and they left and they started a company. But there's not a lot of fidelity in what that process is like and all the different little directions that you could potentially go. And so, I thought maybe as a jumping off point, you could tell us the origin story of Pilot, maybe negative six months through six months, and how the different paths you went down and how you landed on the thing you were going to build and the way that you were going to build. Maybe we could use that to get started.
Waseem Daher:
Yeah, absolutely. So, very interestingly, and I'll give you the long version and you can tell me where you want to go deeper and where you don't, the story of Pilot is really quite intertwined with the story of me and my co-founders, Jeff and Jessica. And to really understand that story, you have to go back, not six months before the founding of the company, you have to go back something like, I don't know, like 10, 15 years before the founding of the company, which is that Jeff, Jessica, and I, all met in MIT, we were all studying computer science together, undergrad, and we were all in the computer club together. And so, I knew them socially, and we had taken classes together long before we started working together.
But right out of school, we started a company together called Ksplice that did software updates without rebooting. I'm sure you've seen a pop-up that's like, "You must reboot to install new updates." And we all lived and worked in this crappy row house in Cambridge in Central Square, and the whole thing was extremely scrappy, we bootstrapped it, grew it to six figures in revenue, seven figures in revenue, Oracle acquired it, and we were at Oracle for a year and a day to transition of the tech, and then hit eject.
And after that first company, literally the day after we left Oracle, we all got together again and said, "We want to do another company." And so, we met up on various people's apartments for the next two weeks, and then ultimately landed on building a group chat tool for business. It was this company called Zulip, it was basically a Slack-like product at a time when Slack was still making a mobile game. And I think we really nailed the market opportunity there based on pay we had ourselves. I would not give us the A-plus on execution though, in the sense that we saw what Slack could be, I think that was the potential for the thing we were targeting, also that ends when though Dropbox acquired it. We were at Dropbox for about two years, running product and engineering, and then left.
And now to answer your very specific question, if we're talking about the six months prior to Pilot. After leaving Dropbox, the thing I felt very strongly about was actually taking some time off to recharge. And so, for the six months prior to Pilot, I said, "You know what? I'm not going to work and I'm not even going to think about what the startup is going to be. I'm actively, actively not going to be searching for startup ideas." And so, I took a big chunk of time to really just recharge and, I don't know, attend to all the things I had neglected while doing the previous companies or working at the acquirers of the previous companies.
So, very, very specifically, the six months prior to the beginning of this company were six months in which, not literally that I did nothing, but where I did nothing that was intended to ultimately yield a startup idea. The time was spent basically visiting friends and family, going to the gym, sleeping eight hours a night, spending time with my wife. It was just like, it was really just about kind of investing in myself. Fast forward a little bit, after the end of that period, the thing that was interesting for us is that, again, we knew we wanted to get the men back together.
And so, unlike, I think, other entrepreneurs, or unlike some other entrepreneurs, I already knew what the founding team was going to be. And so, the founders got together and we said, "Fine, what is it that we want to do?" And I actually found this to be one of the most painful and unpleasant parts of starting a startup, and here's what I mean, which is, in trying to figure out what to work on, there's a lot of time spent thinking, and it's hard to go somewhere and just sit in a room and think for eight hours a day. It turns out that that's very difficult and it's also very demoralizing because any concept that you come up with, there are a million reasons why it won't work. And those million reasons are very obvious to you.
The conviction and belief that it will work, in general, it's unlikely to work. You're generating these ideas, and your brain is like, "Well, no, that idea sucks. There's no way this thing is going to work because of X, Y, Z." There's no real way to make it go faster. Like, you think about, "Oh, what are some spaces I'm excited about?" And maybe do a little research, but I found it very stressful and very demoralizing because there was not... the goal was unclear. The goal obviously was like, "Figure out what company we want to start," but there was no real incremental steps along that path, or at least none that I was aware of.
But in the first several weeks of the company, we were getting together with my co-founders and saying, "Okay, what spaces do we think are interesting? What are problems we have that we think other people might have?" And going from there. One step deeper than that, actually I found much more engaging, which is, when you have the outline of something that you think might be an idea, then the thing we did is aggressively line up potential customer conversations. We'd say, "Okay, if we are thinking about building a tool for mid-market HR teams, let's say, well, then let's go and find a bunch of people who run HR admin market companies, and let's go and talk to them and let's say, 'Hey, tell us about what your top three priorities are, where your hair's most on fire, where you're spending your time. There's a lot of pain that you wish someone could solve for you.'"
And that I found actually much more energizing and much more productive because it was very focused, and you were getting this kind of feedback from the real world, as opposed to trying to do the thought exercise in your own head with no real external input. And so, having thought about this for a while with our team, we produced a short list of, "Oh, here are some spaces that we feel like we're excited about, let's go talk to lots of people in each of those spaces to understand, not, 'Do you like my idea?' To instead ask, 'What are your actual problems? What are your top three hair on fire problems?' And let's see if there are any commonalities there, let's see if there are any themes that emerge, and let's see if we feel like we're a team that is well suited to build or tackle one of those top three priorities for these folks."
And so, that process allowed us to continue to winnow down the set of possibilities to tackle, until we got to a pretty short list. And then from there, the reality is, at some point, you just have to make the call. Maybe we could have built mid-market HR software and built a very successful business doing that.
I mean, my suspicion is actually probably we could've, but you can't run three startups in parallel, you have to say, "Well, this is the bet we're going to make, and we're going to be thoughtful about it. If it seems like it's working great, we'll continue to invest, and if it seems like it's not working, well, of course, we can revisit, but we have to plant the flag and say, 'This is the direction we're going in, let's really put all of our fire power, all of our bandwidth behind it and see what it yields.'"
Brett Berson:
I find it interesting that you managed to find a founding team that not only really works exceptionally well together, but over multiple companies, worked well together, and worked so well together that it was the constraining factor. That it started with, "These are the people that I want to work with, and then let's go find an idea," which I think, on average, is fraught with all sorts of issues, because it's, for example, it's hard enough to find an idea, so, now you need to find a exceptional idea and exceptional solution that all three founders want to work with. It creates even more complexity.
And so, I guess I'm interested, what is it about the founding team, the makeup of the team, the way that you behave, that you think works and has this level of longevity, and worked so well that you would, in many ways, create another hurdle for yourself in building a successful, or landing, I should say, on a successful idea?
Waseem Daher:
It's interesting because the question in some ways is like, what is the limiting reagent or what is the scarce resource that causes your business not to succeed? Or maybe said another way, what are the likely causes of death for your company in the early days? And I think one of the most likely ones is usually founder drama, founder tension, an inability for the founding team to work together. And so, actually being able to solve for that from the get-go, I think, is very valuable in increasing the probability or the likelihood of success of the company.
The other aspect for me is that, and I tried to be very principled about this for the third company in a way that I really was not in the previous companies, is I really sat down and said, "Look, what actually makes me happy? What are the things I enjoy about doing a company? And how do I make sure that the next company that we do has those attributes?" And far and away, the number one thing for me was actually working with smart, talented people who challenged me to do my best work every day. And that for me, the satisfaction I derive from the company is largely actually about the satisfaction of working with the team that we work with. And so, being able to check that box or make sure that I was going to have that it's scratched by working with a team that I knew I knew and like and trusted, where there was strong shared context, strong mutual trust, was really, really important and really valuable.
And the related idea, again, here is, people think that the startup is actually, is very much about the idea, but the idea, in some ways, is the most disposable or flexible part of the company. You may conclude after your first six months of working on the idea that the idea's wrong, and that people actually don't want this thing. And that maybe there's something adjacent that they do want, or maybe there isn't. But what you're left with, if you have to make that choice is, you're left with the team. So, I would contend actually that the team is much, much more important than the idea. And that in particular, if you had to fix one, if you had to constrain one, I would rather pick the team and then tackle the idea, because I would basically work on anything with my co-founders and with the team that we've assembled.
I happen to be excited about the thing we're working on, but I think there are probably 10 other companies that we could do together and I would be equally happy about it. And you see that in our track record, this is the third company we've done, these companies have all been very, very different actually.
Brett Berson:
So, if you reverse engineer why the team works so well together, what do you think the answer is there? Or the inverse of that would be a co-founding team blows apart after two years and they point out the reasons why. I think it's not well understood or well discussed when co-founding teams have an incredibly successful dynamic, the why behind it, and I wondered if sort of anything comes to mind for you.
Waseem Daher:
Well, first, and just to be very transparent, I like and get along with Jeff and Jessica very well. It's not always smiles and roses and unicorns or whatever, there's always tension, there is, but it's, I think, it's like a healthy, constructive tension. And I think in any longterm relationship, whether it's your close personal friends, or your spouse, or whatever, it's not like you can never fight, we certainly do, but I think the thing that, the through line that exists here, I think the undercurrents that have allowed it to work are, strong mutual trust and, yeah, strong mutual trust and respect.
And what I mean by that is, Jeff, Jessica, and I, each have big non-overlapping areas of ownership, and we trust one another to execute well in those areas of ownership. So, there's very little toe stepping, there's very little getting up in each other's businesses is, I think, piece one. And that's possible because we have had a track record of working well together and that I know, that if Jeff or Jessica says, "I'm going to do X, Y, Z," I know that they'll do it, and vice versa. There's that shared trust. The second is what I think about it as having like an extremely detailed mental simulator of the other people.
And I could tell you, I think with 95% confidence what Jeff or Jessica would do or think in any given situation and vice versa. And the power of that is actually that I know and they know when something is going to be controversial, and when the three of us should actually discuss it, as opposed to, "Oh, this is a thing that is fine if I just go do." And again, though, what is the value of that? The value of that, again, is really about that kind of shared trust, shared respect. If there's a thing that is actually important, the three of us should talk about it or the three of us will talk about it. I don't think that like you're off building your own fiefdom or you're going to go do something sneaky that is in your interest and not my interest.
So, I think that's the other piece that makes it work. And then the third is just a much more tactical piece, and this one is less about the co-founder relationship but it's a product of the co-founder relationship and the fact that we've done this a bunch of times before, is that we can focus more of our mental energy on making the company successful, as opposed to spending that time debugging the founder relationship.
Brett Berson:
So, switching back to the process of landing on the idea for Pilot, I was interested in maybe having you talk about what you heard from customers, and you talked a little bit about how you approach those conversations, which you could expand on maybe slightly, but what you heard in that discovery phase that gave you conviction that this is what you wanted to go work on. And how your point of view on a potential solution fit into landing on, "This is the company we want to build." Meaning, as a few minutes ago, you were talking about exploration and following some different threads, you were very problem-oriented, but you didn't talk about the potential way you thought about solving a specific problem.
So, what was the internal informal or formal algorithm that got you to land on this specific problem versus another, you heard X from someone or Y from customers, where you could have built an entirely different company?
Waseem Daher:
There's like a framework of the heart and a framework of the head on this, and let's talk a little bit more about, I think, the rational pieces of it, which are, I think, classically what some investors say is, the only problem you can't fix is the problem on market size. And I think what's interesting is actually most folks' intuition about how big a market is or how big a problem is is quite off, including ourselves in our very first company. The way we landed on the problem for the first company is, we were like, "Well, we have this tech, it happens to help a problem we have, let's go do it." Surely, we'll figure it out.
We were not particularly thoughtful about, "How big could this be if it's phenomenally successful? Or, "How many people have this problem? How much pain is there?" Et cetera. And so, for me, I like to ask three questions about a business that I'm evaluating, or an opportunity I'm evaluating, and this is principally geared towards like a business to business product, but I think the spirit of it applies generally, and those three questions are basically, "Is this a niche problem or a general purpose problem? In other words, how many people or how many businesses have the problem?" Question number two is, "Is this a nice to have or is it a need to have? Are people's hair really on fire about this?" And the third question is, "How much does it cost?"
And the reason that how much did it cost matters is it implies actually a lot about the business. It indicates how much pain there is, because if there's a lot of pain, there should be willingness to pay, but it actually also specifies a lot about how the business is going to operate. Is it going to have to be this freemium self-serve online only, spreads virally, product-led growth motion? Is it something that's going to be very marketing driven? Is it going to be a really classic B2B enterprise sale? And having a good sense of, well, as a neutral general purpose, is it a nice to have or a need to have? And how expensive it is, you basically multiply those numbers, and then you're like, "Oh, okay, this is approximately how big the opportunity is."
And so, one of the things we were definitely orienting around is, we want to tackle a problem where the opportunity size and the total addressable market was really, really large. And the reason we want to do that is because, look, if you're going to go to the work of building a company, why would you not build a company that has the potential to have huge impact? That was sort of the calculus of the head. And I think the calculus of the heart, one of the things that as you go around talking to people about, "Is this pain that you have? Tell me about what your top three problems are," one shortcut for doing that is, "Well, what are problems that you've had?"
You can ask yourself those questions. And you're allowed to ask yourself those questions if there are lots of people like you. And if you're a total weirdo and your needs are totally different than everyone else, that's actually probably not a very good strategy in the sense that it's not going to be generalizable into something that ultimately serves a larger market. But one of the things we liked about the problem specifically that we landed on was, we had a deep and personal connection to it. It was a problem that we had in our previous ventures. It was a problem that, for me personally, my relatives who were all small business owners in Ohio also had very personally and that I saw firsthand.
And I like when there's a strong founder problem fit, or a strong founder problem fit narrative. I don't think it is required, I think you can definitely build a large successful business without that. In other words, I think we probably would have built a very successful enterprise HR business or whatever it happens to be, even though maybe there's not an obvious narrative for why we were the right team to build the enterprise HR thing. For Pilot, there was an extremely strong narrative about why this was the right team for the problem, and I think that was a nice icing on the cake.
I think the other thing, just to say it directly too, is, I think sometimes the narrative is actually not that obvious, and might become more clear in retrospect. Like, thinking about it more on this has been market HR thing, probably the narrative would have been, it's a little bit counterfactual, a little bit revisionist, would have been like, when we were at these big companies, when we were at Oracle, when we were at Dropbox, we saw that the people ops problem was X, Y, Z, and it was very painful for us, and therefore, we were motivated to go fix it. It was not so far out of left field that we were the wrong team to work on it, it was adjacent.
I think for the place we landed, one of the things that took it from good to great was that there was this very visual personal connection for it.
Brett Berson:
You're touching on this as you've been explaining the backstory, but could you put a finer point on your thesis as to why this company is already much larger but has the chance to really be absolutely massive transcended company, where your first two attempts were not that?
Waseem Daher:
One of the things that's interesting about the second company is actually that the thesis was a thesis capable of being a large, iconic, enduring public company in the sense that Slack basically had the same thesis that's what we've had. Now, they executed better on it and they executed differently on it, and those differences happened to yield a much, much better result. But I think we picked the right target in our previous venture in that I think it had the chance to be a giant, iconic, enduring public company had we operated it differently.
But what is the story or what is the narrative for why the opportunity is so great at Pilot? Well, first of all, what is Pilot? And what is the thesis of Pilot? Pilot is your external finance team. We take care of your bookkeeping, your tax prep, your budgeting, your forecasting, CFO services, et cetera, and the way we do it is that you're paired with your dedicated account manager, who's a full-time employee in our U.S.-based offices in San Francisco and Nashville, it's a really white-glove experience where we're going to help out and take care of all this stuff for you.
And under the hood, the way we do it, is we have an engineering team, and the engineering team has built what you should think of as the Iron Man's suit for our account managers. So, the Pilot thesis is really people doing what people do best, and software doing what software does best. Working together would yield a result that is higher quality, more reliable, more consistent, more accurate than what you could get if someone just did it entirely by hand. And the reason that we have such conviction that this has the opportunity to be an iconic and enduring business is if you go back to my framework of the three questions that I asked for every company I evaluate, well, is this a niche thing or is it a general purpose thing?
Well, literally, every business in the world has to deal with its accounting. And is it a nice to have or a need to have? Well, it's basically legally required. That's about as need to have as you can get. This is not quite true, but it's almost like, if you don't buy Pilot, you'll go to jail. That's pretty need to have. And then the third question is, well, how expensive is it? Well, interestingly, we're not selling you accounting software, we are selling you, we will take care of this stuff for you. And the consequence of that enter into ownership is, the alternative to hiring Pilot is hiring the local provider whose office is downtown, and maybe you show up with a shoe box of receipts.
And the landscape or the nature of that provider is that they're fairly expensive. It's skilled human labor and someone who studied and has a lot of expertise, and they'll charge you some number of hundreds of dollars per hour, and they'll work on your stuff for several hours a month. And the consequence of that is actually, it's not a cheap transaction, it's fairly expensive. And so, the consequence of all those three things is, again, you do that multiplication, and what you get out of the other aside is that the market size isn't really enormous. And this is also validated by the kind of top-down math on this, where something like $60 billion a year are spent every year in the U.S. on SMB bookkeeping and accounting. That's SMB only, U.S. only, 60 billion.
So, you could build a large, iconic, enduring public company doing nothing but this bookkeeping, accounting work. Now, I think the thing that's really interesting about Pilot is that the ultimate opportunity is not we do your accounting, and in fact, if you talk to our customers, they don't want to buy accounting from us, though in some ways obviously, they do want to buy accounting from us, and that's what they buy from us, what they would really love to buy from us if we could sell it to them is, "Pilot runs my back office, so I can focus on running my company."
Because if you look at any business owner, whether it's the tech startup founder, or the coffee shop, or the doctor's office, or the florist, or whatever it happens to be, you started your company because there was something you wanted to do in the world. And one of the things that you pretty rapidly discover when you're actually running this company is, "Hmm, there's a lot of back office stuff I need to do." And it's important, but it's tedious, it's not your area of expertise. You don't particularly want it to be your area of expertise, you want to focus on the reason you started the company in the first place.
And so, the longer term, the 20-year vision for Pilot is, well, if we could do all of that stuff for you, and you could focus on running your business, we could do it more accurately and more efficiently, more scalably, more painlessly, and you have a greater chance of making your business successful because you can focus on those unique areas of high leverage for you. And now if you apply that same framework, well, what is the opportunity size if you're really running the back office, if you're doing accounting and legal, and lending, and insurance, and HR, and IT, et cetera, et cetera, et cetera, for every business out there?
Well, very, very clearly, that's not the multi-billion dollar business, that's the trillion dollar business. And I think the business has sort of Amazon-like attributes in a way, in two ways. One is like, Amazon, okay, first, they were selling books, then they sold CDs, then they sold books and CDs and MP3s, and now you can buy literally anything you want on Amazon. Amazon can provide for almost every aspect of the consumer's life. I think a related Amazon services is if you look at something like Amazon Web Services. The insight of AWS was, "Look, your engineers could be spending their time running your data infrastructure, or you can host it in the cloud and have Amazon run your infrastructure so that your engineers can focus on actually building the application."
And I think similarly, the picture of Pilot is, could you hire someone to stitch together a bunch of your back office stuff? Yeah, you could, or you could hire us to do it. And the advantage of hiring us to do it is that we can do it more scalably, more reliably, more consistently, more accurately, with capabilities that are simply not possible if you were to just do this yourself. And so, if you look at the vision even more expansively, really the opportunity here is the opportunity that is in the trillions of dollars, not billions of dollars. And the question for Pilot is not, is the market large enough? The question is really, well, can we actually deliver a product that is good that our customers love it, that they refer it to their friends and fellow business owners? And can we continue to grow at the rates we'd like to grow to actually bring that vision to the world?
Brett Berson:
Did you have this clarity of thought when you landed on, "We're going to go build this company"? Or has this opened up in front of you in the past few years of building?
Waseem Daher:
The honest answer is I don't know. Here's what I would say, I should go back and check my notes. Definitely, one of the critical insights when we were first starting the company, it was this idea of we're not going to sell you accounting software, that we're going to be people doing what people do about solving what's offered as best, that we're going to own the problem end to end. And that there is real power in owning the problem end to end. So, that, I'm positive, was there on day one. I think the notion that there was more than just the accounting, yes, I think had occurred to us in the sense that, at the very beginning of the company, all we did was bookkeeping. We didn't even do tax preparation.
And one of the things our early customers told us was, "Hey, it's great that you do bookkeeping, can you also do my taxes? Because I have this problem, and it's a huge pain, I would love for someone to take this off my plate for me." So, I think we knew certainly the vision of like, let's run your financial back office, was clear to us, I think, from the outset. Was the fact that there would be such strong customer pull into everything else obvious to us on day one? Probably not, but I think it became clear pretty quickly in the sense that our customers were really beating down our doors asking for it. And we still get this all the time, where I remember in the very early days, a customer called us up and they said, "Hey, look, one of my employees is about to have a kid, what should my parental leave policy be?"
And that really struck me because these customers are also buying Expensify or some other piece of software that's designed for the back office, but I'm sure that no one is calling up those companies and asking, "What should my parental leave policy be?" But the reason they're asking us is because we have this unique and powerful high trust human relationship with them, which is that, again, when you work with Pilot, you're paired with that dedicated account manager who knows you, who knows your industry, you know their name, you correspond with them, and the consequence of that is extremely powerful. And I think that was known to us quite early on.
Brett Berson:
This might be a great place to spend a little bit more time on how you landed on man, woman plus machine versus accounting software, and the area that I'm really excited to get your thoughts on is what you did to make this work. Because it's been very in vogue for call it the past five to seven years to do something that's "more full stack," where you're buying the service, if you will, as opposed to a piece of software. And the amount of companies who have gone down this path and raised a tremendous of money, and then not worked, is extraordinary. And as I've spent a lot of time at a high level studying this, I think a lot of it comes down to one of two parts.
One is that the original pitch is, it's going to be human plus machine, and over time, it's going to be a heck of a lot more machine and very little human. And fast forward, four years, that doesn't pan out. It's actually harder to create the software infrastructure to provide a lot more leverage. The second is that, as you start to build, you realize that it's actually harder to have more and more things automated, so, you hire more and more people, and then generally speaking, quality goes down, and then you have a tremendous amount of churn.
And you seem to have done something really special, and so, I'm curious both, you had a very clear understanding of the problem, a lot of pain, personal pain, market pain in the interviews you did, and then you said, "Okay, well, how do we want to solve this?" And you became quite opinionated that it was human plus machine, and then you made that actually work. And so, it would be great to learn more about that path, how you landed on it, and maybe any primitives or principles that you think you got right, that I'd argue that most everyone, nearly every other company got wrong.
Waseem Daher:
You're definitely right that this idea of tech-enabled services is quite in vogue, and the track record of businesses in this space has actually not been phenomenal. And so, let's talk about the three points you mentioned, which is like, well, why did we decide to get on this ride specifically? And maybe what are we doing differently? And I think the risks you identified are exactly right. Okay, first, why did we decide to go down this path as opposed to a path of making pure software? Well, I think it's really because we want to solve the actual problem, and the actual problem that the business owner has is not, "I want to buy accounting software," the problem that the business owner has is, "I want this stuff to be taken care of so I can focus on running my company."
And in some ways, the power of the relationship comes from owning the problem end to end. And this is not a perfect example, but if you look at something like Uber, Uber could have sold ride-hailing software to taxi companies, but actually as it turns out, it is much more powerful to own the customer relationship by actually providing the service end to end. Now, the difference between something like an Uber and something like a Pilot is, Uber's a marketplace, whereas with Pilot, all of our folks are full-time employees of ours. We supply the "supply side of the marketplace." There is no marketplace, we are simply providing the service that we provide. And we can talk at length about why that's the case.
Okay. So, then the question, I think the risk of any of these tech-enabled services business shapes is, well, is it actually tech-enabled or are you really just building a services company? And I think the most ungameable metric that captures that is gross margin, which is, what do people pay for the service? And what does it cost you to provide the service? And one of the things we were very opinionated on from day one was that we were going to track this hawkishly, and that the solution for improving margin had to be, the computer actually does more of the work.
In other words, that we build software tools that actually make life easier or faster or more accurate for our internal team, and that the reason margin improves is because the computer is actually doing more of the heavy lifting, and not, we are de-costing things by hiring overseas labor that's cheaper or something. And I think if you're not fanatically focused on margin from day one, and you're not fanatically of the opinion that to scale the business, the only tenable way to scale is, first and foremost, to make those software improvements, it's not going to work.
The reason is actually a quite sneaky one, which is that, actually, in the early days, if the way you grow is you just hire more people and margins are bad, it actually works, it works up to a point, because while things are small, you haven't yet really hit the challenges of scale. You could build the accounting firm that serves 10 clients or a hundred clients pretty trivially with no technology. You just hire some good people and, I don't know, they work very carefully. And maybe you track their work in a Google Sheet or something. And it actually probably will work in the sense that you'll probably do good work and that your customers will probably be pretty happy. And you'll be like, "Cool, let's do more of what we were doing."
And the problem is, at a certain point, that breaks, and it stops working. And your margins are always bad. Whereas for us, we've said, "Listen, we need to invest in actually making the process more efficient, more accurate, more reliable." And the reason that we do it, importantly, is not because it makes our own economics better, the reason we do it is because it is needed to scale in a high quality way. And this is, to your second point, I think one of the places these businesses write down if you don't do it well is, as you grow, the experience is really inconsistent and is ultimately bad, and you generate a lot of detractors, and your detractors are very, very painful to you as a company.
And I'm not saying that Pilot has 100% promoters, every company always gets it wrong sometimes, but for us, the guiding principle has always been, how do we build software and how do we build process to do the work reliably at scale in a really high quality way? And the reason to invest in the software is actually to improve customer satisfaction. And a by-product of that is that it improves margin. So, I think being laser-focused on making sure that you're unlocking that scale and having the software do the things that should be software is really important. The third, and I don't really know if I 100% agree with this one, but I think it is relevant, is, I think the choice of domain does matter a lot, in the sense that there are some domains where it is easier to believe that the computer is going to do the work, and there are some domains where it's harder to believe that the computer is going to do the work, or that the shape of the work lends itself more to the computer doing the work.
And let me give you maybe two examples that are both a little bit silly, but I think are instructive in terms of how I think about this. If you think about the self-driving car, the self-driving car is kind of like the ultimate tech-enabled service. It's like, okay, the computer is going to do this thing that a person is doing today. And the challenge of the self-driving car is this, the inputs are all very noisy and fuzzy, it's like images from cameras, LIDAR, it's quite unstructured and a bunch of work needs to happen to basically turn it into something that computer can act on. You have to turn it into something that computer can act on, it has to act basically in real time, and there's no tolerance for error.
If you get it right 99.9% of the time, that's actually not good enough. It has to be right at 100% of the time, or virtually 100% of the time, for the project to work. So, that's the self-driving car, right? The inputs is all this kind of like noisy unstructured data, there's a hard time constraint, and the accuracy constraint is very firm. If you look at something like bookkeeping, well, first of all, what is bookkeeping? And what is accounting? Very, very simplistically, you track how money moves in and out of the business. And so, what are the inputs? Well, it's the data sources like the bank, the credit card, the expense reporting tool, the payroll processor, et cetera, et cetera.
And if you look at the nature of the data we get from those providers, it's highly structured. It's dates, it's amounts, it's memo fields, it is very machine possible data. So, our inputs are much cleaner and much better. It's not perfect, there's still work required obviously, but it's the kind of things computers like to do. Computers are very good at manipulating highly structured data. So, the inputs are well-suited for our work, the transformation process is well understood in the sense that the whole point of the field of accounting is to standardize on rules so there's not ambiguity about how you handle a given thing in a given case. And that's not to say that the rules are not complicated, they are, but structurally, the industry is one that wants those rules to exist, and where there are plenty of rules.
And then the third note, which is actually really fascinating, is that there's sort of a natural escalation path, which is that your accountant doesn't know all the answers always, and sometimes they have to ask you, and they're allowed to ask you. Your accountant can raise their hand and say, "Hey, I saw that you had this transaction and I can't quite figure out what it is. Can you give me some context on this? And with that context, I can go and do the right thing." And so, what's interesting is, if the computer can only do 90% of the work, the computer is allowed to raise its hand and to ask, to say, "Hey, I don't know what to do with this, can you help me out?"
And the first path to like, "Can you help me out?" Is, someone on our team is going to take a look and say, "Oh, yeah, well, I know what this is because I'm a smart person and I have some context on this account." Maybe we can resolve it that way. But if the person doesn't know either, the person is allowed to get in touch with the customer to say, "Hey, we saw that you have this transaction at this place and we don't really know what this is for, can you give some more context?" And so, that also, in some ways, it's not that it makes the problem easier, but it increases the probability that that software plus person system can produce output that is actually really high quality where customer satisfaction is going to be high.
Whereas if your self-driving car mostly worked, and then 1% of the time, I crashed into a wall, you're going to be pretty unhappy about it.
Brett Berson:
That makes sense. And so, what's interesting about the surface area that you're building in is it's clear that there's decades of product roadmap to be built. Literally, that's the shape and scale of the problem. And so, it would be really interesting to talk about, and this is, I think, really under-explored, you have a problem, you have a philosophy in terms of how you're going to solve it, and then you get going, and there's a zillion instantiations of the way in which you can spend the first year. And so, once you landed on it, it would be great to hear, what was the first six months like of building? And maybe why you approached it that way. And maybe you could also touch on how you landed on your ICP, and how upmarket or downmarket or who was that person you were going to build for for the first year? Because obviously, accounting at a 10,000-person company is different at a small business down the street that sells cupcakes.
Waseem Daher:
Absolutely. And yes, I mean, I think you're identifying, one of the big challenges of Pilot is that the market opportunity is so large in every direction, and it would be quite easy to try to boil the ocean and be unfocused about what we do. And that's a nice attribute of the space that we play in, which is that there is so much pain, and it is so prevalent, and actually, we are well-suited to solve all of it. The only way to solve it well is to do so in a really focused way. And so, to answer your question, what did the first six months of Pilot look like? Well, the day after we decided to do Pilot, which, actually, we didn't even have the name yet, we were like, "Okay, we're going to do this bookkeeping, accounting thing for companies, and we're going to initially focus on startups."
And so, why did we decide to initially focus on startups? Well, three reasons. One, we knew them well already, because we could draw on our own experience, that's a little bit of a cheat code. Two, it's actually a very hard version of the problem, because the nature of the startups' accounting needs are, they vary dramatically. When it's two people in the garage, it's very different than when it's 300 people with a VP of finance and controller and all that good stuff. And so, we knew that it would pressure test the model in a variety of different ways that would prevent us from over-fitting on one particular use case. And three is actually that we had to solve for initial distribution, which is that we were going to call up all of our friends and make them use Pilot.
And so, actually on the first day, what I did is, I literally emailed, and I had these emails in my inbox, I emailed three founder friends that I knew, I said, "Hey, who's doing your bookkeeping? We're thinking about doing a startup in that space." And they replied like, "I actually haven't gotten around to it yet. I'm not sure." And then I immediately replied, "Cool, congratulations, I'm your new bookkeeper." And I bought a copy of QuickBooks Online, and Jeff and I did the bookkeeping, and Jessica looked over our shoulders to figure out, "What software tools should we build to make the work that Waseem and Jeff are doing by hand here more automatic, more liable, more efficient, et cetera?"
So, the early days of the company were really, we did the bookkeeping by hand, and Jessica did the initial code to figure out, "What are tools that we can build to do this work?" So, it was really a deep, deep, highly iterative, really the whole system being built together, tested by that end user experience of, "Look, we're on the hook ultimately for delivering high quality work to our initial customers."
Brett Berson:
Do you remember the philosophy or rubric that you used to figure out over those first six, 12, 18 months, what you would build and what order? Or was it just highly judgment-based, studying the problem and saying, "We're going to go do this next, and that next"?
Waseem Daher:
Yeah, no, it was actually extremely quantitative, meaning, ultimately what we ended up landing on is, there's a process for doing the bookkeeping every single month, and the process has a variety of steps, and the steps have a variety of sub-steps. And we would time each step for each customer. And so, we could say, "Oh, step seven," payroll journal entries or whatever it is, "we spend 30% of our time there," or whatever it is. "And in particular, on these customers, we spend more time, and on these customers, we spend a lot of time."
And so then Jessica and engineering team could look at that data and say, "Huh, a huge chunk of our time is going into task X. If we could make task X 50% more efficient, or 90% more efficient, or we could just have the computer do it entirely, these are the savings we would realize from doing that." And so, in some ways, this is overly simplistic, but there's a kernel of truth to it, if you're a programmer and you're trying to make the program run faster, you'd look at the output of a profile, and it says, "Oh, these are the function calls that exist in my program, this is how long we're spending in each of them, and here's why we're spending so long in each of them. Oh, it's taking 200 milliseconds because we have to read this data from the disk," or whatever.
And then you, the kind of software engineer, would say, "Fine, I'm going to go and optimize this to reduce the overall time that my function takes to run." That same sort of like iterative framework always apply to the problem of actually doing the books. And there are two objectives you're solving for here, one is time spent, but the other is quality. So, we look on both the axes, what are the things that are slow? Or what are the things that are error-prone? And very methodically and systematically, we can just knock through that list.
Brett Berson:
How about prioritizing or thinking through the common infrastructure versus point solutions? Or was that more intuitive? Where you could say, "Okay, we're doing this process, let's build a little tool or widget to help us do this," and at some point along the way, I assume there's either a concept of a general ledger or whatever, kind of the more horizontal thing that things start to get built on top of. Was that built in a certain way?
Waseem Daher:
What you're identifying is the reason it's a hard engineering problem, which is, I think one of the things that I tend to do that's bad when I talk about the stuff we've built is I make it sound simple, and it's not, it's actually like a quite meaty and challenging engineering project, but I think is really truly on the scale of some of the complexity you would get if you were trying to build a self-driving car, because it has all the nuances that you've pointed out, which is, we can't be in the business of building little point solutions that are not generalizable, because all of this stuff needs to play well with all the other stuff we've built, and we're trying to build something that is flexible enough to work for the two people in the garage, the 500-person company with the CFO and the controller, and the dentist's office, and the coffee shop, et cetera, et cetera.
So, it does require really good systems architecture and good taste when it comes to actually designing the tools and processes that we build, because we want to make sure we're building for scale and we're not just slapping a bunch of band-aids on the acute issues.
Brett Berson:
And so, is there a how behind your approach, or it's just judgment? Meaning, you're getting at, there's this very delicate balance, at least as you're talking about it that makes sense to me, which is, you could go and build this huge monolith, this just fully-featured thing that you have an eye towards the next 10 years of who's going to use this thing, or you can do things incredibly incrementally. But a lot of times, if you're too incremental, then you wake up in two years with a bag of knobs or a bag of features or whatever else, without an infrastructure that actually allows you to build orders and orders of magnitude and scale. And so, managing that seems quite tricky.
Waseem Daher:
Yeah, it's tough, and I think Jessica would have a much more nuanced answer on this question than I do, but I think there are maybe two things going on here. One is, it is a matter of taste, and I think there are some principles of good system design that our team has that we keep in mind. I don't know that there are real silver bullets here or rules that are universally applicable. The other thing, and I hesitate to say this because I think our engineers won't like it, it's not the end of the world if you get to year four and the company is super successful, and you look back and you actually have a bag of hacks. Your company did get to where it got, you can now make the investment to pay down some of that technical debt. I think that it's a continuum of what's acceptable there.
It can't be that the whole thing is like a very delicate house of cards that falls over with the slightest gust of wind, that's not going to work for you, but it's also not the case that if you spent all your time like really polishing and perfecting everything super shiny, and then no one used it, that would also be pretty bad. So, there's a certain amount you have to optimize for velocity, in addition to optimizing for like good system design, and sometimes that requires the thoughtful and intelligent, and I guess I should just say eyes open acceptance that we're going to take on some tech debt in that process.
Brett Berson:
A related question is, you mentioned this a few minutes ago, launching tax, and you have a few other product areas that you've built out. How do you choose, with a nearly unlimited amount of opportunity in front of you, how do you choose what to do? And is it mainly just whatever that you're seeing the most pull from? Or do you have a philosophy around that?
Waseem Daher:
I think the biggest things we think about are, definitely, customer pull is a huge consideration. Why did we do tax? I mean, we were very resistant to do tax in the early days of the company because there's a lot of work. In some ways, it felt like it was going to represent a big distraction from the core bookkeeping work we did, but what we found is, our customers really, really wanted it. And in fact, when we started to do it, customer satisfaction was way higher. And what was interesting is, the north star on doing this was not, "Oh, it's a cross-sell that we'll be able to monetize. We'll make more revenue if we sell tax." No, incidentally, yes, that is true. The reason that we did it is, from a customer experience lens, the customer experience is better if we do it.
And so, customers are happier, they refer more people, they are retained longer, or they tell their friends about it. Everything works together very seamlessly. It was very customer-oriented in how we made the decision. The second thing we try to do as we evaluate what the next cross-sell is or what the next capability to add is, is how generally applicable is it? In other words, I think we would be unlikely to make a large investment to unlock a particular capability if it was only applicable to five or 10% of our customer base, or at least, that's not where I would start, I would want to start with something that everyone needs, where we have a right to sell it, where the customers want to buy it from us, and where we know we can do a good high quality job.
And then, I guess, the fourth point there is also, and where there is not a good alternative in the market today. Like as a very concrete example, I would be shocked if we ever build a payroll system or a corporate card. I'm not going to say we never, never, never will, but I think it's extremely unlikely because there are lots of good providers in those spaces today, and it's good for the customer and it's good for us if we just say, "Hey, yeah, just go use system X, Y, Z, we think it's great. We have a deep integration with it." That seems far better for everyone than we introduce yet another provider in a space that is already crowded with lots of providers, some of whom are very good.
Brett Berson:
The sort of related idea here is, if one is you can expand product offerings, the other is that you can expand ICP. I was interested to learn more about, you mentioned you started with, it sounded like customers that were even pre-bookkeeper or maybe just had a bookkeeper, and obviously, you've grown the ICP over time. Was that just organic market pull? Or did you say, "We're going to be dedicated to a very specific customer persona for this period of time, and then we're going to move to this one and this one in some way"?
Waseem Daher:
A little bit of both. Some of it is our existing customers growing up with us, and that forces, there's a natural kind of a market pull, and some of it is a concerted effort to say like, for example, where do we really play today at Pilot? Well, we're very, very, very good at venture-backed and venture-backable tech companies of various sizes and stages. That's, by far, our bread and butter. And I think you see that in our customer count and our percentage of market share, et cetera, et cetera. We're also really great at e-commerce folks, folks that sell on Shopify or Amazon Seller Central, that consumer and retail shape of business, and also very good at professional services firms, the marketing consultancy, et cetera, et cetera.
And then there's also a long tail of miscellaneous businesses that we support. And I think as we think about how to expand the aperture of folks that we're really focusing on or that we accept, one of the questions we ask is, "Okay, what's the composition and the customer base today? Something we're doing is causing a lot of e-commerce companies to knock at our door. Let's double down on that. If they're knocking at our door anyway and we can service them well, great, the sales and marketing machine is already able to capture them, we just need to do the work successfully." So, there's a little bit of a, "Let's answer the door for everyone that is knocking, and use that to inform where we might go."
There's also a bit of interest generation, where we say, "Well, we think that this shape of customer would knock on our door if they were aware of what we were up to, let's make a concerted effort to focus on and bring those folks on board." And we haven't done this a ton today, but you could definitely imagine a world where we say, "You know what? We're going to get really specialized at doctors' offices, for example, and we'll integrate with every insurance system and we'll just have a bunch of code that really just..." There's a lot of mechanical work that goes into the bookkeeping or accounting for a doctor's office.
And once we've done that work, and once we've built the software integrations and we can do it better than anyone else, it should be very straightforward to go to every doctor's office and say, "Hey, listen, we have this amazing product, it's way better than what you're doing today. We have this great service we can provide to you. Let's get you on board." And I'm making this up. We build a deep integration with mind-body, and then we go to every yoga studio and say, "Hey, listen, you're using this system as your point-of-sale system to run your business. We're actually the best provider. We know this way better than anyone else. We have a deep bench of talent on the team that knows it, we have a deep bench of software integration that makes us work better, let's get you on board."
Brett Berson:
Is there anything, when you think back to the negative six months to first six months of company building, that you got right, or a part of the underpinnings of your success that maybe we didn't explore yet?
Waseem Daher:
For me, key was just making sure that I was recharged and fired up about it, that I had the team that we were just excited to get cracking on it together, and that we were thoughtful about the market size and the market opportunity. And I think, importantly, we didn't spend six months thinking about whether this was a good idea, we actually reached initial conviction on it pretty quickly and we said, "Listen, we just got to try it. And if it turns out that it's a disaster, well, we'll come back to the drawing board. But we're going to commit to it, we're going to see how far it goes, and then we'll make a decision from there."
And I think there was a strong temptation to do more analysis, or at some level, look, you have no idea whether that thing's going to work or not. And the average idea will not work. And you're not going to really get a strong conviction beyond maybe your initial thoughts on the matter by doing another three months of homework on it, the way you'll get to conviction on it is, you will declare, you're going to burn the ships, you're going to try to make it work, and then you will see what happens.
Brett Berson:
I thought maybe we could end our time together with the question that I always really like, which is, who are the people that have had the largest outsized impact on the way that you've approached company building? Could be Pilot or past companies. And maybe if you think about a few of them, are there crystallized ideas that are part of your worldview or company-building philosophies?
Waseem Daher:
Yeah, I'd say probably the most influential individual for us or for me personally is this guy, Hans Robertson, who's actually on Pilot's board. He was an investor in Pilot, he was an investor in Zulip as well, and his track record was, he was one of the founders of Meraki, which was a company that made networking equipment that Cisco acquired, and now has a company called Verkada, which is a enterprise security camera company. And he's just an amazing thought partner in all things go-to-market. If there's anything sales and marketing strategy-wise that I have a question about, he's my first call, but one of the things that he said that resonated with me is, "You just have to be a heat-seeking missile for revenue." I mean, he would say revenue, I'd say customer pain, but the two should be the same.
One of the things I feel strongly about is, I don't know that I'm smart enough to predict the future or to know exactly what the customer wants. And I think it's important to say that out loud, which is, "Well, fine, if that's the case, what does that suggest that you should do? Well, it suggests that you should spend lots of time talking to your potential customers." Because I don't need to derive it from first principles, I can actually figure it out by talking to people and asking them, "Hey, I'm not asking you what do you want me to build? I'm asking you, what is painful to you? What are your top three hair on fire problems? If I could solve problem number one for you, would you pay me $500,000 or whatever it happens to be?"
And so, for me, I think that real laser focus on that customer conversation, customer development, making sure you're building something that people want, is a big piece about how we think about operating our companies.
Brett Berson:
On that point, what's interesting about that idea or advice is it's something that's widely known, but I actually think if you look at most people's calendars or what they actually do, they tend to not do it for some reason. Do you have any theories as to why that is?
Waseem Daher:
I have some theories, yes. You're totally right, it's not a rocket science idea. I think some people just don't do it, or if they do do it, they're doing it wrong. And let's talk about both really quickly. I think the reason that folks don't do it is because it's scary. You're going out into the world and you're putting the thing you've built out there, you're putting a little piece of yourself out there, and so, you're opening yourself up for the possibility of rejection. Rejection is painful. And yeah, sometimes you'll have conversations and the prospect or the customer or the potential customer will say, "No, I don't have this problem." Or, "No, I actually don't care about that thing." And that hurts.
It's much easier in some ways to stay in the lab polishing the thing, because, cool, you know what to do, it's fairly well-defined, you feel like you have a vision for it, you could just build it. But it turns out it's not useful to build it if no one wants it. But it's easier to build it than to deal with the emotional pain of having someone tell you that they don't want your thing. So, I think that's reason number one. Reason number two might be, I don't know, maybe you think you are smart enough to predict the future, and therefore, that you don't need to talk to the customer because you already know the answer. I think sometimes that happens.
And then reason number three is probably, okay, you're talking to a customer but you're not actually asking the right questions. Because usually what will happen is, especially in the early days, you're talking to someone and you're like, "Hey, let me tell you about this cool thing I'm building. What do you think of it?" Well, there are two problems there. Problem number one is, the question is not, "What do you think of the thing I'm building?" The question is, "What is the problem you have?" And then once I understand the problem you have, it's, "Well, if I had X, Y, Z for you, would it solve that problem?" So, there's like, what is the question you're asking?
And the second is, is not, "Well, do you think someone would buy it?" The question is, "Would you specifically give me $500 right now for this thing?" Because the problem is, the people you talk to don't want to hurt your feelings, and they want to be on your team, and so, if they think your idea is terrible, they're probably not going to point-blank tell you that. They'll probably tell you like, "Yeah, maybe I don't particularly need it, but probably someone does. Yeah, go for it. You should make that thing." Whereas if you force it to be crisp and concrete with them by asking, "Would you give me this amount of money right now?" That's a lot less theoretical.
And if the answer is no, I have to tell you no. Because if I'm like, "Yeah, give me your credit card, I'll charge you 500 bucks right now," you'd be like, "Well, actually, no, I don't know that I'm ready to sign up for that service yet." And so, that's going to force an amount of just more rigor in the feedback you're getting from the market, which is what you need to actually build the right thing.
Brett Berson:
Just to put a bow around it, somebody comes to you and says, "Hey, I'm going to talk to potential customers for the first time, can you give me a script to make the most of it?" What are the types of questions or how would you have them architect that?
Waseem Daher:
I think the first thing you got to do is, understand what their pain is. And particularly the question I like is like, "What are your top three hair on fire problems?" And maybe you don't ask it so directly, but you're really trying to tease out, "What are the top three things you're worried about right now?" Because I'm not there to sell you my thing, I'm there to understand what problems you have. And then secondarily, once I understand the problems you have, and now I've earned the right to ask whether, "Well, hey, if I could do thing X, Y, Z, for you, would that solve one of your top three problems?"
And the reason top three matters is, sometimes you're solving problem number 20, and the problem is, if you go and you say, "Hey, if I could solve problem number 20 for you, would that be interesting?" You might tell me like, "Yeah, yeah, I do have problem number 20, I do have the problem that I'm not very good at parallel parking." But if you're like, "Cool, I'm going to start a school to teach you how to parallel park, will you pay me $5,000 to do that?" That's problem number like 432 for me, Waseem. I don't have time to learn to parallel park, and I'm never going to get around to learning to parallel park, I'm only laser-focused on problems one through three.
Which is why the orientation is not, "Is this a problem you have?" Yeah, I'd love to parallel park, I'd love to be able to play guitar, but I'm never going to get to priority number four, my day is entirely consumed with priorities number one through three. So, the orientation of your question has to be, "What are your top three problems? Talk to me about stuff where you're like, 'Ah, this is such a burning need for me.'" And Steve Blank talks about, ideally, it's such a burning need that you already have some sort of like really gross duct tape solution that you're trying to hack together to solve it. It's so painful that you've cobbled it together, that's how you really know that there's really pain there.
Brett Berson:
And then maybe they tell you it's recruiting, where do you go from there?
Waseem Daher:
Well, I think you got to get more specific now. It's like, "Okay, cool, you have the problem. Yeah, you want to hire good engineers," or whatever. Well, let's be more specific like, "What is the actual problem? Is the problem that you don't have enough bandwidth on a team to find good candidates? Is the problem that your interview process isn't very good? Is the problem that actually you're making a lot of offers but you can't close them?" You have to then rerun that process iteratively to really, really understand what the actual pain point is. And once you've pinpointed that, then you can say, "Well, okay, fine, how would I go about solving it?"
Because the solution to the problem of recruiting, it depends on what that means. And so, that's another place that you can definitely be led astray. You have to really viscerally understand the problem that that customer has. And the way you get there is you ask lots of people and you interpolate all of the data you get from all of them, you'll hear consistent themes, and I think having enough of those conversations with enough different people, some trends will start to emerge. And that's when you know you're onto something.
Brett Berson:
Well, I think that's a great place to end given how profoundly important that work is, and how it's often either not done or not done well. So, thank you, thank you for sharing that and for spending this time with us.
Waseem Daher:
Of course, thanks for having me.