Built to Share: 2M Users in 18 Months | Julius AI, Rahul Sonwalkar

1. 0:00 – 0:45

   Intro

   1. RSRahul Sonwalkar0:00

      I quit my job, and then it took a year and a half for me to launch Julius after that. When I, when I went all in, I was nervous. To be honest, I was scared. But it's, being a little scared is good. I think fear is good. You know, it keeps you sharp. It keeps you on your toes. You're able to see through things. When you're in a comfortable place, it, it breeds com- complacency, and you're al- often, you know, fooling yourself into believing that your ideas are gonna work one day. But then when all the bridges are burned, and you really have to make a thing work, you start thinking, you start taking risks, taking shots at goal. But having no other boats, you know, lifeboats, it, it was a little scary, but I think it was good. I'm Rahul,

2. 0:45 – 1:17

   About Julius AI

   1. RSRahul Sonwalkar0:45

      founder and CEO of Julius AI. Julius is an AI data analyst. If you have data on your hands, Julius will help you get insights from your data within seconds, and help you make charts and data visualizations. Since launching in 2023, our users have used Julius to make over 10 million data visualizations. Every day, Julius writes over 4 million lines of analysis code. 4 million lines of code is more than an army of data scientists can write every day. It took about a year and a half to get to 2 million users. [keyboard clacking]

3. 1:17 – 2:51

   Rule No.1 Focus on only one task

   1. RSRahul Sonwalkar1:22

      For AI startups, I'll say focus. Don't build a general purpose tool. Startups win because of focus. That's the only advantage you have as a startup. Now, ChatGPT is this, like, all-in-one tool, making videos, making images, doing internet search, writing essays, and it's just all-in-one tool, and it's not focused on data analysis, so the experience is much worse. A lot of our users, they start with using ChatGPT, and they realize that to analyze any kind of real data to get any kind of meaningful insights, ChatGPT falls short. The quality of insights you get aren't that deep. It cannot handle any kind of real data. The charts don't look good. You can't collaborate with your colleagues on the analysis. So all these problems people run into after using it for a day for analysis, and they all go to Google, and they look up AI data analysis, and the number one search result on Google for that is Julius. It's kind of like, think about hiring humans. Would you wanna hire one human that can do everything? You, you can't. And that will help you get decent results, but then there comes a point where you want someone with deep expertise, someone who's really, really good at one function, like a marketer, finance profe- finance person, an engineer. I think focus agents for a task have much more competitive advantage than, like, the general purpose agent. You

4. 2:51 – 4:22

   Rule No.2 Solve daily problems that matter

   1. RSRahul Sonwalkar2:54

      know, there's this, like, conventional meme, like, "Google just killed your startup. OpenAI just killed your startup. XYZ just killed this all startup." I think all that is very overblown. As long as your users don't care about that stuff, it shouldn't matter. If you're building something that solves a problem for people, if you're doing that, good job at that better than everyone else, that all, that's all that matters. So this is back in college when I got into the hackathon scene. I would go to these hackathons. The big problem I noticed is you have 48 hours to build and launch an idea. A lot of the time people would spend on setting up a backend service, setting up their database, and I thought that was a waste of time. So Waterview was this, you know, managed service. You would get out of box, like, a backend server or database that just kind of worked. It got a lot of users, and I would go to ha- go to these hackathons, give it to people, and they would try it. It would save them time. But problem was none of the people that built their hackathon projects, their weekend projects on Waterview, continued to work on those projects after that weekend. You know, it was like a weekend thing. The big lesson there was you can solve the right problem, you can solve a pain point for people, but if they don't have that pain point daily or weekly, they're not gonna retain. They're not gonna come back to the product. You have a s- you have to solve a problem people have. If they have it only once a year or once every six months or once a month, they're not gonna retain to your product. That's the reason Waterview failed, and that was a very valuable lesson.

