Episode 27

A look at one repeat founder’s frameworks for validating ideas — Pilot’s Waseem Daher

Today’s episode is with Waseem Daher, co-founder and CEO of Pilot. Prior to Pilot, Waseem co-founded Ksplice, which was acquired by Oracle in 2011 and Zulip, which was acquired by Dropbox in 2014. In this conversation, he pays particular attention to Pilot’s first year — including validating the idea, choosing an ICP, and outlining the product roadmap for a company that can go the distance.

Photo of Waseem Daher
Subscribe with your favorite podcast app


Waseem Daher: [00:00:00] I like to ask three questions about a business that I'm evaluating or an opportunity I'm evaluating. And this is principle 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 our people's hair really on fire about this? And the third question is how much does it cost

Brett Berson: [00:00:35] 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, roadblocks, 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@firstround.com

today's episode of in-depth I'm ready, really excited to be joined by Wassim  Wassim 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 Wassim co-founded case blights, which was acquired by Oracle in 2011 and Zula, 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.

Wassim 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 pilots, ICP and how we 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 Wassim's playbook honed over the course of building three companies.

Wassim 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, quasi, thank you for joining us. Of 

Waseem Daher: [00:03:37] course. Thanks for having me. 

Brett Berson: [00:03:39] So 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 gets started and the three to six months after a company gets started is one of the most underexplored or misunderstood parts of company creation. And it's generally kind of 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.

And 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 in the way that you were going to build.

Maybe we could use that to get started. Yeah, 

Waseem Daher: [00:04:31] absolutely. So very interestingly. And I'll give you the long version and you can tell me kind of 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, do you have Jessica?

And I all met and MIT. We were also in 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 a long before we started working together. But right out of school, we started a company together called K splice that did software updates without rebooting.

I'm sure you've seen a pop-up it's like you must reboot to install new updates. And we all lived and worked in this like 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 to the tech and then hit a jacked. 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 Zula. 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 pinwheel we had ourselves. I would not give us 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 well though, Dropbox acquired it. We were at Dropbox for about two years running product and engineering, and then laughed. And now to answer your very specific question, if we talked 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, tend to all the things I'd 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, where six months in which not literally that I did nothing, but where I did nothing that was intended to ultimately yield a startup idea at the time was spent basically visiting friends and family, going to the gym, sleeping eight hours a night, spending time with my wife, you, I 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 man 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 like sit in a room and like, 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 in your brain is like, well, no, that idea sucks.

There's no way this thing has been a work because of X, Y, Z. There's no real way to make it go faster. Like you think about 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 sort of unclear. The goal obviously is like, figure out what company we want to start, but there's sort of no real incremental steps along that path, or at least none that I was aware of.

But the first several weeks of the company were getting together with my co-founders and saying, okay, where, 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 we aggressively lineup 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 is 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, 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's 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 are 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 like at some point you just kind of 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 sort of 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, we, of course we can revisit, but we sort of 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.

I find it interesting 

Brett Berson: [00:11:11] 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, an exceptional solution. Then 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: [00:12:09] 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. And I think, or maybe you 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 who worked 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, 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 foreign 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 liked 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 is 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 as 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, 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's probably 10 other companies that we could do together and I would be equally happy about it. And you sort of see that in our track record, this is the third company we've done. These companies have all been very, very different, actually.

So if you reverse 

Brett Berson: [00:14:37] 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 it sort of anything comes to mind 

Waseem Daher: [00:15:04] for you. Well, 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. Like there, there is always tension. There is, but it's, I think it's like a healthy, constructive tension.

And I think in any long term 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 toast stepping. There's very little getting up in each other's businesses. 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 like go do and again, the 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. And the three of us should talk about 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, in not my interest. So I think that's the other piece that kind of makes it work. And then the third is, I'm 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: [00:17:30] So switching back to the process of landing on the idea for a 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.

As the company we want to build, meaning as a few minutes ago, you were talking about exploration. And following some different threads, you are 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 

Waseem Daher: [00:18:27] company. 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, the rational pieces event, which are, I think classically what some investors say is the only problem you can't fix is the problem of 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 and our very first company, the way we landed on the problem for the first company is we were like, well, we have this tack, it happens to have a problem. We have like, let's go do it.

Surely we'll figure it out. We were not particularly thoughtful about it. How big could this be? If it's phenomenally successful, how many people have this problem? How much pain are 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 it is a nice to have, or is it a need to have our people's hair really on fire about that?

And the third question is how much does it cost? And the reason that how much does 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 spread 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 avenue to have and how expensive it is?

You basically multiply those numbers and then you're like, oh, okay. This is approximately kind of 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? 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 as well. What are problems 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, if you're a total weirdo and like 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, like 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 is an extremely strong narrative about why this was the right team for the problem.

