Winning with open and closed source products | Neha Narkhede (Co-founder at Confluent and Oscilar)

Brett: let's get into it. Thanks so much for joining us.

Neha: Thank you for having me. Really excited about this.

Brett: Maybe we could start by actually talking about the Kafka story and how that kind of got off the ground when you were at LinkedIn. And then we'll use that to sort of talk about sort of the insight for Confluent. 

Neha: Yeah, you know, at LinkedIn when I was there, along with my two co founders, LinkedIn was, facing a big problem in the sense that, we were building a lot of, real time features for our users. At the same time, we were building a lot of offline analytics, kind of products to help power some of those features as well.

So we had like two worlds that were not speaking to each other. One was, you know, the real time apps, the other was Hadoop and the backend infrastructure. And things were breaking all the time. You know, there was a messaging system that wouldn't scale that was supporting the online apps.

There was a completely different system supporting the offline apps. So really what we needed was a scalable data streaming platform that would enable sort of merging both of these worlds and have one system that could move data from one place to the other. And Process data on top of that in a very real time fashion as well as support offline applications.

So we, we actually began by researching the market to see if anyone had built something like that. So definitely wasn't the preference to build Apache Kafka, but when we realized that nothing else existed, we decided to take the leap and start Apache Kafka open sourced it when it was about three years in.

And then it just took off, in the years to come. That's what led to Confluent.

Brett: what made you sort of decide to open source it?

Neha: Yeah, that's a great question. So, the first reason was that we saw it as a foundational technology. So it is the heart and soul of data. in a company and in order for it to become, you know, successful out in the world, which was, you know, one of our ambitions, it needed to be open source because developers like foundational technologies to be open source that they can take, tweak.

Contribute to and so on. So that was one of the reasons. The second reason is open source just makes, product much more, you know, easier to use better because a whole community of developers contribute to it. So that was sort of the third reason and second reason. And the third one was, you know, we just believe that nothing else existed like Apache Kafka.

And for the rest of the companies to benefit from this, it needed to be open source. So those were some of the reasons that sort of came to mind and we open sourced it under the Apache Software Foundation. So it was, you know, independently governed. That I think played a role in its overall success.

Brett: But you, you open sourced before you decided you were going to build a commercial company around it? 

Neha: Yeah, well before that. So this  confluence started four years after Apache Kafka was open sourced and became successful and it was very much an organic decision.

Brett: And so when you were using it as as internal infrastructure, what, what was the main benefit when you were using it? Just internally. The desire to let other people leverage it.

Neha: It was a couple of different use cases, right? One was, for it to function as a logging system, and that meant, for it to be a data pipe to our offline systems, which, you know, used to break before Apache Kafka quite often. The other one was supporting stream processing capabilities.

So processing real time data that comes from our real time applications. Like people you may know or who viewed your profile and so on. And then enabling sort of, you know, merging both of these worlds to create like an, you know, a central nervous system for LinkedIn to tap into build any new application with just one API call.

That was sort of the way LinkedIn was using it. And if you generalize it, you know, all the digital companies need this is they all have consumer facing applications. They all have backend systems and really they all need a single view of the data and flexibility to use it in real time or batch. that is how we envisioned Apache Kafka.

And that is you know, exactly how it's still used.

Brett: What was the first version of Kafka long before it was open sourced? Like what was the first iteration of the product?

Neha: So the first iteration was, very much, influenced by the first use case that we wanted to tackle, which was making messaging systems much more scalable. And that was because the, incumbent messaging systems were simply not designed for internet scale data. And so we, you know, kept it pretty simple.

We had a publish API and a subscribe API, and it just was simpler, more scalable. you know, Apache Kafka initially was just a, you know, much more scalable pub sub system. All the rest of the functionality came after that.

Brett: Once you open sourced it, why do you think it took off in the way that it did? 

Neha: I think the first reason is that companies were getting, digitized. So there was a lot of, you know, data that needed to be. I tapped into, harvested, built applications around, and there was no existing system that was capable of scaling. The second reason is that, we drastically simplified the API calls and the user interface.

And we made it like really, really simple to get started with, get, you know, use it within any application. So the user experience was also a big part of it. I, I think that the scalability and user experience were really two big reasons why Kafka succeeded in addition to its differentiation, and it's conceptualization as a very different sort of database like system.

Brett: Before you open sourced it, did you think it would take off in the way that it did, or you just thought, eh, it would be nice to put it out in the world and other people might be able to use this?

Neha: Yeah, we just thought, you know, we'll put it out in the world and, tech companies like LinkedIn would use it, you know, Silicon Valley tech companies that are, technology forward. But it turned out that big enterprises started using it to a point where we started getting calls from big enterprises to sort of consult with them and help them with their Kafka deployments.

And that was sort of the, first time I thought that there should be a company around Apache Kafka that, you know, creates enterprise products and that can be adopted for large companies as well as the smaller companies alike

Brett: Did you have to do a lot of work to get the product ready to be open sourced? Or It was set up in a way that it was relatively easy to open source?

Neha: It was set up in a way from the get go for it to be really easy. To open sources. So the way we designed it, the way, you know, the UX was designed the way it overall worked as a very modular system made it very, very easy to open source it. And, you know, I think the best open source technologies are used in production.

for, you know, major applications. And that's what makes for a more successful open source system. So I'm glad that we waited for Kafka to be used for practical applications in a stable manner before it was open source. So the first experience people had with the product was really small.

Brett: is one of the insights there that in this case. You built something to solve your own problem and you as a company were representative of lots of other companies because it, it obviously was started not thinking about thousands or hundreds of organizations using it. And it kind of led into this interesting sort of cascading events, which is often very different than a normal sort of enterprise software company where you think about some use case, you go build a closed source product, you get maybe design partners, et cetera, et cetera.

Neha: Yeah, I think there were two reasons why, it was successful. I think one is technology differentiation, which seems pretty obvious, you know, it solved an important problem. But the second one was that there were market tailwinds, you know, there were companies that were collecting data at a much larger scale, almost 10x scale, and they needed something like this.

