Jyoti Bansal on how Traceable found product-market fit

Speaker A: Product market fit is a journey, and whatever your assumptions are, you have to validate the assumptions, change them, iterate over them, pivot over them.

Speaker B: Hello and welcome to the Unusual Startup Field Guide. It's a podcast where we learn from the most successful founders of unicorn startups how their companies found product market fit. I am your host, John Briones. Today we'll be diving into the story of Traceable, and this is a special episode for us because we're doing it with my good friend and co founder of Unusual, Jody Bonzel. I've also been an early investor in all three of his unicorn companies, so I'm excited to have the chance to interview him today. Welcome, Jody.

Speaker A: You're my favorite person to talk to about this topic, so it's great to be here.

Speaker B: Well, excited to dive in. Um, let me give the listeners a little more context on you, Jody, and then I'm going to start firing some questions at you like we do with all of our guests. We go back in the time machine and we talk about the journey to finding product market fit. And so we always start with the insight that led you to starting a company. In this case, we're going to dive into Traceable, which is actually your third company. So even more reason, people are probably wondering, why the heck did this guy start a third company? So why don't we start with that? We'll always talk about the value hypothesis. We'll always, which is the what, the who and the how as we relates to your journey. And then we want to hear about the surprising twists and turns that you took on your way. Before we dive into the latest on Traceable, we should talk about the news last week.

Speaker A: Last week we announced, uh, the merger of my two companies, uh, Harness and Traceable. Harness was started with the mission of can we simplify software Delivery? And, uh, DevOps and all the toil that developers have to do once the code is written to ship software. And Decibel was started with the mission of can we secure all the software that the developers are, uh, uh, building and can we make sure that there are nothing, no kind of breaches that are happening at the code level, API level, software breaches. And what we realized was that the two companies, uh, are starting to converge more and more in terms of the buyer Persona, in terms of the user Persona, in terms of how people are looking to solve these problems in more of a DevSecOps fashion, where DevOps and application security is starting to converge and becoming more of a, uh, joint responsibility by the engineering teams. And we Announced the merger of the two companies where the M2 missions continue when they merge so we can bring uh, a more complete, comprehensive solution to the market for them. And it just closed today and we are uh, excited to bring the two teams together. But if you go to your original question on why was it start? Part of it is many people ask me like, why were there two separate companies to begin with? And that's where the some of the founding thesis and the founding the why who worked.

Speaker B: So we like to use the word insight when we talk about the journey to product market fit and that journey for founders maybe take us back in the time machine. What was the insight that compelled you to start Traceable?

Speaker A: Yeah, for M. Me, the traceable insight came from my days at Appdynamics. At Appdynamics, when we had a very great observability and tracing, uh, platform. And that observability and tracing was used for people to troubleshoot performance issues. If you are building a software application, your performance slowdown or your performance outage, you uh, would use the tracing observability technology to figure out the root cause and fix it. And many times the customers of AppDynamics will ask me this thing that can I use a similar instrumentation observability tracing kind of techniques for securing my applications? Because can you understand what's happening in the applications and can you secure them? And that conversation will happen again and again. So it was very clear to me that there was a pain there and I was interested, uh, and excited about solving that pain. And to me the insight was that there is a lot of pain around securing applications. The second insight was that the techniques that we are doing for performance monitoring and troubleshooting could be the inspiration for how our next generation of application security product could be built. But similar kind of techniques for instrumentation, observability, tracings and those two combinations that there is a pain and there is a unique way to solve this and the pain is getting bigger and bigger was the founding insight part.

Speaker B: And one of our favorite questions at Unusual is talking about the technical inflection that's bigger than even the company itself. So as you think about traceable, what was the big technical inflection that was happening at the time that you saw as an opportunity?