And I think that was 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 a spin market, HR thing, probably the narrative would have been a little bit counterfactual, a little bit revisionist would have been like when we were at these big companies, when we were at Oracle and 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 like 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 visceral personal connection for it.

You're sort 

Brett Berson: [00:22:53] of 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 transcendent company where your first two attempts 

Waseem Daher: [00:23:13] were? Not that one of the things that what'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 Zula had now, they executed better on it. They exited differently on it and that, and those differences happen to yield a much, much better result. But I think we picked the right target in our previous venture and 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, like 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 US-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 it built.

You should think of as the iron man suit for our account managers. So then pilot thesis is really people doing what people do best and software doing. What software does best working together will 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. Like that's pretty neat 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 end to end ownership is the alternative to hiring pilot. Is hiring the local provider whose offices 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 at 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, again, you do that multiplication and what you get out of the other side is that the market size is 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 economy, 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 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. Like you want to focus on the reason you started the company in the first place.

And so the longer term, like 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, more efficiently, more scalable, more painlessly, and we'll 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 of Amazon-like attributes in a way in two ways. One is like Amazon. Okay. You first they're selling books. Then they sold CDs. And they sold books and CDs and MP3s. And now you can buy literally anything you want an 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, like 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 pitcher pilot is could you hire someone to stitch together a bunch of your back office stuff, flight? Yeah, you could, or you could have to do it. And the advantage of hiring us to do it is that we can do it more scalably, more Elias, really 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 so 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? Did 

Brett Berson: [00:29:51] 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 

Waseem Daher: [00:30:00] building? The honest answer is, I don't know.

Here's what I would say. You know, 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. Bass Salvadoran what's offered as bass, that we're going to own the problem end to end, and that there is real power in owning the problem at hand.

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 do is 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. Like, I would love for someone to take this on my plate for me. So I think we knew certainly the vision of like let's to 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 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. This might be a 

Brett Berson: [00:32:04] 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 called the past five to seven years to do something that's quote, 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 amount of money, and then not worked is extraordinary. And as I've spent a lot of time, you know, at a high level sort of studying this, I think a lot of it comes down to it.

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, actually harder to, 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 when you thought what 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: [00:34:00] You're dead. Well you're right, that this idea of tech enabled services is quite invoked. 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 read specifically?

And maybe what are we doing differently? And I think the risks you identified are exactly right. So, okay. First, why did we decide to go down this path as opposed to a path and 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 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 their 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 right here, software to taxi companies, but actually as it turns out as 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 is a marketplace. Whereas with pilot. All of our folks are full-time employees of ours. We supply the quote unquote supply side of the marketplace. There is no marketplace. We are simply providing the service that we provide and we could 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 ungovernable 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 D 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 gonna, the reason is actually a quite sneaky one, which is that actually in the early days, if the way you grow, as you just hire more people and margins are bad, it actually works. It works up unto 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 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 break 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 a hundred percent promoters. Like 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 do 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 a hundred percent 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's going to do the work.

And there's 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. 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, a 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 like noisy and fuzzy. It's like images from cameras, LIDAR, it's like quite unstructured and a bunch of work needs to happen to basically turn it into something that computer can act on.

You have turned it into something the 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's sort of has to be right. 100% of the time or virtually a hundred percent 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, like what is bookkeeper and what are the 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 parcel data. So our inputs are like much cleaner and much better. It's not perfect. Like 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 sort of 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 is 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 roles.

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 it, your accountant can raise their hand and say, Hey, I saw that you had this transaction.

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 it'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? As you know, someone on our team is going to take a look and say, oh yeah, well, I know what this is because like, 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 had this transaction to this place.

And like, 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 the software plus person system can produce output. That is actually really high quality where customer satisfaction is going to be high.

Whereas if you're self-driving car mostly worked and then one person at a time I crashed into a wall, you're going to be pretty unhappy about it. That makes sense. 

Brett Berson: [00:42:35] 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 

Waseem Daher: [00:43:34] cupcakes.

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 we actually didn't even have the name yet, we're 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 her and experience. That's a little bit of a cheat code to, 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 sort of 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. You know, we're thinking about doing a startup in this space. And they were applied like, you know, I actually haven't gotten around to, but yet I'm not sure.

And then I'm either probably 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 was semen, Jeffery doing by hand here, more automatic, more liable and 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 kind of being built together, tested by that end user experience of look we're on the hook, ultimately for delivering high quality work to our, so customers, 

Brett Berson: [00:46:06] do you remember the philosophy or rubric that you use to figure out over those first 6, 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 

Waseem Daher: [00:46:21] next.

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 stamps. 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 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 each of them, oh, it's taking 200 milliseconds because we have to read this data from the disc 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 seems sort of like iterative framework. What was applied 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 kind of just knock through that one.


Brett Berson: [00:48:06] 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 is kind of the more horizontal thing that things start to get built on top of was that built in a certain way, what your 