So there was a timing. And an opportunity part to it in addition to a technology part to it.

Brett: What, what was sort of the, the more detailed version of how you went from the successful open source project to going and starting a company?

Neha: Yeah, I think the inception of Confluent is pretty unique, you know, especially when it, when compared to a typical journey of many startups, right? Confluence roots lie in Apache Kafka, which, was a real time, you know, today even is a really popular open source system. So the zero to one phase for Confluent was really distinct in several ways. The first is a starting point. So unlike conventional startups, like you said, that begin with an idea, then seek validation. Confluent kind of started with a proven technology that was used at, you know, roughly 50 percent of Fortune 500 companies at that point in time. So we had a vast community to kind of tap into to commercialize.

And that is a very different starting point. The second thing validation I think the validation for Confluent wasn't about the core technology, and we believe that that was one of the reasons why the timing was right. But instead, the validation was actually about understanding the gaps in the Kafka ecosystem, identifying how Confluent could provide solutions to make Kafka more accessible

manageable and extensible. So our strategy was very much, you know, focusing on the existing user base. Kafka had a broad user base. So our initial focus was, hey, how can we help existing Kafka users through operational tools, connectivity to different systems in production, support and training. So we put a lot of thought into that.

you know, that really dictated the product direction. And last but not the least community engagement. We put a lot of thought, you know, Kafka became successful also because of the developer evangelism and how we, encourage developers to think differently, not just use a different system.

So that was also a significant part of the zero to one phase, for the Kafka community and Confluent.

Brett: Was it an easy decision to go start an actual company once Kafka started to take off, or was that more of a winding journey? So you

Neha: the decision was, it sort of looked like this, you know, I was in a meeting with my co founder, we were helping a fortune 500 company with some of their Kafka problems in production. And while my co founders asked, you know, answering some question, I just sort of was. Thinking, Hey, you know, if there was a company around Kafka, which there will be, it will, you know, be really sad that, the Kafka co founders or co creators did not create it.

And so that's when I pitched this idea to my co founders is that, hey, let's reduce our regrets and try to do this. And, that was a pretty. easy decision because, you know, we had the context around the product. We, the product was adopted very, very, broadly. And so we, we were starting from a very strong position.

Brett: I'd love to hear more detail around how you figured out where you would start to build. and for what type of customer and what type of use cases to build sort of the first version that ultimately became confluent.

Neha: Yeah. So over time, Confluent has expanded its offerings, adding more features, tools, a managed service to enhance the Kafka ecosystem, which is a whole different discussion. But the MVP was fundamentally about making Kafka more accessible, manageable, extensible for businesses. So Confluence MVP in a sense was built around the foundational capabilities of Apache Kafka.

And we invested in three areas. The first one was operational ease. You know, offering tools and enhancements to simplify the deployment management and scaling of kaf clusters, which is actually the, I think, the right, starting point for many open source companies. The second was data integration.

You know, it was meant to move data around. It was meant to connect systems, so we provided connectors out of the box that would allow you to connect your production systems. And the third was more strategic, which is we didn't want Kafka to be a just a data pipe. We wanted it to become that central nervous system.

So we introduced stream processing capabilities that could use Kafka as a foundation, but then allow you to, you know, process data in many different ways in real time. So we very much focused around the current Kafka user base and what they needed both from an open source perspective, as well as from an enterprise perspective.

Brett: Can you share more about the process by which you landed on those three pillars of the first version of the product?

Neha: Yeah. You know, we paid a lot of attention to, feedback from our community. So that sort of influenced a lot of the open source investments around stream processing in particular. We also did a lot of, research with, you know, commercial users. So potential commercial users, the large companies, and that was sort of, you know, that is what influenced the investment in.

tooling around operational ease, confluent, you know, in the, in those days, many enterprises were still on, premises. And so we had to offer a software product and later on, we complimented it with a SaaS offering, so very much, you know, was influenced by user-centricity

Brett: Did you think about building for a very specific customer type at the beginning and then kind of build outwards or the roadmap in the early version of the product? The goal was to be extensible, whether you were a hundred person Silicon Valley company or a bank in New York or whomever.

Neha: Yeah, you know, early days we thought all about foundational investments. You know, whether you were a small startup, whether you were a midsize or large company. We believed that these were foundational capabilities. that Kafka needs because those are the use cases. So we focused a lot on use cases and, you know, then came up with this common sort of denominator and said, okay, these are capabilities that must be present for an open source developer to start with it, and these are the capabilities that must be present for a production grade enterprise deployment.

So we, you know, overall, we were very much, you know, we still are very first principles thinking, very foundational thinking.

Brett: Why did that make sense as opposed to, you know, these 20 banks want this specific set of features and let's sort of start there and then we'll build for, you know, the next ICP and the next ICP?

Neha: Yeah, that was a, actually that was a challenge for, Kafka and Confluent because, it is a foundational system. So it got used for all sorts of use cases, you know, at all sorts of companies. So, Kafka, you know, that was one of the reasons why we couldn't, or we didn't sort of narrowly focus on an ICP like traditional companies do for good reason.

It was because, you know, the Kafka adoption base was so broad and for Confluent to quickly, convert those users into commercial users was so important that we used this sort of foundational approach to do that as quickly as possible because, you know, frankly, any company could come into the space and do the same.

So we very much went broad before we went deep.

Brett: when you had the first version of Confluent built, did you just put it out in the world or did you do it some sort of design partnership or what was the rollout?

Neha: The roller was very much, you know, just. put it out in the world, and leverage sort of our evangelism strengths to drive adoption of those products. And that made sense because a good part of it was actually open source. So it made sense for us to, you know, open source it and just put it out there. The second reason why this made sense was because we had years of experience building the community and building the product or the core product. And so there was a lot of conviction around the early, You know, product vision and the product direction. So it made a lot of sense for us to just put it out there and drive adoption.

And that is, you know, that turned out to be the right approach for us.

Brett: Did it instantly start working?