Speaker A: Yeah, the biggest technical inflection that was making it clear is the uh, this kind of high emergence of microservices serverless architectures, that everything connecting to APIs, either internally APIs or externally through APIs, that what is an application, the inflection technical, uh, Inflection was the definition of application is a bunch of things that are connected to APIs. And now if you look from a security perspective, it becomes a massive challenge. Everything is, there is so much at transit like in what's coming in, what's going out, how you are interacting between different software systems internally, externally. And to me the API economy or the explosion toward APs was the technical inflection point which as we talk about technical inflection points, the big drivers for what's your wedge to build a new generation of a business.

Speaker B: Right. So without the change, there's seldom opportunity. So it's 2025 year today. We're sitting here in March. Take us back. What year was it when you were thinking about this?

Speaker A: When I've been thinking about it for a few years before that. But 2019, it was very clear to me the inflection point that was happening with APIs, the pain points around that was happening, all the conversations with customers I had over the years around the pain points on end. So in 2019 is when let's figure out, as an entrepreneur, you always start with when you have the insight, but you also start, get high degree of conviction on the insight that the conviction says someone has to solve this problem this way the world uh, is underserved without solving this problem and if I don't solve it, someone else will do it. And that's when I started having dialogue with Sanjay, my co founder who was still at uh, Appdynamics at that time, to join me and we can start a company to, to solve this and at least start experimenting. It's a lot of people think because I started this was my third company and successful company that became a, became a unicorn, everything would have been smooth. This time I'll find all my insights will be right, all the assumptions will be right, everything will be like a straight smooth line. It's uh, it doesn't work like that. Whether it's the first company or second company or third company, product market fit is a journey. And whatever your assumptions are, you have to validate the assumptions, change them, iterate over them, pivot over them. And we had to go through that journey as well.

Speaker B: So if you don't mind, let's talk a little bit about that. Right. So when we use the term product market fit, we often talk about the value hypothesis. And the value hypothesis has three pieces. The what meaning what's the solution and how are you going to package it? What's the thing you're going to build? The uh, whole is that desperate user or that segmentation of the market that you're going to go after and then the how, which is how are you eventually going to price and distribute the product? So if it's okay, I'd like to walk through each of these as it relates to traceable, because as you point out, I remember talking to you about some of the assumptions that you originally had for these things didn't exactly go according to plan. And I think that's really important for the listeners to understand that even on your third time, it's still an iterative experimental experience. So let's start with the what was the original what that you were going to build when it came to traceable?

Speaker A: Yeah, yeah, the what was because a lot of it was inspired by my previous experience and Sanjay's previous experience at AppDynamics, that it was the ability to instrument and watch inside applications to bring this next generation of uh, application security with API security as the technical inflection point. That was the what we thought we would do. What we realized was that it wasn't the right. What and I'll go into that is we are biased because that's what was very successful for us from the performance monitoring world. The uh, ability to instrument and watch the applications completely from inside by watching the runtimes of Java programming language or. NET or PHP or Node JS and all that. And that's the technology we started building. That is the what. That is the product that we can instrument and watch your applications and APIs and secure them by doing that. And when we started having the customer discovery and the customer dialogue and started to sell it, we built up build many of those techniques as well. What we realized was that's not enough for the security folks. The friction of uh, instrumenting and watching the applications could be much higher than the value right away. It's. You need to, it's the. And that's the the it Also when you start breaking the problem of what does securing an application mean? What does securing an API mean? We also realized that we started with securing mean you need to protect them. That a hacker is trying to hack an API. You have to protect it. What we realize is like the, the market is still not fully there in, in people's uh, terminology, what they think is securing means first understanding what is going on before they even think about protecting it. Say I don't even know what to protect. I don't even know how many APIs are there. I don't even know what developers have built out over time. We don't even know who uses what. Uh, so the first stage of security is protecting them. It's just understanding what the APIs are and like a discovery and catalog and understanding the risk around it. The second stage is testing them. Can you test and find the vulnerabilities and fix them like a bit more productively? And then the third stage is you are protecting them in runtime. So we started with our understanding that securing means m protection, like how secure something without stopping the hackers. But it's a journey there. And what turned out to be that our technology approach that you go and instrument these applications and code from inside is too heavyweight for the first phase which is discovery and catlog. So there was a disconnect in that we realized and we realized that we need to change our technology approach and augment our technology approach that is not just about we need to bring a lighter weight approach for the discovery and testing that doesn't require people to instrument. Uh, and the effort that people need to do easy way to plug it into their applications so that discovery and cataloging can be done in, in hours and without much work involved from the engineering teams, et cetera. So that was definitely the evolution of what we thought the what would be and how we have to go through the what became like it's a three pronged journey for a customer and the technology that we are building and the technology approach that we thought wasn't the perfect fit for it.

