131: Build A Remote Org On A Written Culture With Abhishek Nayak
Jun
Abhishek Nayak is the CEO and Founder of Appsmith, the first open-source, low-code platform that helps businesses with all types of custom internal applications. We discuss business models for open-source software, the steps to creating a remarkable product, and the main tenets of a solid remote culture.
—
Listen to the podcast here
Build A Remote Org On A Written Culture With Abhishek Nayak
My guest is Abhishek Nayak, CEO and Founder of Appsmith, the first open-source low-code platform that helps businesses with any customer internal application within hours. Abhishek, welcome to the show.
Thanks, Steve. Thank you so much for having me on your show. I’m excited to talk to you.
I’m very curious about some of the stuff that you guys are doing at Appsmith. Let’s start with your journey. How did you come up with this idea of Appsmith? What were you doing before? How did you get here?
Appsmith is my third startup. I’ve been an entrepreneur for the better part of the previous decade. Every single startup that I did was always with Arpit, who’s my Cofounder and CTO at Appsmith. We’ve always had to build some sort of custom applications, for example, to run customer support. I also did a gaming startup before Appsmith which is a consumer startup.
There we had to build things to manage user data, game levels and design game levels. My previous startups have ranged to be in the payment space and also the gaming space. My Cofounder, Arpit, was always responsible for building a custom tool to do customer support or run operations. That’s where the idea for Appsmith emerged.
We realized we are doing a lot of repetitive work in every single startup. It’s the same interface. You need to display some charts, maybe some data in a table and show a form so that you can modify some data. Maybe you have a workflow. Let’s say you’re a FinTech startup or a payment startup and you have a customer onboarding workflow.
You need to build an onboarding workflow, which is custom for your business. We realize all of these tools have something that is common and some things are customized. We decided to put all those common features together in a low-code open-source platform so that people don’t have to build things from scratch. That is Appsmith.
The idea of Appsmith originated from scratching my cofounder’s itch. My cofounder was the person who was always in charge of building this. He realized he doesn’t want to build stuff from scratch all the time. We should build something that helps other engineers build on top of a framework that does a lot of heavy lifting for you. That’s how we landed on Appsmith.
These modules that you’re talking about and building, are they not available before? I was under the impression that most of the new software that is being built is being modularly constructed rather than from scratch.
It depends on what kind of modularization and how much effort it still takes. For example, if you need to show some data on a chart, you need to create an API in the first place and connect to that API. You need to write the code for the charting library that you use. You might be using a charting library so you’re not writing every chart from scratch. You don’t need to figure out how to transform the data so that you can use this particular charting library or if you need to create a form, you need to write the logic for the form.
In this process, maybe about 15% to 20% is modularized. You’re not doing everything from scratch but 80% of the work is not modularized. It does take a lot of effort. Those are the bits that we are trying to convert in Appsmith so that you’re only doing 20% of the work, 80% of the work is done out of the box for you. It’s a different level of modularization and automation for the developer.
If in the past or if currently someone begins a new software, 20% of them of the components are available off the shelf. You’re going to take this 20% to 80% so that people will have to do a 20% customized or coded. That is very exciting. This is already your 3rd or 4th startup. When you create a startup, how do you find product-market fit? What are the ingredients that go into finding product-market fits? You talked about this as a framework that you have developed. Can you explain how that works and how you approach new startups?
The first thing I look for in a new startup idea is, “Am I somebody who understands the customer well or am I somebody who understands the problem well?” Maybe I’m not the customer fit but maybe I understand the problem well or I’m the customer fit. That’s the first thing. I strongly think you should solve problems that you’re fully aware of. Do not try to do something because it’s a cool idea or market.
You should solve problems that you're fully aware of. Do not try to do something because it's a cool idea or market. Click To TweetOnce you’ve crossed that hurdle, then I use a framework that I call as unique, useful and remarkable. I’m looking at the fact, “Is this idea unique? Does something like this exist in the market already? If it does exist in the market, are people aware of it?” Sometimes you have unique ideas, which nobody’s aware of and therefore you still have the chance to be unique because people aren’t aware of it.
In other cases, your idea is not unique at all. Customers are so used to using similar products or solving similar problems that they’re not excited by this. The first thing I would look for is whether your idea unique or not. I would look at the second one. Is it useful? Does it do something for the customer? I do believe there are a lot of ideas that start as unique and only over time become useful.
If you’re unique, you do have a chance of breaking out of the noise and standing out for a customer. Therefore, you might find a customer using you, even though you might not be that useful. The second step for me would be to turn it into something useful. Either solving a pain point or doing something in a way that is saving the customer money. It’s 1 of those 2 things. Either it should be making money solving a problem or saving the customer money. That’s the useful bit.
The third bit is remarkable, which is the way you execute your idea. It has to be remarkable that people talk about it. Your happy customers go on and tell other customers or other potential customers about this. A lot of products are not remarkable. They might be unique or solve something that’s critical but you don’t talk about it because it’s not remarkable or exciting to you. That’s where a lot of your growth becomes dwarfed because the word is not spreading about what you’re building.
It has to be exciting enough so that it goes viral, is what you’re saying. Let’s dissect this a little bit. How do you know if something is unique? You have an idea. Is there a way to check whether this has not been done before?
I think so. The answer might not be fully objective but if you are somebody who understands the problem space or the other options available in the market, it’s easy for you to identify if something is unique or not. You test it by pitching it to a customer. You begin to look for their expressions, the words that they say or their facial expressions, whatever you might have as a signal. All of that works to tell you if it’s unique or not.
The biggest problem arises when you enter a market that you have no idea about, where you don’t understand what the current state of the market is. What are customers already buying? What is their unhappiness or excitement about the current state of competitors? If you don’t know that, you cannot build something unique.
I do believe you have to be embedded in that environment and spend enough time for you to understand if this is unique or not. That’s hard for you to understand if you’re not embedded in the market. I see that especially in a lot of young MBA grads entering markets just because it’s big or maybe because they saw somebody else makes a lot of money in it. They have no idea about what customers are already buying and they don’t understand the customer persona well so they can’t make something that’s unique. That’s where a lot of ideas stumble.
There’s no shortcut to experience and knowledge. You’re better off digging into a market and then, trying to come up with something rather than the other way around.
Sometimes there might be a shortcut. The shortcut might be a specific experience that you went through. Maybe that experience lasted for a couple of days. Maybe you had an incredible experience in a foreign country or a particular way by which somebody was selling you something. You realize that this can be applied somewhere else. I do believe there’s that cross-pollination and cross-connection of ideas that emerge. With all of this, there is a possibility for you to provide a unique spin to something.
Either you are embedded in an area that you understand and then you realize something is missing. You stumble up or you have an experience. You think maybe this has not been solved and you have to do research. You do a focus group in that industry and try to see if other people have not seen something like that, then you can hone in on the uniqueness of it. What about remarkable? Is there a process to make a digital product or a software product remarkable or is it more an art than science?
This is a mix of art and science. The science bit is a lot simpler to talk about. You do something remarkable when customers have not experienced that before. It could be amazing customer service or the ease of buying and using something. In every single thing that we experience, there’s something that’s lacking, which prevents us from talking about it. Sometimes it’s solving one thing that provides a very remarkable experience to customers and developers.
In Appsmith’s case, for example, one of the biggest reasons why we get word-of-mouth virality is because 1) We are open-source. 2) Our customer support is great. It’s both of these things together. There are a lot of open-source projects in which we’d see a lot of activity but they don’t get support quickly enough. On the other hand, you have a lot of small open-source projects that are able to provide great customer support but they’re not that popular.
In the case of Appsmith, we have both working for us. It’s an open-source project that’s popular but we also provide incredibly good developer support through our documentation, videos and community forums. In the early days, it was a little bit slow. People didn’t see this as remarkable. In 2 out of 5 conversations that I have, people tell us how they were blown away by the velocity of responses that they got and the amount of material that is out there to use Appsmith.
That to them was remarkable. That’s what they talk about when they tell their friends about it. That’s something that we noticed. Providing great support sounds like a simple thing but doing it at scale is extremely complicated and quite cumbersome. We’ve spent a lot of time figuring that out and that is becoming a remarkable feature for Appsmith.
Let’s talk about the idea and the business model of open-source. How does it work? How do you create an open-source business model? How do you monetize it?
Open-source, by definition, means that your software source code is available to anybody and they can do whatever they want with it. If they want, they can modify it, resell it or put on their logo on it and start a whole different company around it. The core concept of open-source is that the source is available to developers to modify and change.
In the case of Appsmith, our code project is open-source, which means anybody can take it and do something with it. This also means that customers or potential customers. They don’t have the incentive to pay Appsmith any money. The way we tackle that is by ensuring that we have a certain set of features that are only available in our enterprise edition, which only matter to a very large organization.
We believe 80% to 85% of our users will never pay us money and that’s fine. Anywhere from 5% to 10% of our users do have features and needs that cannot be addressed by the open-source project. That’s what we charge them for. These are things like security-related features. These are features around reliability and scalability.
These could even be custom support because they’re a very large company. They need support SLAs, which we cannot provide in our community edition. We then provide that for a fee. Traditionally, open-source organizations monetize in a couple of ways. The first method is by providing support. That’s something we do at Appsmith but not a lot of it.
The second thing that they might do is provide a hosted service where they charge you for the cloud-hosted edition of the open-source service. This is something that we don’t do at Appsmith, at least not yet but I know a lot of open-source projects do charge for hosting. The third common thing is to provide enterprise features that are not available in the open-source edition. This is how GitLab and Appsmith monetize most customers.
Does it mean that there’s a very long period of incubation when the business is not making money? You have to build up the audience and they have to start using it. It’s going to take some time to get it to the enterprise level and for them to need these extra services. How do you fund that? It sounds like it’s impossible to bootstrap a business like that.
It depends on how quickly your open-source project takes off. In a lot of open-source project cases, it does require a lot of incubation time. That’s why open-source projects generally start with 1 or 2 engineers who work on it part-time for 6 months or maybe 2 years. Only after that, do they go in full-time once there is a sizable mass of users that are using it.
In the case of Appsmith, it did take us a whole year before we could launch the project. Our first enterprise feature request came in about six months after we had launched the project. For us, that was relatively quicker but I do know for a lot of companies it does take a long time. Even in Appsmith’s case, it did take us a good one and a half years after launching the project to make the first revenue. In our case, we were funded by our seed-stage investors so we could continue doing it for a little bit longer. That’s how we funded it. In other cases, I do know people do it part-time as an engineer or people who self-funded by providing a support contract or by providing consulting services on top of it.
What’s unique about this product is that you’re selling it to the engineers themselves who are doing the programming and the coding. Are they difficult buyers to please? How is it different to sell something to an engineer rather than a business owner or a C-level executive?
There are a couple of things that make it easy to sell to developers and a couple of things that make it incredibly hard to sell to developers. Let me cover the bits that make it easy to sell to developers. 1) Developers are online all the time and they will research every single thing about your product before they come to you and ask you for help.
Developers are always online and will research every single thing about your product before they come to you and ask you for help. Click To TweetDevelopers love to do things on their own for as much as possible without talking to a support person or a salesperson. This I love about developers because every time I do a sales call with an engineering team, they’re very well-informed about Appsmith and they understand how it works. They wouldn’t spend a couple of hours on it before we have a conversation with them.
2) Developers are always open to trying out a new product because every single day their job depends on innovation and doing something different that they weren’t doing a year ago. They’re always looking for new tools and libraries. If not all the developers, at least 15% to 20% of the developers are always looking for a new tool. It’s very possible for you to put a new product in front of them and get them to try it and give you feedback about it. They’re always looking for something new and trying to save time.
3) They’re willing to wear your brand on their body. They’ll happily wear a free T-shirt because they like the T-shirt or they like your product. I love that because it’s like free marketing for your product. Developers are some of the highest-paid people in the world and they’re willing to wear a free T-shirt. That’s a silly small thing but I love the fact that they’re so happy to use other people’s swag. That’s something that I like.
Some things make it hard to sell to developers. 1) They have a very high bar for quality. They might try your product but if the quality isn’t that high, they’re going to throw the product away very quickly. Even if they’ve spent a couple of hours on it, they’re not willing to invest more than that because they have a higher bar for quality.
2) When they need help, they expect sophisticated help. They expect help that is above and beyond an average customer support person. The kind of support that they expect gently is expected from other engineers. Supporting a developer who’s been using your product for a long time is quite expensive because you need to have a very sharp engineer supporting that developer. It’s not a low-cost service that you can provide to them.
3) For you to charge them, you need to be providing something that they cannot already do for free. If there is a way for them to achieve something for free and there isn’t that much time-related cost associated with it, they’re going to go find that free service. They’re not necessarily going to go pay for it just because it’s a lot more convenient. They don’t tend to do that. You need to be able to provide something which they cannot get anywhere else. Only then, they’re willing to pay you.
Very high maintenance but well-informed customers, the developers are. That’s fascinating. Switching gears here a little bit. Your business is remote. You explained to me you have 100 employees. Some of your employees are in twenty different countries you never meet in person. How do you create, maintain and develop a culture when it’s remote and people never see each other?
Our team is about 120 people. We did an offsite where there were about 90 people. That was the first time we all got together for a few days and met each other face-to-face. The majority of the time, we’ve never met each other and all our work remotely. For you to run a remote organization, as a leader, you have to have multiple processes in place but you also need to ensure there’s a lot of flexibility and freedom available to your team.
That’s why there’s a balancing act where you need to have some clear rules and some principles in place but you also need to ensure that there is flexibility around those rules so people can take decisions for themselves when they run into a conflict. In a situation where there are multiple right answers, they should have the principles in their mind so that they can take the right decision. These principles need to be communicated in a written form repeatedly.
This leads to the second management principle. As a leader, you have to write down everything essential. You cannot depend on one-way communication, which is broadcasted through a visual medium. It has to be written down and people should be able to read it without attending a call with you. If you do not write it down, then it’s not important to your organization.
As a leader, you have to write down everything essential and important. If you do not write it down, it's not important to your organization. Click To TweetIf you do write it down, it means you can use that as a way of spreading knowledge and the principles and beliefs that you have. I communicate everything and am open. I communicate using notion docs or Slack. If it’s important, then it is done using Notion, Slack and a video call but it is rarely done only through a video call.
If it’s a video call, some people might miss it or other people might skip forward the recording so, therefore, they miss the important points. Therefore, I use a written return document as well as a video to communicate things. This is about how I communicate as a leader. For the rest of the organization, you need to have people who are proactive communicators, people who ask for help and people who write well.
If you don’t have people who proactively communicate or ask for help, it’s difficult for you to run a remote organization. You have to keep repeating this point and also train your team a little bit. Expose them to resources and training materials that tell them how to write and communicate better. All of this leads to a much smoother functioning of a remote organization.
That’s very interesting the way you explain it. I always thought that people don’t always read things. One of the reasons why speaking is more effective is that people are more likely to absorb something when it comes from a person who is speaking to them. Rather than when it’s the core letters and a piece of paper.
A guest on this show talked about how writing and reading is not natural way to communicate. It surprises me that for you it’s very effective. Is this because the developers are more apt to reading stuff? Maybe you have more introverted employees who are the engineer brain that is very precise and looking for the exact meaning of things. Do you think this has something to do with that?
I don’t think so. At the very start, we did have a problem with this. We were moving from a meeting culture to a written culture or a documentation-first culture. It was painful for us to get people to read everything. We realized it does require discipline in how you communicate it. You have to keep reinforcing the fact that everything is available in the written medium.
Sometimes in our meetings, we do give time to people to read our document at the very start of the meeting and only then do we continue with the meeting. It’s a bunch of different ways. I wouldn’t say we fully solved it but after having used the written medium a lot more in the last years versus before when I always used to do meetings or video calls, I do believe the written medium is better to provide clarity.
It’s not the best medium for you to have a discussion. That I agree. For a discussion or a brainstorming session, it still makes sense for you to do it synchronously. The written medium is great for you to communicate ideas with clarity and conviction. It’s a low-fidelity method of communication versus a video call. You’re forced to focus on the most essential points and refine your arguments in a way that makes sense.
I like that concept. Essentially, this is why people read books because you cannot write a book by glossing over ideas. You have to be precise and think through what you’re writing. It is a much more reliable medium. In speaking, you can use your charisma, magnetism and other nonverbal communication abilities to maximize the audience and essentially gloss over stuff. Wrapping this conversation up, what can you offer to our audience? What do you suggest they do after reading?
A couple of things. The first one would be, if you’re thinking about working or hiring remotely, you have to realize that it’s a little bit different than you were managing before and it is very possible to do it. It’s going to be very painful for a leader at the start but there are real behavioral changes that you need to bring for you to succeed. You cannot expect that translation to happen. Once you start working remotely, you realize the entire world is your oyster. You can hire the very best people at the budget that you have or at the cost that you can afford. You don’t have to compromise. That’s been incredible.
The second thing I would suggest is if you’re running a growing business and struggling to get engineers to build something essential for your business, you should take a look at Appsmith. Appsmith might be able to solve that problem. Send a link to your engineers and they will be able to use it for building something very quickly. Something that might have taken you a few months, you’ll get done in 1 day or 2. It’s a general-purpose tool so you will find some used cases for it and you should try that out.
That’s a great suggestion. I’m going to do that as well. I have a developer who develops all of my front-end stuff. I will send it to her, let her check it out and maybe accelerate things. Abhishek, thank you very much for coming to the show. Thanks for sharing your unique knowledge.
Thanks, Steve.