Neha: Actually, yes, the MVP instantly started working and, you know, around the stream processing capabilities that over the years became a core strength of the Kafka ecosystem, and especially confluence offerings. And the operational ease tooling was so fundamental to any enterprises adoption that it just sort of worked out of the box.

It, it then evolved over a period of time as you know, market needs evolved and our customer base evolved. But then we actually just, just took off because of that understanding and experience.

Brett: What did you find was the hardest thing in the 

first year of building the company?

Neha: I think the hardest thing was establishing Confluent as an enterprise company. So we very much had the brand of, you know, being the smart developers behind a very differentiated, interesting technology, but establishing Confluent as, hey, you can also think of us as not just community leaders, but also a serious enterprise company.

That required some investment in marketing, branding, and also releasing products that struck this right balance between open source development and enterprise development.

Brett: Can you talk a little bit more about how, how you did that? How you established it as an enterprise company?

Neha: one of the core things that still drive the company and drove us back then as well is customer centricity.

So we very much focused on, you know, our open source user base collecting feedback and our enterprise user base collecting feedback. And that centricity around the user drove, you know, a big part of our vision. The second thing that Confluent has done very well is, you know, feedback loops. So we have a very tight feedback loop and always had with the community as well as the customer base.

So that, always has worked in our favor. and the third thing I would say is developer evangelism. So, you know, Confluent in particular still does and did a very good job in developer evangelism, which I think, you know, any open source product out there just has to get it right. And, so those were the three things I would say that really influenced the early success.

Brett: what else sort of separates a company that's in the fraction of 1 percent at developer evangelism, maybe versus the top 20 percent at developer evangelism.

Neha: I think, you know, there are a few tactical things that you just need to get right from an execution perspective, which is very obvious to anyone actually, which is like, you know, excellent documentation and, you know, regular cadence of, you talk about release notes and so on and so forth. So that, you know, is just the base things that need to be done.

But I think what differentiates the top 20 percent from the rest is thought leadership. You know, thinking of developer evangelism as one of the most important tools to establish yourself as the thought leader in the space, because that is actually a core differentiator. You can, you know, compete on the product, but it's actually really hard to compete with the thought leader in the space.

So I think that is what differentiates thought leadership with the top 20%,

Brett: What does good thought leadership look like? Or what did you all do in the first year or two around thought leadership?

Neha: you know, what thought leadership really is about is teaching the end user a new way of doing things most of the focus of the communication is, you know, what's happening in the space, why, you know, a new way of doing things is needed versus. You know, writing a lot about or speaking a lot about, Hey, this is, you know, the product pitch, right?

The quintessential product pitch where you talk about your products, features and functionality and sort of try to convince people about using it. I think thought leadership is more about teaching people a different way of doing things and talking more about the why and the problem before, you know, you talk about the solution.

Brett: So, for Confluent in that first year or two, what was the narrative that you were communicating to customers in the market more broadly?

Neha: At Confluent, we wanted to create a new category called data streaming. We didn't want to get, shoehorned into the messaging system space or the logging system space. We fundamentally wanted to create a new category and we, we called it the data streaming category and that required a lot of thought leadership around.

You know, convincing people about the need for this category and what it means, and, you know, later on why Apache Kafka is the best data streaming technology, but that is, you know, the most important thing that we did and used developer evangelism is a core tool to do that is very much create that new category and it takes years to create a category.

It takes, you know, maybe a minimum of 3 to 4 years, but a continuous and relentless sort of, you know, investment in category creation really pays off.

Brett: Was it obvious that you should create a new category?

Neha: It really was, you know, because that was sort of how, Kafka came about is not because it's a scalable messaging system or not because it's a scalable logging system, but the insight that it's both. And when it's both, it didn't look like either. And that is one of the reasons why we thought, hey, this is a new way of doing things and this is a new thing overall. And a new way of doing things needs a new name and a new concept. So that is what category creation looked like for Kafka and Confluent.

Brett: Did it sort of organically come about in terms of the category of data streaming, and that's the language people were using or you got together and said, we're creating a new category, how can we articulate it, or what language are we going to use?

Neha: Yeah, we got together a lot, to think about what we should call it and we didn't get it right in the first few years. We called it something and then people got confused, you know, the initial few years were calling it event streaming and people thought of it as Netflix and movie streaming.

And there were a lot of, you know, different iterations before we, you know, settled on what it is today, which is data streaming and that took, off really.

Brett: How did you come up with data streaming? Was that just some random conversation one day?

Neha: That was actually a culmination of a lot of conversations and real product marketing coming in and you know, influencing, founders and the company to think about it, you know, in terminology that customers might understand. So that it did take a lot of conversations internally. But I think enterprise product marketing did play a big role.

Brett: Something we didn't talk about very much yet is the co founders in the business. what was sort of the early dynamic there? Was it, were you all very close and it made sense to start a company? And then how did you figure out who's going to do what and who's going to get what title and those types of things?

Neha: Yeah. You know, it, for the success of an open source company, all the creators should be part of it, and when that doesn't happen, you have two companies and they're competing on things they shouldn't be competing on, which mostly comes down to pricing and it's just a race to the bottom. So it made sense for all three of us to work together and all three of us to kind of come together and start Confluent.

So that was actually an easy decision because we worked very closely on creating the product in the first place. So there was a lot of experience working together. That, you know, was one of the most important decisions that the founding team took. And the second one was pretty organic. Each one of us had our strengths and, you know, each one of us were playing a specific role at LinkedIn, in the Apache Kafka team.

So the roles that we took in the company were just an extension of the roles we had at LinkedIn. So it was a very easy and organic decision, but a crucial one that we took.

Brett: How did you all start working together on the, project originally? 

Neha: So I think the way we did this is, my co founder Jay Kreps wrote the initial version because he came first into the, company and was exposed to a lot of the problems and envisioned a new way of doing things and wrote a prototype. And that's when I joined not because it was, you know, an interesting problem.

It was a problem that nobody else wanted to work on. Because building data pipelines was not very interesting at that time. They were breaking all the time. So mostly I joined to work on a very important problem for the company and Apache Kafka was the right solution to it. And then our third co founder, Jun Rao, joined the team as a deep sort of database specialist, which was very important to the conceptualization of You know, Kafka as, you know, sort of a change log from databases. It was very influenced by that. So, you know, we had a very diverse perspective on the team.