Waseem Daher: [00:48:32] identity fighting 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 kind of simple and it's not, it's actually like a quite and challenging engineering project that I think is really, truly on the scale of some of the complexity you would get.

If you were trying to build the 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 acuity. And 

Brett Berson: [00:49:35] 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 sort of, 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 in orders of magnitude and scale.

And so managing that seems quite tricky. 

Waseem Daher: [00:50:15] 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 are 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 now make the investment to pay down some of that technical debt. I think there'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 in a super shiny and then no one used it, like that would also be pretty bad.

So there was a certain amount that 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: [00:51:31] The question is, is you mentioned this a few minutes ago, launching tacks and you have a few other product areas that you've built out.

Uh, 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 the you're seeing the most pull from? Or do you have a philosophy around? 

Waseem Daher: [00:51:54] I think the biggest things we think about are definitely customer polo is a huge, is a huge consideration.

Like why did we do tack? And 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 like 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. Like we'll make more revenue. If we sell tax incidentally, like, 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 like works together very seamlessly. Like it was very customer oriented and 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 it is, is how generally apical 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 in 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. Then we introduce yet another provider in a space that was already crowded with lots of providers. Some of whom are very good.

Brett Berson: [00:54:01] This 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? Polar, 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 

Waseem Daher: [00:54:29] some way, a little bit of both, some of that is our existing customers growing up with us and that sort of forces, there's a natural kind of a market poll.

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 in 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 was also a bit of interest generation when we say, well, we think, 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 doctor's offices, for example.

And we'll integrate with, you know, 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 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. I'm making this up. We build the deep integration with mind body, and then we go to every yoga studio and say, Hey, listen, you're using the system as your point of sales system to run your business.

We're actually the best provider. We know this way better than anyone else. We have these deep, 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: [00:57:05] 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 

Waseem Daher: [00:57:17] for me key was just making sure that I was like 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 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 is a strong temptation to do more analysis or at some level, look, you have no idea what the 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: [00:58:24] I thought maybe we could end our time together with the question that I always really liked, 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: [00:58:49] I'd say probably the. Most influential individual for us, or for me personally, is this guy hons Robertson. Who's actually on pilot's board. He was an investor in pilot. He was an investor in Zulema as well. And his track record was, he was one of the founders of Muraki, which was a company that made networking equipment that Cisco acquired and now has a company called ricotta, which is a enterprise security camera company.

Yeah. And he's just like an amazing thought partner in all things go to market. If there's anything sales and marketing strategy wise that have a question about like, is my first call. But you know, one of the things that he said that like resonated with me is you just kind of, I 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 we'll 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, real laser laser focus on that customer conversation and customer development, making sure you're building something that people want is a big piece about how we think about operating our companies on that 

Brett Berson: [01:00:36] point.

What's interesting about that idea or advice as 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: [01:00:54] I have some theories. You're totally right. It's not a rocket science idea.

I think some people just don't do it or if they do it, they're doing it wrong. And I think let's talk about both really quickly. I think the reason that folks don't do it is because it's, it's scary. Like you're going out into the world and you, like, 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 like, yeah. Sometimes a lot of 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. Like it's much easier in some ways to stay in the lab, polishing the thing, because like, cool.

You sort of 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 like not useful to build it if no one wants it, but it's easier to build it then 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, number two might be, I dunno, maybe you think you are smart enough to predict the future and therefore 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 and someone and you're like, Hey, let me tell you about this cool thing I'm building.

What do you think of it? Well, so there are two problems there. Prom number one is the question is not, what do you, 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 is, well, if I had X, Y, Z for you, would it solve that problem?

So there's like, what is the cost 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 like the people you talk to don't want to hurt your feelings and like 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. You know, maybe I don't particularly need it, but it probably someone does. Yeah. Go for it. You like should make that thing. Whereas if you force it to be crispy 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 now, because if I'm like, yeah, give me your credit card. I'll I 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.

Just to sort of put 

Brett Berson: [01:03:42] 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: [01:03:54] I think the first thing you gotta 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 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 like 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 was seem like I don't have time to learn a parallel park and I'm never going to get around until learning to parallel park.

I'm only laser-focused on problems. One through three, which is why the orientation is not is this 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? Like talk to me about stuff where you're like, oh, 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 like really pain there. And then maybe 

Brett Berson: [01:05:35] they tell you it's recruiting. Where do you go from there? 

Waseem Daher: [01:05:39] 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, like 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 and very good is the problem that actually you're making a lot of offers, but you can't close them. Like you, you have to then kind of 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 the customer has and the way you get there, as you ask lots of people and you sort of 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 on something. Well, I think 

Brett Berson: [01:06:37] 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. Of 

Waseem Daher: [01:06:49] course. Thanks for having me.