I'm Waseem Daher, Cofounder and CEO at pilot.com. AMA!

Hi everyone! I’m Waseem Daher, CEO of Pilot. I previously cofounded Zulip (acquired by Dropbox) and Ksplice (acquired by Oracle).

Pilot handles your accounting/tax/forecasting, etc. When you work with us, you’re paired with your dedicated account manager (a full-time employee of ours), who takes the work off your plate every month. (Under the hood, we’ve developed a bunch of software that our team uses to do the work with greater consistency and accuracy than anyone else out there.)

Key point here: Pilot is a service, not a piece of software you buy. (You hire us instead of hiring another accounting firm.) Think of us as your back-office finance partner with an Iron Man suit.

Happy to talk about:

  • Being a serial entrepreneur
  • Starting a company with the same founding team three times
  • Acquisitions
  • Anything startup finance-related
  • The R&D tax credit
  • Sales for technical founders
  • … and really anything else startup-related—I just love this stuff.

I’ll be back on January 14th at 11:30 AM PT to answer as many questions as I can—looking forward to it!


Note: This AMA is closed for new questions, but you can check out the existing conversations below.

This January 14th, for the year’s first Relay AMA, we got to host Pilot’s co-founder and CEO, Waseem Daher. Having previously co-founded Ksplice (acquired by Oracle) and Zulip (acquired by Dropbox), Pilot is Waseem’s third foray into SaaS.

He has thus unearthed, with two equally thoughtful co-founders who’ve been with him all along, a lot of the invisible, founding scaffolding one must build upon. Sizing up a category’s adjacencies and potential. Telling apart what merely feels productive from what is. And valuing the quiet joy found in the day-to-day craft of building an org, over the ardent (ultimately exhaustible?) enthusiasm of any given startup idea.

AMA Index (Waseem’s brain-pickings) :sparkles:

(founding insights, opinions, and observations; deftly examined and articulated)

“The worst of both worlds: decentralised teams that move slowly”
On goal-setting: “set destinations , not routes for your teams”
Why Pilot doesn’t just sell software; neither does any other SaaS
Technical-founder-led sales
Acknowledging founder time as a scarce resource and how to “maximally leverage” it?
A necessary precursor to introducing new products and what Waseem would do differently with a previous venture (a collaboration tool that predated Slack)
The question to ask before making that first critical sales hire
On OKRs: “it’s important for everyone at the company to understand the company’s objectives, their own objectives, and the line that exists between their objectives and the company’s objectives”

Further reading/listening/pondering from the interwebz :open_book:/:headphones:

(Other insightful excerpts drawn from blog posts, interviews, and conversations)

On how most things aren’t worth fretting over:

“This sounds hard to believe, but almost all of the things you might be worrying about as a first-time founder don’t matter. I vividly remember agonizing overnights and weekends about all of these things that we thought would kill the company, and in the end, they were all irrelevant.

In particular, a lot of people (my past self included) spend a ton of time worrying about what the competition is doing, rather than worry about whether customers really love what your company is doing. If you can deliver a high-quality product that solves a very hair-on-fire problem for your customers (and they’re willing to pay you for it), you’re off to a very good start. Until you’ve done that, that’s probably the task that should occupy 100% of your mindshare.”

Source: 5 Questions with Waseem Daher, Founder of Pilot

On the world-expanding periscope doing early sales as a founder can offer:

“Ideally, you have a founder, who is just going to go all-in on sales stuff. I don’t think that requires them to be a sales person by training. But I think there’s something really, really powerful about having one of the founders operate the sales machine. Because you learn a ton about the world. Like sales is the little periscope you’re looking through to understand what is out there. And to have that information funnelled through a third party who is not empowered to make decisions, I think it’s hard. You can get that much tighter feedback loop if you have a founder doing it.

If you do have a person on the team that’s willing or capable of doing that work, I think, when you get to the point where you feel like it has started to become a process. And you’re not able to close sales at the rate you’d like to close, or you feel you’re dropping stuff on the floor, that’s probably when I’d look to say ‘well, how do we add another person to the team to give me more firepower.’ But, importantly, I don’t think that person is going to be able to figure out how to sell your thing. I think, ideally you as a founder, should have demonstrated that it’s possible to sell, and here’s the shape of how it might be sold."