Brett: What were you doing at LinkedIn before you joined the project?

Neha: I was working on the LinkedIn's backend for search functionality. And that was pretty mature by the time I was working on it and I was, you know, always very curious about what was important for the company. And, you know, that's how, that's what influenced my, interest of working on the problem.

That's how I came across Apache Kafka and transitioned over from search to Apache Kafka.

Brett: Was that sort of a guiding principle for how you chose what teams you would try to work on throughout your career? Just figure out what's important to the company.

Neha: Absolutely. I think, if you align yourself to what's important to the company, you effectively end up working on the most important problems and end up learning something new along the way. So that's been a guiding principle throughout my career is to align my interests with what is the most important problem for the company.

Brett: you mentioned sort of this complimentary skills dynamic? What sort of can you talk more about that? And what in the early days did everyone own? That worked so well. I think it's particularly interesting in the context of of a super technical product where I would think there would be more overlap in skillset given there's just so much technology and product building versus maybe a traditional SaaS company or something like that.

So what are the complimentary skills look like? And what was like the divide and conquer dynamic in the first couple of years?

Neha: For us, it was, you know, organic in the sense that, you know, my co founder Jay Kreps was the face of Apache Kafka and it made sense for him to be the face of Confluent and that's what allowed him to take the CEO role, which he very effectively did. I was managing and running the streaming and Apache Kafka teams at LinkedIn, so it very much made sense for me to take the CTO and VP engineering role in the early days, which later on evolved into the CPO role out of need. And our third co founder, Jun Rao, was very much an internally focused architect and went deep on the code base and went deep with the open source community. So he was the open source community's face. So, you know, those were sort of complimentary skill sets, even within the engineering background that all three of us had, which I think is, you know, typically, not true of engineers who come together to start a company, but it's also the beauty of first time founders is, you know, you come together and you, as long as you have a growth mindset, you learn about each one of your roles and hopefully build something successful.

Brett: Did you think earlier in your career, you'd really like to start your own company or you just sort of bumped up against this and realized it seems like it could be interesting.

Neha: I bumped up against this and I thought it would just be interesting mostly because, I was really passionate about the problem space you know, interested and passionate about the solution and the new way of doing things that we had envisioned and always believed that, you know, people should start companies if they are passionate about a new space that they really care about bringing a new solution to versus, you know, thinking about starting a company and then finding a problem, which also are another way in which companies are started.

But I fundamentally believe that passion should lead the decision to start a company.

Brett: So switching gears slightly something we haven't talked about is the actual business So how did you go about generating the first dollar in revenue and figuring out sort of those type of questions?

Neha: the first is we built with monetization in mind from the very early days of Confluent. So, you know, we very much, were thoughtful about what would help our developers in the open source community and what would help our users in the enterprise customer base.

So what we did was a couple of things. We encouraged open source adoption. So features that directly enabled the end users of the open source product, we believe should ideally remain open source or be open source. And this approach, ensured us, that the core value proposition of the product would remain accessible to all.

And most importantly, the reason we did that is also because we wanted Kafka to be the de facto solution to the problem. And it's very important to focus on your free and community user base. But the second thing is what we did on the enterprise adoption was we built sort of features to encourage the enterprise adoption for mission critical applications.

So Confluent was very much, following the enterprise user base and, you know, offering a software product based on the traditional sort of compute based subscription model and that involved including operational tools to charge for security enhancements and integration capabilities.

So that sort of formed a very well rounded product for, the subscription based, software offering and then, you know, we evolved to offer a SaaS product and that became the most effective paywall, right? So one of the most effective ways to monetize, I believe, an open source product is by developing a fully managed SaaS offering around it.

So with the SaaS model, there's no expectation for the offering to be open source . Users benefit from the convenience, scalability of the managed service while the company can monetize the added value of the SaaS platform. So the core product can still remain open source and you benefit from its distribution, the brand awareness, but with a SaaS product, you very naturally can monetize that open source product.

Brett: When did the SaaSoffering come along? How far into confluence journey?

Neha: It came along pretty quickly. So about two years in, we realized that, there must be a SaaS offering because at that time, the whole industry was in the middle of this transition from on prem environments to the public cloud. So in order to sort of remain the. You know, leading technology and leading product in the space.

It was very essential that Confluent Cloud, which is a SaaS product we developed. And, you, you know, it's a difficult problem to solve because you're essentially building two businesses within a company, one is a software subscription based business model. And the other is a consumption based SaaS business model and just, you know, integrating both of those worlds is a a challenge, but it effectively paid off for Confluent.

Brett: can you talk more about how you did that and how you navigated it?

Neha: there were a couple things. So from a product perspective, we maintained a lot of overlap. So we thought about You know, foundational capabilities that would benefit both user bases, the open source as well as the enterprise user base and made sure that, that was always developed by the same team.

At the same time, you know, we had a Kafka team, layered on top that would focus on the community development and community facing feature development and also had teams, you know, separate teams that were building the proprietary feature set, but those teams, you know, everyone was fully aware, of thinking about these features in a cloud native manner.

So later on, as we introduced the cloud offering, we layered on, you know, sort of, tooling, folks that would encourage the rest of the organization to think in a cloud native manner. So that was sort of from a product perspective, what was done to integrate both the worlds, which was arguably, easier to solve for than the go to market side, because, from the go to market side marketing in particular, if you take an example

for the software product, it is a different dynamic. you're thinking around influencing the buyer of the product, and that's where you traditionally start. For an open source company, you also have to have a developer evangelism arm of marketing, which then needs to be integrated with the product marketing arm.

But, you know, from the SaaS offering perspective, marketing changes, right? You are encouraging users to easily start with the product and start using the product and encourage users to start with a free trial or whatever. And so, the marketing looks very different. So integrating both those worlds just meant that

