Airplane’s Ravi Parikh on Picking the Right Problem and Market to Succeed

Ravi Parikh is a Cofounder of Airplane, a developer platform for internal tools. With an engineering background, Ravi started Heap in 2013. After noticing repetitive customer pain points at Heap, Ravi teamed up with Joshua Ma to uncover a structured way to deal with these issues. Ravi and Josh founded Airplane in 2020 and have seen exponential growth in just three years since launching by building a solution that preempts “bandaid solutions that result in big bottlenecks.”

I sat down with Ravi to discuss Airplane, figuring out the right problems to solve, and staying close to customers through a cross-pollination of roles.

Let’s start with your journey and how it led you to Airplane.

Prior to starting Airplane, I cofounded an analytics company called Heap. We started Heap in 2013, went through Y Combinator, and spent the first couple of years building out the product.

Once we started scaling and getting traction, I shifted my efforts to go-to-market. I managed sales, marketing, customer success, support, and back office. Basically, everything that wasn't product. I did that for most of my next five or six years at Heap.

When the company reached about 200 people, I left and started Airplane. A lot of the motivation behind Airplane was due to the pain points I felt every day at Heap.

Heap is an analytics product, a data product, and also an enterprise software. Our customers would often have requests such as "Hey, I implemented the API wrong and I need you to delete the data in this environment." Or, "I accidentally split my data into two different environments, can you combine them together?"

These requests would come up on a daily basis. In some cases, it made sense to turn those into product features, but you usually didn't want a button in the account called "delete all the data" or anything like that. Most of these one-off operations became things that our solutions engineering team would have to escalate to the backend team and then the backend engineering team would have to run a query or script.

Over time, we accumulated 70 to 80 of these scripts and repetitive queries. These bandaid solutions to common customer operations were issues that resulted in big bottlenecks where engineering was constantly being dragged in to solve customer problems. It resulted in situations where customer-facing employees felt disempowered to solve customer problems themselves.

That was an ongoing pain point during my time at Heap. I wanted to find out if I could build a more structured, elegant way of dealing with these issues. I was brainstorming with a friend of mine named Josh and he had a similar journey to me. He was the CTO of a company called Benchling.

Josh was at Benchling the same seven or eight years that I was at Heap and helped scale its engineering team up to a pretty large size. He also saw very similar problems where his team was impacted by daily one-off customer requests.

We realized that if this was a problem at both of our companies, it was probably a problem in other places.

Talk to me about your first customer.

Our first customer was a startup called Dover, but it's actually my wife's startup. So definitely had a little bit of a home-field advantage. I'm not going to pretend it was a totally cold outbound or something of that nature.

They're a recruiting tech startup. If you're hiring people and you have a software engineering role open, they will handle the sourcing, the meeting scheduling, and all of that via software. As a result, every time they onboarded a new customer or a new role, they had a lot of people on the engineering team doing one-off scripts or database queries to get that new role in the right shape and configure it in the right ways.

They hadn't built some internal workflows or tools to do that automatically, so the engineering team was involved every time. We used Airplane to get a lot of those scripts into a UI that could allow their customer operations team to autonomously trigger those actions and onboard customers themselves.

How did you continue to grow? How’s business going now?

So we started working on Airplane in December 2020. We onboarded Dover about a month later with just an MVP product. We actually didn't get another customer for several more months. The reason was, I think, the way Dover had written their scripts. The way their infrastructure was built made it really, really easy for them to use the first version of Airplane.

Everybody else we pitched a product to was like, "This is really cool, I want to try it." But then they would take five hours trying to onboard onto it and fail.

If something takes you a lot of time and effort to spin up, in some sense, it's not worth it. It's not worth the activation energy. A lot of the value we're selling was not just automation, it was the speed of solving that problem. We spent a lot of time realizing that and then we spent a lot of time making that onboarding process really smooth.

Once we had iterated through that, we were at a point where if you were using Modern Infrastructure, JavaScript, or Python, you could onboard onto Airplane in a few minutes. We were then able to get a handful of other customers, people who we weren't necessarily affiliated with, which was good. Then we launched the product about a month after that.

Since then, we've just gotten steady traction and growth. The product offering has expanded and now supports multi-step complicated workflows and UI built-ins. We've become much more of a full-featured kind of tooling platform. The company as a whole has grown to about 20 people now. We've raised a couple of rounds of funding and we have our fair share of customers.

What are the things that you feel you've gotten right to have this level of success?

Picking the right market is the number one thing you have to get right.

What's the market that you would put Airplane in?

I think with Airplane, we get lumped into that low-code/no-code market. I actually think that whole low-code/no-code thing is not going to last. I think it's going to get squeezed out a little bit.

I think you're going to have software like Airtable that does really well because it's meant to replace the application layer. You're like, "Oh, I can use Airtable as my ATS or my CRM or something in a lightweight way." That works really well. And then for first-party internal tools you're going to have Airplane, which is very much a developer platform to write code faster, that's going to work well. I don't think the middle stuff–it’s somewhat code-based but it’s also not a full developer platform–is going to work so well.

So what market are we in? I'm not really sure, but I think of Airplane as really accelerating software development and developer productivity.

What is your biggest piece of advice for other entrepreneurs?

Pick the right problem. One that happens to affect a lot of people, and a lot of businesses and is solvable in a relatively general way.

How are you guys growing?

Almost all of our business has been mostly organic via word of mouth.

We did a couple of product launches last year and got a few bursts of leads from Product Hunt and Hacker News. Then you get that steady trickle of two or three sign-ups a day and that two or three becomes five, which becomes 10, which becomes 20. That’s just kind of trickled up over the last year.

Talk to me about customer-centricity and getting the product right.

I don't think there's any one magic formula. I think some things are really easy to miss. I think usually you build a product, a product like Airplane, you build out of a personal pain point. You build it for yourself, use it in-house, and have a sense of how it should work.

I think that you have to apply a first principles mindset to it. I don't think you can purely rely on customer feedback to find your way to product market fit. I think you have to actually just have a point of view of this is the problem we're trying to solve and here's what I think would be the best solution. I think people can tell you their problems, but they can't tell you how to solve them.

How do you stay close to the customer?

My role is mostly on the go-to-market side at Airplane. My cofounder's role is CTO and he's more focused on product and engineering. Both of us try to do everything though. A big mistake my cofounder and I made at Heap was that we had too much of a separation of responsibilities. There weren't a lot of avenues for cross-pollination among the teams.

At Airplane, we don't have a dedicated support team right now. Our engineering team does a support rotation as part of their on-call and it can get burdensome and annoying, but it does mean there's a constant direct stream of feedback from customers going back into the engineering side of the organization. Quite a lot of people from the engineering team along with my cofounder and I, join sales conversations, customer success conversations, and customer syncs.

I think we also try to build a culture of sharing things very actively within the company. If an interesting customer call happens, we encourage going into Slack, posting the timestamp of the interesting part of the call recording, and sharing the cool thing they highlighted.