Source: Fireside Chat with Waseem Daher

On a fundamental transition all CEOs must make:

“I think the specific nature of the work has changed a lot. And, I think, I’ve been a little slow to catch up with it. Which is, in the very early days of the company. And this will all sound obvious in retrospect. In the very earliest stage of the company, your job is just to do the thing that needs to be done. So sometimes that’s sales calls. Sometimes that’s taking out the trash. Sometimes it’s hiring people.

It’s just like whatever needs to be done, your job is to just do the thing. And then increasingly as the company grows, your job is less about doing the thing and more about building a company that can execute well on the things that need to be done. And so, in particular, at this stage in the company’s life if I’m doing a specific thing that’s actually a bad sign. It really means that I’m gating the growth of the company in some way.

My only jobs should be: attracting/retaining the best people, parting ways with people that don’t work out, funding initiatives and de-funding initiatives. It’s really just operating at one level of abstraction above, honestly, classically, what I’m used to. You’re used to doing things. And doing things seems so productive. Your levers as a CEO are not, ‘let me go write that line of code, let me go close that one sale.’ It’s ‘let me build a team that will close sales far better than I ever could. Or that’ll write better code than I ever could.’

It’s super hard because the first thing feels like you’re doing productive work. It’s like, ‘oh great, I closed a sale, saw the revenue number go up. Great! I actually contributed to this company today. As opposed to, ‘well, I had these five coffees with people and I didn’t fit with any of them.’ That doesn’t feel like work. Even actually the work of bucket two is likely much more impactful for the company than if you had gone and closed that incremental sale.”

Source: 20VC: Why Passion Is Overrated When It Comes to Starting Companies, Why VC Is Overrated as a Financing Mechanism & Why You Should Never Sell Your Company with Waseem Daher, Founder & CEO @ Pilot

On how existing stacks impact pricing decisions:

“With any sort of new market thing, the challenges are: educating the customer that exists and understanding where the budget is going to come from and whether it is close enough to something that already exists so that you can kind of fit into that line item. Or whether you can fit into the way they’re used to buying it. I think that also has a lot of implications on how they’d think about pricing.

For us, one of the ceilings, or at least, I believed it to be a ceiling, was how much we could charge you for our service of kSplice. Where we gave you software updates without rebooting for linux. We probably couldn’t charge you more than what Red Hat charged you for the whole Linux support contract.

Because you’re the IT buyer, [saying], ‘Well, this is a feature of Red Hat from my perspective so I can’t pay more for it than what I pay for Red Hat generally speaking… Ideally, you want to figure out the thing that is closest to your thing and try to see what lessons you can learn, either from a customer acquisition perspective. Like who buys that thing and where do they go and how to reach them. So you don’t have to create, from a whole cloth, create the whole category from scratch.”

Source: Fireside Chat with Waseem Daher

On how a thorough interview process trumps crafty interview questions:

"The thing I feel most passionately about (in the interviewing process) is just there being rigour in the process itself. In other words, before you bring in someone for an interview. Ideally, you’ve written down the role and requirements; know what the role you’re trying to hire for, you know the skills you need, and you’ve built an interview day that actually tests for those skills…

The best interview gives you a signal as you to where the candidate spikes. A mediocre interview will let you know if someone is really bad, but it wouldn’t let good ones really shine. So, I think being very very rigorous about building the process is much much more important than, [saying], ‘I have this one gotcha question or I have this one question that teases a lot about the candidate.’"

Source: 20VC: Why Passion Is Overrated When It Comes to Starting Companies, Why VC Is Overrated as a Financing Mechanism & Why You Should Never Sell Your Company with Waseem Daher, Founder & CEO @ Pilot


Hey Waseem,

Thanks for taking the time to do this!

It’s great to see the journey of serial building that you, Jessica, and Jeff, have been on together. In an interview, you mentioned how you’ve learned to prize the process of designing an org above all. This subject has always drawn my interest, too.