you know, we needed to take a very bottoms up approach and user centricity approach where we made it easy for anyone to start with the product, whether it was the SaaS offering or the software offering. And that sort of became the guiding principle of the marketing world. And sales was just a whole different, you know, dynamic.

It was the most difficult one to solve for, because in the early days, you know, if you're offering a software product, you have the traditional sales people who are used to selling a subscription based software product, but, selling a SaaS product on a consumption based business model is just entirely different.

The DNA of the sales team is different, so that is a transition that the company is still making, but, you know, is probably the most difficult part of the whole equation.

Brett: Did you ultimately sort of separate it into two go to market teams with two different skill sets or, or like what, what was the path into solving it?

Neha: We actually decided to not split it, and, that was because, we ultimately wanted to transition to, a cloud first business. So, we put in, instead a lot of thought and a lot of investment in sales enablement, you know, internal education of why this is important, changing compensation structures gradually.

To encourage the adoption and scalability of the cloud product. So I think it was a very gradual and thoughtful approach, but we didn't segregate the go to market side or the product side.

Brett: when you think about the first million or 2 million dollars that you generated as a company, was that all done by the founding team, or did you very early on start to build sort of an actual go to market team?

Neha: the first few, you know, in, in general for Confluent, first many years, it was completely inbound in the sense that Kafka users knew that we were the Kafka company and they started reaching into Confluent. So the first few sales were, you know, founder led. Pretty straightforward. Then we hired more of a generalist kind of product leader who helped with the next phase of selling and very, very quickly added the first enterprise sales reps who did very well.

Brett: how many years in did they join?

Neha: So towards the end of first year, I think we had two enterprise sales reps who started aggressively overachieving. So that allowed us to scale the sales team, pretty aggressively in the years to come.

Brett: But you started with reps, not with a go to market leader.

Neha: Yeah, we started with some reps and then, added the go to market leader after that.

Brett: And do you think that that order of operations was correct?

Neha: That order of operations, you know, generally I believe is correct because, you know, the first phase, founder led sales is extremely important to understand, you know, why customers are buying? What are the problems? What kind of background is required in the sales reps to succeed? Then sort of testing the waters and making sure that your assumptions are actually correct by hiring the first couple of reps, seeing them succeed.

And, then hiring a sales leader who can come in and scale that. So it was a very much, intentional decision.

Brett: Did you go through a process to learn how to sell, or was it very natural? I think the sort of, um... Archetype of most super technical people is that sales tends to not come naturally, but I'm curious what your path was to selling.

Neha: So for Confluent, the dynamic was a little different. So you know, that allowed us to sort of, you know, not learn some of the selling tactics. So for Confluent, we were converting an existing user base from one product and upselling it to the other product. We were not selling a product per se, they were already sold on the product.

They just needed some help with it and we convinced them that this was the feature set and the support that you needed to succeed with it. So, it was actually, you know, funnily a very easy sales process, because they were already convinced that they needed it

Brett: what point did you have to start doing more traditional outbound or enterprise sales versus inbound? Was it just given the nature of the product many, many years in?

Neha: A couple years in, you you know, it was clear that to, reach the next stage of scale for Confluent that we needed to develop the outbounding muscle and that happened, you know, pretty organically as we were closer to almost 100 million in ARR, which was surprising, but that is, you know, all thanks to the immense Kafka user base that we had.

So a couple of years in, we started, you know, developing sort of marketing efforts and established like the SDR organization that could, you know, just leverage the Kafka user base out there, but more proactively reach out and that, you know, is today a pretty core strength of Confluent.

Brett: who was the actual buyer? In the very early days, like, who ultimately was the person that could sign and, you know, pay for the product?

Neha: So in the early days, and this is probably even true today, is, they were very much sort of line of business buyers, mostly because Kafka powered specific but diverse use cases inside a company. So the challenge at Confluent was less sort of convincing each use case that they needed Confluent. It was more, engaging with different line of business buyers, you know, bringing them together on a central platform.

And convincing and, you know, sort of helping them scale multiple use cases or gradually over a period of time inside the company. So it was, you know, the reps sort of spent a lot more time on this sort of land and expand motion and bringing different buyers together over a period of time until Kafka or Confluent became sort of the de facto system for all the real time applications in a company.

Brett: When you zoom out a little bit and you think about those first five years of building Confluent, what were the tough calls or the difficult moments that ended up being correct? It sounds like there were a bunch of things that were intuitively obvious. But I'm sure there were things along the way, bets that you've made that ultimately paid off, that at the time were non consensus.

And I also think that the Confluence story is one that seems somewhat obvious in retrospect. But I'm sure, you know, week by week, month by month, it didn't always seem as inevitable as it is now.

Neha: I think there were, you know, if I reflect on the first five years, there were a lot of small things, but I think the two big things that come to mind for me was timing of the SaaS offering. I personally wasn't as convinced, As my co founder was on the timing of the SaaS offering, but he turned out to be right, because it took a while for that SaaS offering to be stable and, you know, self service in nature in order for it to become successful.

So we really, you know, took a very hard decision to run two businesses in one company and introduce the SaaS offering in just sort of, or started working on the SaaS offering in just year two. That was probably the most critical decision. And today our cloud business is growing and is, you know, almost larger than the software business as well.

The, the second one was sort of strategic licensing decisions. So we faced. competition from cloud providers, just like any other player in the open source space. And these providers, the dynamic was, while not actively investing in the open source community, they usually offer managed services by hosting the open source product as is.

So they can capitalize on the popularity of the products, but not much, you know, contribute to the development of the community. So in response to that competition, Confluent made some strategic decisions around licensing. So we introduced value added offerings like stream processing, ksql, under licenses that were similar, very similar in spirit to the open source friendly Apache 2.0 but these licenses had specific provisions that prevented other entities from just offering managed services around the product. So this move was very much controversial at that time. It was, definitely many other open source companies were taking a similar approach, but not the same approach.

but it actually, helped us protect the interests of the open source community and, you know, ensure that those who benefit from the product also contribute to its growth and, sustainability. So off, you know, it offered us sort of the, commercial strength to then invest in the open source community.