Speaker B: So let me paraphrase if you don't mind. You were right that APIs were an issue for people. So the technical inflection wasn't incorrect. What you were I think ahead of the market on was the need to secure those APIs. Problem one wasn't securing them. Problem one was understanding what APIs people had and how they were getting used. So you had to think a little differently about the initial solution for the product. Uh, you talked about speaking to customers, which brings us to the whole.

Speaker A: Mhm.

Speaker B: So you had initial insight about who might be most desperate. That's the word we like to use that unusual because only desperate people buy from startups. Can you talk a little bit about that customer discovery process and who you spoke to and what you learned in terms of uh, who might be desperate for it and who maybe wasn't that you thought would be.

Speaker A: Yeah. So the assumption that we had for who when we started was that this will be mid sized companies who are completely born in the cloud API first highly modern cloud native architectures and that would be the who it intuitively made Sense. That's what the assumption we started with. The good thing is as we teach in Unusual, we got to validate the assumptions in the customer discovery process. And I would say that is the traceable team. We did a good job at it. And also thanks to the Unusual Academy, the Haga and unusual founder services, the team was embedded with us in going through that process. And it was. So our thesis was that who is uh, these fast moving, smaller mid sized teams, maybe 300 developers, 500 developers, fintech, health tech, insurance tech as the initial starting point with the most desperate pain. Before we go into enterprise. And in these teams the Persona of application security and software engineering is converged together. Most of the times in these teams it's not as uh, separate kind of Persona. It's the, you have your uh, software engineering teams are very, are security conscious and they are also, they are much more uh, comfortable with uh, a lot of data and ability to analyze the data. That was our, our initial what we found in the discovery process that is really not true. The people who really care about the securing the APIs the most are larger financial institutions and larger health care services where compliance is a big factor. Uh, and where there is just more cyber attack, cybersecurity attacks. It's the when you're a smaller company the reality is you're not getting attacked by hackers. You don't really if you're a hacker Winfrey, go and put your energy on, you'll put your energy on somewhere where there's just a much bigger price to get in terms of what you can get. So what we realized is the more pressing pain is larger enterprise especially like larger financial services, healthcare where compliance is a factor. People need to protect the data that hackers are trying to steal. There is, they're required. The impact is very high. And that was an assumption change in our mind the where the pain was and that reflected in the how significantly. Because when we, when the assumption on how was that we'll build a very PLG kind of model. If you're going to go to the fast moving mid sized kind of companies, PLG is the right model to go to market. That's how the product was designed. We had a, a uh, strong open source model as well. So we can go into these, into this customer base at high velocity, rapid kind of thing. What we realized was that wasn't the right market. Most of the revenue that we are seeing even when we are trying the PLG model we realized that the most of the revenue was coming from large enterprise who was really struggling and the world was desperate about solving some of these APIs security needs. They were mandated in many cases by the regulators, by their, by the compliance teams or like previous attacks that they had cybersecurity attacks that they had happened, et cetera. So the how was the initial assumption on what we thought the how would be had a pivot as well that we have to pivot to more of a cybersecurity enterprise selling and what. We also realized that the PLG didn't work as well for us because um, in cybersecurity when you're selling to enterprise the teams are very constrained, they're very small teams. They don't have the expertise or even time to go and download a free product and drive it. And they are normally done a little bit top down where the priorities are driven by someone senior CISO or someone on what is the what are the priorities are. Uh, many times they use the third party wars to do even the evaluation because they don't have the expertise to do the so you have to work with the third party wars. So we started with a ah developer engineer, PLG focused go to market assumption and working towards that to a more of a enterprise cybersecurity involve. The VARS evolution of our how our go to market and what you can see as we also talk about in the academy that they all go hand in hand together like the what, the who, the how. You know, once the who starts to change, the how has had to change from the if you didn't adapt that and adjust that the business wouldn't have worked.