As you’ve also said, and I agree, that it doesn’t matter how many great hires one has made, unless the systemic glue that brings them together is continuously refined.

With the vantage of having built three separate orgs now:

— How do you navigate the trade-offs between the pace of decentralization vs. the predictability of centralization, across different stages?
— And what were some of the early decisions at Pilot that have helped scale inter-team collaboration better?



Hey Waseem,

Glad to have you here! Really looking forward to the session.

I’ve always felt that we often ignore/misinterpret the service half of SaaS. The necessary demands that any long-run, enterprise relationship can make, no matter how great the software is.

In that regard, Pilot sits at such an interesting position with its unique human-algorithm mix. Had its origins in internal software you had built at Oracle. And in its current shape is, indeed, a service driven by software.

  • How did you come to conclude that this problem wasn’t just a software problem? Why not push the product boundaries further? I’m sure there are lessons here for all of us, as this has long remained an assumed constraint for the industry.
  • What has this model meant for scaling the business? Especially as building for a broad category like accounting, onboarding multiple verticals over time, is inherently complex even for pure-play SaaS.



Hey Waseem,

Thanks for doing this!

Being a technical founder, what were some of the misconceptions (and fears) that you had to overcome in order to run those early enterprise sales? Also, what are the two-three key steps you’d have your younger self at Ksplice, approach differently today, to build the right base for the future sales org?


Hi Waseem,

Thanks for taking timeout to do this AMA. I loved your piece around transitioning from working in the business to working on the business.

As co-founders of a bootstrapped business that now just closed a seed round, we’ll be making this transition over the coming years.

To me it feels like hitting PMF is the inflection point where you focus your energy to working “on the business”. I think this stems from not wanting to burn through investment before we have reassurance of PMF, user love and MRR going up and to the right.

In your experience what have been the key moments when these transitions start? Do you think about different streams of work differently e.g the role of the CEO on sales and CTO in development? How do you balance staying lean and frugal but not losing out on leverage?

Looking forward to hearing your thoughts!



Hey Waseem,

Thanks for taking the time to share your lessons!

You had mentioned in an interview, how you felt that Zulip’s (which remarkably preceded Slack in the group chat category) GTM execution could have been better. If you were starting out today, within a new category, what are some of the early GTM wins you’d definitely want to score?


Dear Waseem,

Thanks so much for doing this AMA with us. It was great to read about your journey thus far. Congratulations on your success.

We are kriyadocs, a document workflow automation company focused on the publishing industry. We have transitioned from a services business to a product-led services business. We believe that we have achieved PMF and are ready to scale and grow. In the true spirit of transition that you talk about, I have pulled myself out of several roles including development and operations. However, I am still heavily involved in sales and am our chief sales guy. I am currently building out our sales playbook to allow us to replicate what I do but am still struggling with the decision on when to hire a head of sales. What are your thoughts and experiences on how to manage this critical function?

I look forward to your insights.
Best regards


Hi Waseem,

Thanks for doing this.
Would love to hear your thoughts/ practices that have worked for you around org structure, goal setting and clarity for individuals in a team and creating alignment across various teams - especially at the stage when scaling the org beyond the 30-40 people.


Hey Waseem,

I’ve got another one. :slightly_smiling_face: As an extension to my previous question on scaling Pilot’s unique model, it would also be interesting to hear how difficult was it to arrive at a scalable value metric for pricing, given the complex service-software mix?


This is super-hard. The most elegant solution is: if you can keep the team as small as possible, you actually get both—you get centralized decision-making but high velocity.

I’ve always been impressed by how much a small but dedicated team can accomplish, and arguably the best strategy is “Can we figure out how to do this without having to add a bunch of heads to the team?”

Absent that, I’m a fan of Amazon/Jeff Bezos’s strategy of “Two Pizza teams” on this (a team that’s small enough that it can be fed with two pizzas): can you assemble a small team with a clear mandate and clear decision-making authority and point them at the problem?

I think the place this gets frustrating is when you get the worst of both worlds: decentralized teams that move slowly because of their significant coordination overhead (because they’re not actually empowered to do the things they need to do)