So those, I think those were the two major ones that come to mind.

Brett: Can you explain more about that strategic licensing insight and maybe what was controversial about it and how it ultimately played out?

Neha: The licensing decision, is, you know, striking, a, very tough balance between keeping the open source community happy and building trust with them or not losing the trust you have and striking the right sort of balance, with the cloud providers because they're also potential partners.

So that is something that every open source company actually faces. So it's pretty applicable, but open source companies, didn't have the same approach, you know, they each used a different license to, make this sort of licensing decision. So there was a lot of work involved in educating people about the specific approach you're using to.

make this licensing decision. The other thing that we spent a lot of time on, which was actually more important, arguably, which is convincing our open source community that we're not moving away from the open source ethos. We are still very committed to it. And this is very much an open source friendly.

This is basically Apache 2.0 plus the fact that no one can just take it and offer a managed service around it. So it was, we put a lot of thought and effort into making sure that both the communities understood why we are doing it. And the fact that the license is basically Apache 2.0 

Brett: What are the things that you chose to sort of license in that way versus leave completely open source?

Neha: you know, that was, that's a great question because we followed the same approach we followed, to strike a balance between open source user base and the enterprise user base. So, there were very much offerings that the open source community needed to reach the next stage of Kafka adoption.

So this was an easy to use stream processing system. This was, a schema registry that would allow you to manage your metadata around Kafka. So these were all the things that the community needed anyway, and we wanted broad adoption of the, these technologies. So we, that made the decision pretty easy on what should fall under this umbrella.

That really guided the, you know, decision on what, falls under this new license.

Brett: I wanted to go back to sort of the conversation and the debate that you had around SaaS in the early days. What, what were the different perspectives at the time?

Neha: Yeah, I think the, the perspective, one perspective was, hey, we're a really young company. We're barely establishing our product around the proprietary IP that we needed to develop in a software product to sell to enterprises, versus, you know, with a very small team trying to build a completely different kind of product, which was arguably harder to build.

That was sort of a product lens to the problem. The good market lens was we have a big opportunity ahead of us with the early success of the software offering, we have the opportunity to simply sort of focus on and scale that side versus trying to, you know, merge these two worlds and build a new world, alongside the existing one.

But the other perspective was the market is changing, you know, the companies are moving from on premises to the cloud. And it's actually happening faster than we initially thought. And if you don't follow the market trend, you fall behind and eventually don't remain or become the market leader. So following our customers and still sort of doing the hard thing and figuring out, you know, how to jump into it and work on it were sort of.

Two different perspectives that we had.

Brett: how did you navigate the team structure around doing a cloud offering so early on?

Neha: You know, from a team structure perspective, if I start with the product side, we kept the foundational team the same. So there was only one team ever working on Apache Kafka and the foundation. There was only one team that was ever developing a specific proprietary feature set. So we never split.

You know, specific teams or individual teams to, you know, develop the cloud native offering versus the software offering. So that was a very intentional decision. So the product direction remains the same. The execution remains streamlined, what we did later on and hire a different skill set to develop

the operational tooling and the scaling of the cloud offering, which is one of the, you know, more obvious investments that a company needs to make any way to develop a SaaS offering. But what we did is we educated every team on the product side to think in a cloud native manner and to develop new features with a cloud native ethos in mind.

That was sort of a, you know, very structured decision on the product side that we took to navigate this change.

Brett: one of the thing I wanted to go back to. you didn't explain how you ultimately resolved the sort of big bet decision of building cloud so early on, was it like a disagree and commit or what was the actual pivot point at which you said, okay, we're going to go in this direction and make this bet.

Neha: It was, you know, didn't take a long time actually, it was one or two internal discussions where people share their perspectives and were ultimately convinced because the market and customer base was in indeed, going in that direction, and, managed to convince the people who needed to be convinced.

So it was less of a disagree and commit decision, mostly because that was where the market and customer base was going.

Brett: how long did it take you then to build the first version of the cloud offering?

Neha: It took us. A year to build the first version and even that I don't believe was the MVP. It just takes a lot of time to build the operational tooling that you need to build, which is just just merely the foundation of offering any SaaS product at all. And then for us, it also meant making different aspects of Kafka cloud native and different aspects of the features that we had already built in open source cloud native.

So that for us took a little bit longer, but otherwise it took a year to release something from the time we conceptualized it.

Brett: And then was that released in sort of, again, an inbound function or you worked with a small number of design partners? What did the first like five customers look like for the cloud offering?

Neha: It was very, inbound fashion we already had a couple of customers who were interested in using the SaaS offering so that, the rest of the go to market, we always focused on the existing Kafka user base and the existing Confluent user base. So the first five customers were just,

you know, existing customers who wanted to try it out. And when that became successful, we, you know, simply announced it. We released it, and the community took interest in it and, you know, started adopting it pretty fast.

Brett: Do you think Confluent would have worked if it was just the cloud offering right out of the gate and you weren't building these kind of two companies at the same time, or actually the way that it worked was sort of the globally optimal way to go about doing it?

Neha: It's a great question because we in hindsight have thought about this, you know, all the founders is would, would it have just been feasible if we started with a SaaS only offering? And the answer is probably not because, you know, one of the most important things in open source company needs to do is quickly establish yourself as the market leader, quickly establish yourself as the only real company you need to go with if you wanted that open source product.

So, which means you need to, as quickly as possible, gather the existing user base and convert them. And, you know, the existing upmarket user base was on premises. So we would have lost the opportunity of converting a really important user base in the early days would definitely have still converted them years down the line, but it ran the risk of losing the space to someone else who came and addressed that part of the market.

So that was, I think one of the major reasons why it made sense for us to start with the software offering. It still is a big business. So it turned out to be the right decision, but it just comes with its own set of, you know, operational challenges

Brett: So I wanted to do a little bit of a hard pivot and talk about starting another company. And I think that this is a really interesting area of exploration because there are so few examples of founders who build one unbelievable company that compounds and works and then go on and create another one and I think that's for all sorts of different reasons, I'm really interested to learn more about what was your process in deciding to build another company and the early work to get to conviction.