Speaker B: So let me get this straight, it's your third company, you've built two prior unicorn companies and you got the what, the who and the how at least partially wrong to start and the what you thought you had to secure. Turns out people just needed discovery. The who you thought it was mid market. It turns out the consequences were much more severe for larger companies. So you went after that and instead of PLG which by the way was very cool in 2019 everyone was trying to do it. It turns out that classic enterprise selling was the way to, to actually reach the desperate who. So just for our founders like that's a lot of pivoting, that's a lot of shifting. That's uh, an amazing growth mindset. Like what advice do you have for people who are going through this JO journey just based on your own?

Speaker A: Maybe I should be embarrassed here. That time I had to do all of this. Now the reality is this is how a startup building is and this is where the all founders. My advice is not about that. You're right. It's about that uh, were you flexible and were you able to iterate to the right path? We are lucky on a few things that we are right on our assumptions and maybe we'll eventually be right. Some manual assumptions that we had three years from now, two years from now and they're starting to like what we saw in 20, 19, 2020 and versus even today they are starting to change like the world. But you have to have the flexibility to iterate and adapt and change and uh, there is no shame in it. My advice to founders is that is your number one strength. If you can build as a company as and as founders, find your path, adapt, change, pivot and be very brutally honest about assumptions because if you're not and you're kind of, you're holding to assumptions that just are not working at some point your, your business is not going to survive in the, in these

Speaker B: pivots that you did, you talked about customer discovery and lots of conversations. Is that work that you delegated to someone else, your co founder a sales like how, how did you actually uncover and then come to these realizations?

Speaker A: It's, it's, it's, it's a combination. I, I like to spend a lot of time on customer discovery. Personally myself I've done I would say at least 100 calls everywh directly uh on the calls myself hearing, listening, having this conversation. But my co founder Sanjay, he led many of these and many and even more. We started to get some help from a salesperson to help with the meetings. The unusual founder services was a key element to it as well to set up some of these customer meetings. And I always talk about the uh, you don't want to spend most of your customer discovery on warm uh leads or warm intros or friendly friendliest. You want to have the cold conversation because that's when you get the most honest conversation when people will tell you like yeah this is a pain. This is not a pain. We even we had, we actually sold to some companies that were not the right product market fit. Who are these kind of the early stage like the small fintech kind of companies where they were excited about it, they bought the product for not too much like 20, 30, 40k uh a year. And as we went through this exercise and we like co building them we also realized that they were, we sold to people who are not the right product market fit and we adjusted the product market fit like a year later when we realized okay Our product market fit and majority of the money where we could build the business, a very successful business which we were able to do is in the enterprise with this kind of uh, go to market. And we that these were the pre product market fit customers which is very strange that we had. We used to call them like these are that we have these eight customers which are in our pre ICT pre product market fit experimentation category who were excited about the problem and bought for small amounts. But we knew eventually they were not adopting it fast enough because the pain was not desperate enough.

Speaker B: And do you think in put your intellectual honesty hat on, do you think the things that you discovered were knowable a priori or do you think that you had to go through the experiments as the mechanism to learn them?

Speaker A: I wish things were discoverable, knowable beforehand. But the reality is it is not. Anyone who claims it is that they knew all the answers. They were most likely they got very lucky that all their assumptions were right, which I don't think is the case. I've done it three times, I've done a mix. I had some assumptions that were right, some assumptions that are not right and I had to pivot on those same in harness, same addressable m. But no one can get all the assumptions and if you don't change it won't happen. That really to me is the crux of the product market fit process of like how do you validate the assumptions that are right and how do you invalidate assumptions that are not right and find the right solutions and where everything fits together, how all comes together and then you have a product, a community successful go to market model that you can build around it and you can scale the business.