5. 4:22 – 6:08

   Rule No.3 One ‘NO’ kills an idea

   1. RSRahul Sonwalkar4:25

      I worked as an engineer at Uber and Facebook. When you're at a big company and you have an idea, one "no" can kill that idea. You get a "yes" from your manager. You have to get a "yes" from your manager's manager, design manager, product manager. You have to get all these yeses, and even one "no" can kill your idea. So innovation doesn't really happen in big companies. And then at a startup, it's complete opposite. All you need is one "yes." Looking for customers, you know, you can get 50 nos, but one yes, your first customer, that's all that matters. Instead of one "no" killing your idea, one "yes" can really make your company work. So one of the problems I was trying to solve at Uber is people book Uber rides usually for things that they can't drive to, like, uh, like an airport or from an airport or when they're out going out at night to bars or restaurants. That sporadic usage is not good for Uber. One of the things I wanted to solve for was how could we get people to use Uber on a daily and weekly basis? So I wanted to launch this commuter product at Uber. How can we help people use, you know, Uber's offerings, Uber Transit, Uber X, Uber, um, Uber Mobility, like bikes and scooters, all that as a part of a commuter package that companies could offer their employees? So in order to pitch that idea, I was pushing it really, really hard, and, you know, I got buy-in from a lot of cross-functional management. I couldn't get buy-in from our, um, engineering leader, and I couldn't get buy-in from the engineering leader and that crushed the idea. But at the same time, I was building apps and different ideas on the side on the weekends, and that motivated me to just, like, quit my job and spend a year exploring my ideas full-time.

6. 6:08 – 7:46

   Rule No.4 Failing Fast

   1. RSRahul Sonwalkar6:11

      Every failure is, is, is good. Failing is good because you know what's, what's not working. I, I, I talk to founders and they, they're too scared to launch, too scared to tell people what their idea is. They're too scared to put the product out there. I'm the opposite. You know, at Julius, we launch things when they're barely working because we want to get early feedback from our users, from our customers. We want them to try it out. We want to learn from our users and customers on what they actually want and how the things should work. So I'll give you one of the examples. We were building in, you know, data and AI and insights, and we thought, you know, one of the, one of the group of people that want insights from data but don't have the expertise to go do data science on their own is, is sports fans. We built this thing called NBA GPT. It was called Hoops GPT. It would help you query NBA data, play-by-play data by just asking simple questions. We had to build the UI, the interface, figure out how this text to querying engine is gonna work, and ship the whole thing in, like, two weeks because if we were too late, the NBA season would be over. There was no point to wait a year to try the idea again. And turns out, like, sports fans aren't that savvy about data. Turns out it's only the people that want to do betting. They really aren't the users you want to serve. So we learn very quickly, know whether it's something people want or don't want. We don't want to build something that no one will ever want to use. I think failing is important. Failing fast is really, really important. Paul Graham talks about this in his essays all the time. It's like failing fast is super important.

7. 7:46 – 9:58

   Rule No.5 Build products people share

   1. RSRahul Sonwalkar7:46

      This is months after launching Julius. We had about 10,000 to 15,000 users, and most of our users at that point were actually coming from ChatGPT. ChatGPT had this plugin store where users would discover Julius, and they would come to Julius, stay with Julius, and use Julius over and over. And it was going great. It was going great. We're growing. Overnight, OpenAI announces that the plugin store is gonna get shut down, and our biggest source of users disappeared overnight. So we had to scramble and figure out how we were gonna get more users and where we were gonna get users from. So that was an existential moment, and that is what really got us to move fast and figure out, "Okay, how do we get our users to become champions of Julius?" Then we realized that when people analyze data, they want to tell their colleagues about it. When you get an insight, you don't keep it to yourself. You want to tell your colleagues. You want to tell your team. And so we built sharing into the product. If you solve a problem that people have, they will come to you. They'll come to you, and they will use your product, and they'll tell their friends about it. So word of mouth is a free way to grow your product. If I were to start Julius from scratch today, what would I do differently? Nothing. I think, you know, all the things I, I would consider as, like, missteps, things, um, I could have avoided, I think those are valuable lessons. You know, all the features we tried and didn't work out, all that is really valuable lesson. That's helpful data. You can-- If you have only data from successes, then that's very skewed. You don't know what doesn't work. So it's really important to try a lot of things. Things that don't work are also important because now you know what doesn't work. Honestly, like, I would not do anything differently. [outro music]

Episode duration: 9:59