Neha: You know, for me, after taking a little bit of a break for, family, I just sort of got bored, you know, and did a lot of thinking about, who I am and what, I'm passionate about. And what that sort of led to is an insight that, I hold dearly now to my heart is that I'm a builder at heart, you know, I love waking up every morning and building something interesting with a team.

And that was one of the bigger reasons why I was encouraged to start something new. The next stage, you know, was really finding all the problems that I was deeply passionate about and had any experience in solving. So, you know, was focused on the founder market fit. So that is where the whole fraud and risk space came to mind because it's one of the largest use cases of Kafka on a dollar basis.

So I had a very close understanding of the problem, the gaps in the solution in the market, and why it is a big problem to start with. The third is, you know, having having had Confluent become a success, I'm ambitious that any next problem I pick should address a big enough problem and should have a big market to go after.

And the fraud and risk space is an extremely large market and is very relevant given all the transactions that we do now are happening online or are going to happen online. and the fourth is, you know, working with the team and a company sort of allows you day to day how to figure out which team you need to build, you know, how to build a culture on the team, how to get the team together to work on a problem.

And last but not the least, it was, you keeping in touch with my technology side and making sure that a solution for this problem is deeply technically difficult to build. And, you know, building this sort of a real time AI powered risk decisioning platform was fundamentally, is fundamentally a difficult problem to solve.

So that was sort of my process to start a company and then start Osciller in particular.

Brett: One of the things that I've noticed is that, when you build a company and it's successful, it's often ends up developing very hardened points of view on everything from how to build products to how to distribute pricing and packaging and so on.

There's also this hidden variable problem where often things work in ways that you might not entirely understand. And so then when you go to take the thing that worked the first time and apply it in a new context, it doesn't necessarily work. But because a company was so successful, tends to lead to people having a strong point of view on things.

And so do you think about that? Like, what can I take? And what do I have to just go unlearn or relearn or start from scratch?

Neha: Yeah, I'm very much so and the reason is because A, it's not only a completely different market and a completely different buyer, but it's also, you know, it's different in the sense that now I'm not building an open source based company and it's a traditional sort of closed source based SaaS product.

So the worlds are completely different. So I was going into it. I was very aware that it's going to be a different zero to one. It's probably going to be a different approach scaling the business. So really needed to be aware of what needs to be replicated versus what needs to be different. So there are a couple of things that I've kept the same, which is, you know, Oscilar's strategy is very deeply rooted in a customer centric approach really is in our DNA.

Everyone from engineering to sales engages with our customers directly. The second is long term vision. So while the immediate market dynamics are essential, I've always believed just like Confluent did in the power of a long term vision building a platform company. So that's, you know, the most exciting things that is common between Confluent and Oscilar is that both are conceptualized as platform companies. So it allows us to offer like a suite of interconnected solutions and addressing a really large market versus focusing on one aspect of the problem. And prioritizing culture from day one. And this is, you know, something I learned at Confluent, which we did really well, which we are replicating at Oscilar is to prioritize building a positive and inclusive culture from the outset. So those were all the things that just made sense that were common, but there were a few things that are really entirely different. So one is, you know, at Confluent we are building an open source based product offering a software and a SaaS offering, which is very complex in its own ways like we spoke about, but with Oscilar I've chosen to focus solely on a closed source SaaS only product.

It streamlines our go-to-market strategy, reduces operational complexities, you know, allows us to deliver a continuous value to our customers without the challenges of on prem deployments but the second is, you know, branding and the process of branding the company is different, right? Like at Confluent, we could lean on the brand of a very popular open source project.

So, the zero to one branding phase was actually really easy with Oscilar you're, you know, humbled that you're starting with something that people don't really know about. It takes some time to build the brand of the company, but the best way of doing that is by getting lots of customers who love your product.

that, I think, is a different approach to building Oscilar than confluent.

Brett: Did you intentionally choose sort of a style of company that was quite different or it just so happened to be that it was different?

Neha: I specifically chose a company that would be entirely different, you know, the reasons are like a one is just simplicity, you know, you kind of have, the experience you've had already balancing, building a software business and a SaaS business and trying to balance and transition from one to the other.

And so, you know, didn't want to deal with that difficulty again but the second is also really wanted the experience of building, traditional company, you know, starting with a closed source product, working with a few early customers, taking it to market is slowly building the product and scaling the company. The two worlds are so different that just from a curiosity perspective, it really, you know, keeps me going every day. So I learned something new every day. 

Brett: Can you talk a little bit more about tangibly how you went about exploring to land on this new company and how much of it was sort of an intentional process versus an intuitive one? 

Neha: a couple of things went into it. The first one was that, you know, I studied or learned that if you follow the market and there's a huge market transition happening and you're offering the most powerful differentiated product, then that's sort of the right problem to jump on. and that was, you know, one of the big reasons why I picked the risk and the fraud space is because, you know, especially with the pandemic, everything was moving online, there isn't still a right solution that's real time, you know, AI powered to solve this problem, to give you a few risk decision only a few milliseconds versus seconds and minutes.

And that turned out to be one of the bigger sort of factors in, me picking the risk space. The second one was just you know, reflecting on the fact that I had experience observing how the most technical companies which were Confluent customers still struggling with it. And reflecting on the fact that I also had experience from LinkedIn, observing how LinkedIn had built their systems, which, you know, arguably were one of the leading systems and, you know, it turned out that my co founder also had deep experience supporting Facebook's risk systems.

So now we have experience at the two leading companies', risk systems and learned that, you know, this is a big problem and even the leading tech companies struggle with it in their own way. So, you know, learned that the solution is going to be really hard to build. So that was the second part of the thought process.

The third was I you know, set up meetings with about 70 or 80 different buyers who are you know, heads of risk and different companies in different industry verticals and literally sort of showed them a Figma prototype of what they would be using if they were to use a product like Oscillar and to get that customer research to a point where people, were ready to buy something if only it existed.