Speaker B: Silicon Valley loves its founder revisionist history stories where you were hit by a bolt of lightning and everything went right and all your assumptions were true. But the reality is that's just not how it works. Right. This iterative process is embrace it. Right. It's part of the journey. So it's a real credit to you that you have the perseverance and the learner's mindset to continue to pivot right. Because that seems like that is the way.

Speaker A: And it is hard and uh, could be frustrating sometimes, but it is very fulfilling in the end that you are and you are reducing the risk a lot by going through the iterative exercise. And I say if you go on a false assumption and you hire a lot of salespeople and you start burning your cash away, it's, it's, it's, that's why a Lot of companies don't survive. The space stays there. That said, maybe I wish, maybe if I do a fourth company ever, maybe I've less privileged to do, but at the same time I do. As I said, this is how companies are built and I'm a strong um, believer in the uh, this kind of the flexibility is what makes us strong and direct.

Speaker B: Yeah, your ability to run experiments, to learn fast and pivot quickly as opposed to building too much, spending too much time and money. I think that's often the difference between the startups that succeed and don't. Okay, so Traceable, amazing news last week. Just to summarize on that. Now Harness and Traceable are together. What's the big vision for the company as you think about the next five, 10 years?

Speaker A: The vision for Harness and Traceable combined now starts with uh, what's happening in the world of software engineering. There are about 40 million software developers in the world today. And if you look at the cost of software developer across the US, Europe, India, China, everyone combined, there's about at least $100,000. That's about $4 trillion that's spent on software engineering. The reality is about 30, 40% of the software engineering time goes into all the things that are outside of coding and planning and creative work. And if you go in a very large sum, it could be even 60, 70% of the time. Whether it's about testing, building code, deploying code, making sure the cost is good, making sure compliance, making sure your quality is on, scalability, performance, all of that is good, making sure your security is good, which is a big time drain. And that's 40% of the cost of software engineering. And if you now you look at AI, AI coming in is significantly increasing what could be done with software engineering. The amount of code that's being written is going to go 2x, 3x 4x 5x because the productivity gain that the software engineer is going to have it also the more people will easily become developers now citizen developers with AI, uh, software engineering will become more accessible to do that. So we are just going to see a massive explosion in the amount of code that's being written. So now if you look at the delivery process of building, deploying, securing it, governing compliance, all of that becomes an even bigger problem. If you look at, even today, it's like it's a trillion dollar of the software engineering time is spent on software delivery. All the work that goes in there and our vision and harness is to can we automate most of that to AI? Can we bring data and Automation and AI agents to solve most of that. A lot of people don't think of Harness as an AI company because we started before ChatGPT. It's like when harness was launched in 2017. This was 2017, end of 2017 in the market. The headline uh in press was Harness brings artificial intelligence to continuous Delivery. This was 2017. So we have been building AI based systems for DevOps since then. Not LLMs at that time but we were at the forefront of bringing AI to DevOps. How we got get the deployment validation automatically, how do we do speed up your builds, how do we speed up your tests when you launch our CI, how do you do cost management, all kind of things. We have been at the forefront of AI and now we are taking that all of that and we are becoming the agentic AI platform for all the software delivery use cases whether it's DevOps, FinOps, application security, quality, reliability, deployments. Build all the grunt work that the developers have to do but they don't want to do. Uh, of course there's a lot of exciting work happening on the AI. Helping with coding I always talk about. Yeah helping with coding is amazing but what about that? But that's actually coding is the interesting work that the developers like to do. What if all the non interesting work that developers don't like to do which is taking 30, 40% of the time, let's bring AI to that and that's where our mission and Harness is and a big part of that is security. That's where addressable comes in. How do you create secure software? How do you deploy secure software? How do you make sure everything is secure all the way through the software life cycle. So very excited about where the business can grow. We are sizable business now. This year the combined companies will be north of 250 million in ARR growing north of 50% and a few companies at our size growing at that. So we are very proud about that and we think like the momentum is with the two companies coming together continuously window to offer for the next many years.