To be frank, we’re not perfect about this—but I think one of the big things that helps here is: clear goal-setting, where the person or team that is accountable to the goal is also decides how the goal is achieved. (In other words, set destinations, not routes for your teams.)

The second piece that helps is just good hygiene around communication: write down and share out decisions. We’ve had two offices (SF and Nashville) for a while, so that forced us ot get into this habit early—things that are decided in hallway conversations that aren’t shared out make it hard for teams to collaborate.


I just thought about my own experience, and the experience of business owners like me. No one has ever said “I really want to buy accounting software!” — the sentiment is “I want this problem solved for me, end-to-end.”

What we’re really in the business of selling isn’t software. It isn’t even “monthly financials.” In many ways, it’s “peace of mind knowing that Pilot is taking care of you,” and I don’t think you can get that without being willing to own the problem end-to-end.


Yes, there’s a lot of operational complexity that we have to contend with that a pure-software company doesn’t have to—so in general I don’t really recommend this approach if you can avoid it :slight_smile:

In this case, I’m not convinced it actually can be avoided, though.


Don’t underestimate your own sales ability—you’re more passionate and knowledgeable about the space you’re playing in and the product you’re building than anyone else out there.

I wrote some very tactical tips on technical-founder-led sales on Quora a while back, which I’d encourage you to take a look at if you’re curious.

Don’t try to step out of the role too soon. It’s tempting to hand off sales to someone else early, but don’t. You’ll want to do it because you want to get that unfiltered feedback from your customers and potential customers—it’ll help you improve the product!


I think about this a bit as: founder time is my scarcest resource—how can I maximally leverage it?

  • If we’re in the early days of being bootstrapped, I will just necessarily do a lot myself (because you have to). In that way, I’m converting founder time into $ saved, which is a high-leverage activity at this point in the company’s life.
  • If we’ve raised some money, the highest-leverage thing I can do is help the business grow. So if I can thoughtfully deploy dollars to buy time (especially in places where hiring the expert will do it in a higher-quality way anyway), I’ll do that
  • If we’ve started to achieve scale, the highest-leverage place for me to use my time is to help the organization work on the right things, move faster, etc. To do that, that generally means that I can’t do the thing—I have to help build the machine capable of doing the thing, and then I spend my time trying to adjust the machine.

Easier said than done, of course.


I think the challenges of Zulip were more product challenges than GTM challenges, per se—in particular:

  1. I think we could have benefited from a strong visual designer as a cofounder—the product never really popped from a UI perspective, which I think hindered its adoption

  2. Our model was really different than what people were expecting. Now, it happens to be really different in a way that’s actually much more productive—but it requires you to use the system for ~two weeks to get the hang of it, to see that that’s true.

My feeling for any new thing is that you either need to:

  • Meet your users where they are (so it’s obvious on day 1 how to use the product, and it already fits into your established workflows, etc.), OR
  • Ask the user to do something new, but demonstrate to them in the first 30 seconds why this new way of doing things is going to be much better for them than the old way of doing things.

At Zulip, we asked you to do something in a new, different way, but the payoff was fairly delayed, which was challenging.


This is absolutely one of the hardest hires to make—a good head of sales will dramatically accelerate the revenue trajectory of the company, and a bad head of sales will significantly slow your growth. So it’s definitely a high-stakes hire.

The question I’d probably ask is: is your playbook mature enough that you think you can hand it to someone and have them run with it & scale it up? Or are you constantly iterating on it?

If you’re still constantly making tweaks, what you may want is a sales manager to manage all of your sales reps, but you probably still need to stay close to the machine.


We do annual company goals and quarterly OKRs, at the company level, and then at the team level as well.

I think it’s important for everyone at the company to understand the company’s objectives, their own objectives, and the line that exists between their objectives and the company’s objectives. (In other words, does the work I do actually matter to the company?)

I think if people don’t understand the why of what they’re being asked to spend time on, you get bad results.


To be honest I still don’t think we’ve perfected this :slight_smile:

We’re probably one of the only firms in the world that can actually lose money doing bookkeeping/accounting work for our clients, which is a consequence of our flat-rate model.

Having said that, I think customers appreciate the transparency/straightforwardness of the approach.