So that was sort of the deeper, you know, next step of validating whether whatever I'm interested in and whatever is an interesting solution to build, like, is it a real problem or, or are people going to pay for it? And that's the biggest part of customer research that leads to successful companies. And you know, fourth was

knowing that there were people in my network and my co founders network, we could attract and build like a really world class team that could solve this problem in a short amount of time. and that was sort of the fourth factor, but those were all the, you know. stages in which, I progressed before the company started even.

Brett: Did you look at other market and problem spaces or immediately converged on this one?

Neha: there was one other maybe problem space again, sort of drawing on my experience, which is helping companies build like a customer 360 product, where you have like a central platform to tap into to understand your customer usage patterns, your customer data, and that is obviously powered by a streaming system like Kafka.

And it turned out that that market was. a little crowded and the timing wasn't right. And the differentiation wasn't very clear. So it just, it just didn't meet all the right criteria that I had learned as a second time founder, which is really important. You know, landed on the risk space very quickly because it was:

it is a problem that I'm really passionate about and it's a big problem in the market.

Brett: When you hear like headline risk and fraud, it feels like a very crowded space at a high level, but obviously you've landed on sort of an area that you think is an unmet need. Can you talk more about that? Because it just sounds like there's 50 companies or 150 companies doing something in the space.

And what was sort of your path into finding the opening?

Neha: Yeah. So the observation and the thesis is that there are actually, in fact, you're right, that there are a lot of companies in the space. And the problem is that these are all point solutions, so they focus on a specific part of the problem. So, you know, one company might focus on assessing your email risk or another company might focus on assessing your device risk and so on.

So now companies have ended up with a lot of these point solutions that each give you a fragmented view of the user's risk profile, which effectively then leads to a suboptimal decision about the user's risk. So the main insight is that you need a single unified risk platform that can collect signals from every touch point of the customer journey that can integrate data from all these point solutions into one platform and give you this 360 view of the user's risk profile to ultimately make the final decision

on that user's risk and be able to do that in 50 to 100 milliseconds. So this insight of, you know, this lacking sort of integrated unified platform in the space is 

what, you know, led to the high conviction that there is a very differentiated and different approach, which then matched the problem and the need communicated by the risk leaders in my customer research.

Brett: One of the things I'm really interested in is like the difference between a problem and a problem that has a lot of commercial opportunity tied to it. Such that people will either pay you for it or will pay you a lot of money to have it solved. Did you sort of find that in, in building now these two companies that those two things are sometimes different?

Neha: Yeah especially, you know, as I did customer research for Oscilar I found that it it is really important to make sure that you reach a point where someone says, I will pay for it. Can you build this? And that takes a lot of time and iteration to reach that point. And one of the big reasons why also I picked this problem is because there was a clear build versus buy decision that

favored the buy decision. That was not very obvious at Confluent actually, we spent a lot of time focusing on convincing the company that they didn't need a team managing Kafka or that team could be much smaller, effectively, you're dealing with you, you know, target customer base that just wants to do it themselves, right?

So the DIY mentality is pretty strong, but in Oscilar I realized that, the head of risk, which is the buyer, actually does not have the engineering team. They just don't hire for it. They don't report into it. They just don't have the team that can build the technology and the product they want. So they're very much looking for the right solution in the market.

And they're ready to pay for it because they're losing 10x 100x more dollars, when they don't use the solution so even a small percentage of that loss that they're experiencing is a price worth paying. And that price is actually pretty high. So that was also an element, you know, wearing my business hat, which was very important to picking the problem is you just didn't want to spend the resources it takes to convince someone that they shouldn't build something in house and should just use something new.

Brett: So I wanted to wrap up where we often do, which is ask you in your role, as a company builder, who are the folks that have had the biggest impact on you? And were there any sort of specific tangible things? That they taught you or insights that you gleaned from them?

Neha: I don't think that anyone specific comes to mind, but what I've done pretty frequently at Confluent is realize that I was a first time founder and just didn't know much about anything on the business side. And I was very proactive in reaching out to leaders at different companies to just learn how they had solved the problem and the problems that they ran into and married that by reading every book there is on that topic, and sort of triangulate those two inputs to formulate my own perspective on the problem and my own, you know, own approach to the problem. So sort of, I wouldn't call it mentorship, but I would call it a lot of proactive research that has influenced my thinking around company building.

The second thing is, just having done it before now, in hindsight, I just learned a lot of, lessons from the success of the company, as well as some of the challenges that I experienced along the way. and you know, leaders that I now see in the space who have done something special repeatedly, and, you know, reading about them or having a chance to talk to them that has been you know, those are, I would say, are the three factors that have influenced my thinking as a leader.

Brett: What's an example of, a proactive research sprint or a problem maybe when you were building confluent that you went out and talked to people? What were those conversations? How did you sort of triangulate the solution?

Neha: It was when we were starting the cloud product and the thinking around the monetization of the cloud product. And back then, I remember that, the CPO of MongoDB. and today Atlas, their product is the most successful cloud product out there, arguably. And proactively reached out to the CPO there, and regularly had conversations, hired him as an advisor

at Confluent and was very helpful in avoiding some of the problems that they ran into and learning from the experience that they were, they had because they were a couple of years ahead in our journey. From a perspective of building a cloud business, the insights I got from just, you know, setting up time and learning from MongoDB was pretty instrumental to the extent I remember.

Brett: What do you remember what a few of the insights were if we didn't touch on them?

Neha: One of the insights, was around, you know, the go to market scaling framework for PLG companies. So effectively as an open source company, we were in some way a PLG company, but, you know, what it means to introduce a consumption based business model around a product led, growth model was sort of a new concept that I had to wrap my head around and, you know, everything from understanding PLG dynamics before diving into scaling to scaling customer success to rethinking sales and marketing, all of these 

aspects of company building looked very different in a consumption based business model. So I spent a lot of time thinking about that aspect and learning about consumption based business models before, you know, or while building Confluent Cloud.

Brett: Awesome. Well, thanks so much for spending the time with us. Really enjoyed it.

Neha: I really enjoyed it too. Big fan of first round. Thank you for your thoughtful questions.

Brett: Awesome.