Speaker B: Amazing. Listen, I really appreciate you sharing the story, being vulnerable as always. I've learned so much from you over the years so uh, appreciate being your partner in the journey. So let's wrap up with a few uh rapid fire questions quickly if you don't mind. The first is what is your one piece of advice for aspiring entrepreneurs who are building right now in the age of AI?

Speaker A: The advice that I just shared already be flexible. Iterate validate your assumptions and that's be flexible to change What's a book that

Speaker B: you think every founder should read?

Speaker A: One book, the one I really. And um, I think every founder should read is Built to Last and Jim Collins. You know, it's the whole concept of to build a great company, there have to be a vision and uh, some kind of a visionary mindset about your company, about the problems you're solving. You're building it for the long term, but you're not really just looking for flashy things, all the learnings and insights. I think it's uh, very helpful for me and I would encourage every founder.

Speaker B: What's the secret to building a great team?

Speaker A: For me, secret to building a great team? You try to hire the best people as in the areas that you're looking at. And to me I look at. Everyone has to lean on their superpower. That's how the great teams are built. If I have a certain superpower, I want to lean on that and I want to surround myself with people who have different, other superpowers, other strengths that they are really good at that I can learn from on those areas from them. And that's what I encourage everyone. But that's bringing the right people. The second part to me is about building great team, is creating high degree of alignment. And a lot of times like I, when I build a team management team, my focus is and that can I create alignment, that people are all marching in the same direction in the same way. Your clarity of vision, short term, long term, your clarity of goals, short term, long term, your clarity of high level. How are we going to go there today and two years, three years from now? And once that alignment is there, the teams can just go and run on themselves. And you don't need. They trust each other, they respect each other, they're. And now you. The third thing that you layer on top of that is visibility and accountability, that you have the right people in the seat. You create alignment and goals and clarity around that and then you have ownership, accountability and metrics and visibility that are shared across the team. Not just to me as to everyone in the team. So they share the metrics, there's good amount of transparency, interest comes in and you have a good thriving team that can operate at that point.

Speaker B: What is the one soft skill for founders that you think is supremely important?

Speaker A: One soft skill, I call it, uh, ability to sell or ability to inspire or ability to get people part of your mission, your vision as founders. That is the, uh, most of the founders come from technical backgrounds, product background, like myself. And to me it was very Clear. The soft skill that I needed to know is to get. You've got to be selling everywhere. You'd be selling to people to join your team. They're selling to your customers. Of course, you're selling to investors to invest in you, all your partners, all kind of people. And that's. You have to become good at that. And selling could be sold, could uh, be described as storytelling of who you are, your company, the problem you're solving. It could be creating inspiration around it, but that's every founder has to learn it.

Speaker B: And last question, leadership can be a lonely thing. What's one truth you wish you knew about leadership before you started all those years ago? AppDynamics

Speaker A: One truth I will send you that is not easy. It's like when we see the from outside success stories and it feels like very glamorous. But really when you start feeling the layers, which I didn't know before I started, it's like it's all about grit. It's all about determination. You will have, you'll have out of 10 days, you will have five good days and five bad days. And you need the grit to go through those five bad days. And otherwise it could be, you'll be. That's important part, especially in the startup world, you know, the entrepreneurial world. Leadership is all about having that grit and not think of it's an easy, glamorous journey. That's, that could be the outcome. But even for that outcome, you have to go through all the uh, all the hard things.

Speaker B: Amazing words of wisdom. All right, well that's Jodi Bonzel talking about traceable and the journey to product market fit. Thanks everybody for tuning in to the unusual startup, uh, field guide.