Jyoti Bansal is the CEO and co-founder of Harness and Traceable. He is also a co-founder of Unusual Ventures.

‍

In a special episode of the Startup Field Guide podcast, Jyoti sits down with John Vrionis — his co-founder and friend of 20 years — to discuss the recent merger of Harness and Traceable. This merger positions Harness + Traceable to create the most advanced AI-native DevSecOps platform in the world!

‍

Some highlights from their conversation:

‍

The technical inflection point for Traceable was the emergence of microservices and serverless architectures, leading to an explosion of APIs and new security challenges.
‍

In the episode, John and Jyoti explored the key factors that shaped Traceable, including:
‍

• The initial assumptions about the target customer (the who)
• The original planned solution (the what)
• The planned go-to-market strategy (the how)
  ‍

Spoiler alert: Every one of these assumptions changed during the initial customer discovery process.

‍

• When it came to product, Traceable went from their initial assumption around securing APIs to first helping customers discover and catalog their APIs
• On the target customer, Traceable shifted its focus from mid-sized cloud-native companies to larger enterprises in finance and healthcare
• The company's GTM strategy shifted from a PLG model to enterprise cybersecurity sales

‍

One of the most important takeaways from this conversation is that even for experienced founders like Jyoti Bansal, product-market fit is an iterative process requiring flexibility and willingness to invalidate assumptions.

^‍

If you are curious to learn more about the merger of Harness and Traceable, check out the episode on YouTube and/or the transcript available below!

‍

**Extra: Want to know which book Jyoti thinks all founders should read? Hear all about it in our CEO Rapidfire segment.

‍

Episode transcript
‍

John Vrionis:  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 Vrionis. 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, Jyoti Bansal. 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.

‍

John Vrionis:  Welcome, Jyoti.

‍

Jyoti Bansal: You're my favorite person to talk to about this topic, so it's good to be here.

‍

John Vrionis: Let me give the listeners a little more context on you, Jyoti, and then I'm gonna 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 gonna dive into Traceable, which is actually your third company.

So 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, which is the what, the who, and the how as it relates to your journey, and then we wanna hear about the surprising twists and turns that you took on your way. Before we dive into that, we should talk about the the news last week.
‍

Jyoti Bansal: Last week, we announced the merger of my two companies, Harness and Traceable. Harness was started with the mission of, can we simplify software delivery and, DevOps and all the toil that developers have to do once the code is written to ship software. And Traceable was started with the mission of, can we secure all the software that the developers are building? And, can we make sure that there are no breaches that are happening at the code level, API level, software breaches. And what we realized was that the two companies 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 are starting to converge and becoming more of a joint responsibility by the engineering teams.

And we announced the merger of the two companies where the two missions continue when they merge so we can bring a more complete comprehensive solution to the market for that. And it just closed today. And, we are excited to bring the two teams together. But if you go to your original question on why it started? Many people ask me, like, why were there two separate companies to begin with? And that's where some of the founding cases and the why, who, what, comes in. 

‍

John Vrionis:  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?

‍

Yeah, the Traceable insight came from my days at AppDynamics. At AppDynamics, we had a very great observability and tracing platform. And that observability and tracing was used for people to troubleshoot performance issues. If you are building a software application, when your performance slows down or you have a performance outage, you 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 can I use a similar instrumentation, observability, tracing kind of techniques for securing my applications?Can we understand what's happening in the applications and can we 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, and excited about solving that pain. And to me, the insight was there is a lot of pain around securing applications. The second insight was that the techniques that you 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 combined there's a pain and there's a unique way to solve this, and the pain is getting bigger and bigger was the founding insight part.

‍

John Vrionis: 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?

‍

Jyoti Bansal:  Yeah. The biggest technical inflection that was making it clear is this kind of high emergence of microservices, serverless architectures that everything connected to APIs, either internally APIs or externally through APIs. Then what is an application? The technical inflection was the definition of application as a bunch of things that are connected to APIs. And now if you look at it from a security perspective, it becomes a massive challenge. There is so much in 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 APIs was the technical inflection point. Technical inflection points become the big drivers, the wedge to build a new generation of a business.

‍

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

‍

Jyoti Bansal: I’d been thinking about it for a few years before that, but in 2019, it was very clear to me the inflection point that was happening with APIs. As an entrepreneur, you always start with when you have the insight, but you also start to get a high degree of conviction on the insight; you have the conviction to say someone has to solve this problem this way. The world is underserved without solving this problem. And if I don't solve it, someone else will do it. And I started having a dialogue with Sanjay, my co-founder who was still at AppDynamics to join me and we can start up a company to solve this. And at least start experimenting.A lot of people think because I started this third company and a third successful company that became a unicorn, everything would have been smooth this time. I'll find all my insights to  be right. All the assumptions will be right. Everything will be like a straight smooth line. 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, pivot toward them, and we have to go through the journey.

‍

John Vrionis: 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 John package it?

 What's the thing you're going to build? The “who” is that desperate user or that segmentation of the market that you're gonna go after. And then the how, which is how are you eventually gonna 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” — the original “what” that you were gonna build when it came to Traceable?

‍

Jyoti Bansal: The “what” was inspired by my previous experience and Sanjay's previous experience at AppDynamics — the ability to instrument and watch inside applications to bring this next generation of application security with API security as the technical inflection point. That was what we thought we would do. What we realized was that it wasn't the right “what.” We were biased because that's what was very successful for us from the performance monitoring world, the ability to instrument and watch the applications completely from inside by watching the run times of Java programming language or dot net or PHP or Node JS and all that. And that's the technology we started building. That is the what, 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 dialogue, what we realized was that's not enough.

‍

For the security folks, the friction of instrumenting and watching the applications could be much higher than the value right away. 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 meaning you need to protect them. That a hacker is trying to hack an API. You have to protect it. What we realize is the market is still not fully there. In people's terminology, what they think  securing means is 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 there are. I don't even know what developers have built out over time. We don't even know who uses what, so the first stage of security is protecting them. It's just understanding what the APIs are and like 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 a bit more proactively? And then the third stage is you are protecting them in runtime. 

‍

So we started with our understanding that securing means protection. What turned out was that our technology approach that you go and instrument these applications and code from inside is too heavy-weight for the first phase, which is discovery and catalog. So there was a disconnect. We realized that we need to change our technology approach and augment our technology approach. That is not just about bringing a lighter weight approach for the discovery and testing that doesn't require people to instrument, and that people need to do in an easy way, to plug it into their applications so that discovery and cataloging can be done in hours and without much work involved from the engineering teams. So that was definitely the evolution of what we thought, what would be and how we have to go through it. The “what” became a three pronged journey for the customer and the technology approach that we had wasn't the perfect fit for it.

‍

John Vrionis: 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. You talked about speaking to customers, which brings us to the who. So you had initial insight about who might be most desperate. That's the word we like to use at Unusual because only desperate people buy from start ups. Can you talk a little bit about that customer discovery process and who you spoke to and what you learned in terms of who might be desperate for it and who maybe wasn't that you thought would be?

‍

Jyoti Bansal: Yeah. So, the assumption we had for 'who' when we started was that it would be mid-sized companies, completely born in the cloud, API-first, highly modern cloud-native architectures. That was the 'who,' and it intuitively made sense. So that's what the assumption is. The good thing is, as we teach at Unusual, we got to validate the assumptions in the customer discovery process. And I would say the Traceable team did a good job at it. Also, thanks to the Unusual Academy and the Unusual founder services, the team was embedded with us and going through the process. So our thesis was that the 'who' is 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 time in these teams, it's not a separate persona. It's that your software engineering teams are very security conscious, and they're also much more comfortable with a lot of data and the ability to analyze the data. That was our initial purpose. What we found in the discovery process is that's really not true. The people who really care about securing the APIs the most are larger financial institutions and larger healthcare services where compliance is a big factor, and where there are just more cyber attacks, cybersecurity attacks. It's that 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—you'll put your energy where there's just a much bigger prize to get in terms of what you can get. So, what we realized is that the more pressing pain is larger enterprises, especially financial services, healthcare, where compliance is a factor. People need to protect the data that hackers are trying to steal. There are requirements, and the impact is very high. That was an assumption change in our mind. That's where the pain was.

‍

And that reflected in the 'how' significantly, because the assumption on 'how' was that we'd build a very PLG kind of model. If you go to the fast-moving mid-sized companies, PLG is the right go-to-market model. That's how the product was designed. We had a strong open-source model as well, so we can go into this customer base at a high velocity, rapid kind of thing. What we realized was that wasn't the right market. Most of the revenue we were seeing, even when we were trying the PLG model, we realized that most of the revenue was coming from large enterprises who were really struggling and desperate about solving some of these API or security needs. They were mandated in many cases by the regulators, by their compliance teams, or by previous cybersecurity attacks that had happened, etcetera. So, the 'how'—the initial assumption on what we thought the 'how' would be—had a pivot as well. We have to pivot to more of a cybersecurity enterprise selling. And what we also realized is that PLG didn't work as well for us because, in cybersecurity, when you're selling to enterprises, the teams are very constrained. They're small, and they don't have the expertise or even time to download a free product and use it. And they are normally done a little bit top-down, where the priorities are driven by someone senior, a CISO, or someone on what the priorities are. Many times, they use third-party VARs to do even the evaluation because they don't have the expertise to do so. So, we started with a developer engineer, PLG-focused go-to-market assumption and worked towards that to a more enterprise cybersecurity VARs evolution of our 'how' our go-to-market. And what you can see, as we also talk about in the academy, is that they all go hand-in-hand together. The 'what,' the 'who,' the 'how'—you know, once the 'who' starts to change, the 'how' has to change. If you didn't adapt and adjust that, the business wouldn't have worked

‍

John Vrionis: 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. Mhmm. 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 an amazing growth mindset. Like, what advice do you have for people who are going through this journey just based on your own?

‍

Jyoti Bansal: The reality is that this is how startup building is, and this is where, for all founders, my advice isn't about being right. It's about being flexible and able to adapt to the right path.

‍

It's not that we're lucky on the few things we get right in our assumptions, and maybe we'll eventually be right. Those were some initial assumptions we had that, three years from now, two years from now, are starting to change, like what we saw in 2019, '20, and versus even today. But you have to be flexible enough to iterate, adapt, and change. There's no shame in it. My advice to founders is that this is your number one strength: if you can build as a company and as founders, find your path, adapt, change, pivot, and be very brutally honest about assumptions. Because if you're not, and you're holding onto assumptions that just aren't working, at some point, your business isn't going to survive.

‍

John Vrionis: In the pivots that you did, you talked about customer discovery in lots of conversations. Is that work that you delegated to someone else, your co-founder or sales? Like, how did you actually uncover and then come to these realizations?

‍

Jyoti Bansal: It's a combination. I like to spend a lot of time on customer discovery, personally. I've done, I would say, at least a hundred customer discovery calls myself. I was directly on the calls myself, hearing, listening, having these conversations. But my co-founder Sanjay, he led many of these, even more. We started to get some help from a salesperson to help with the meetings. Unusual Founder Services was a key element as well, a way to set up some of these customer meetings.

‍

And I always talk about how you don't want to spend most of your customer discovery on warm leads or warm intros or friendlies. You want to have the cold conversations because that's when you get the most honest conversation. When people will tell you, 'Yeah, this is a pain,' or 'This is not a pain.' We even actually sold to some companies that were not the right product market fit. These were the early-stage, like small FinTech companies, where they were excited about it. They bought the product for amounts like $20,000, $30,000, $40,000 a year. And as we went through this exercise and were co-building with them, we also realized that they sold to people who were 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 the majority of the money where we could build a very successful business (which we were able to do) is in enterprise. And these were the pre-product market fit customers, which is very strange, that we had. We used to call them, like, 'These are the eight customers which are in our pre-PMF experimentation category' who were excited about the problem and bought for small amounts. But we knew eventually they weren't adopting it fast enough because the pain wasn't desperate enough.

‍

John Vrionis:  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?

‍

Jyoti Bansal: I wish things were discoverable, knowable beforehand, but the reality is they're not. Again, anyone who claims they knew all the answers, they were most likely very lucky that all their assumptions were right, which I don't think is the case. I've done it three times. At AppDynamics, I had some assumptions that were right, some assumptions that weren't, and I had to pivot on those. Same with Harness, same with Traceable. No one can get all the assumptions right. And if you don't change, it won't happen.

And that's really, to me, the crux of this product market fit process: 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? The what, who, how—all come together. And then you have a product, a company, a successful go-to-market model that you can build around, and you can scale the business.

John Vrionis:  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, 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. Because that seems like that is the way.

‍

Jyoti Bansal: And it is hard and could be frustrating sometimes, but it's very fulfilling in the end that 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 start burning your cash away, that's why a lot of companies don't survive this phase.

That said, maybe if I do a fourth company, I would have maybe less privilege to do this, but at the same time, I do. I just say, this is how companies are built, and I'm a strong believer that this kind of flexibility is what makes us strong and not inflexible.

‍

John Vrionis:  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, ten years?

‍

Jyoti Bansal: The vision for Harness and Traceable combined now starts with what's happening in the world of software engineering. There are about 40,000,000 software developers in the world today. And if you look at the cost of a software developer across the US, Europe, India, China—everyone combined—it's about at least a hundred thousand dollars. That's about $4,000,000,000,000 that's spent on software engineering.

The reality is that about 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 to a very large company, it could be even 70% of the time. But it's about testing, building code, deploying code, making sure the cost is good, making sure your compliance, your quality, your scalability, and your performance are good. Making sure your security is good, which is a big time drain. That's 40% of the cost of software engineering.

And if you're talking globally, 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 of the productivity gain that software engineers will have. Also, more people will easily become developers now. Citizen developers with AI, software engineering will become more accessible. So we are seeing 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, governing, compliance—all of that becomes an even bigger problem. If you look at even today, a trillion dollars of software engineering time is spent on software delivery—all the work that goes into it. And our vision at Harness is to automate most of that with AI. Can we bring the 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 GPT. When Harness was launched in 2017 (the end of 2017), the headline in the press was, 'Harness brings artificial intelligence to continuous delivery.' This was 2017. So we've been building AI-based systems for DevOps since then. Not at that time, but we were at the forefront of bringing AI to DevOps. How do we get deployment validation automatically? How do we speed up your builds? How do we speed up your tests when you launch our CI? How do you do cost management? We've been at the forefront of AI.

And now we are taking all of that, and we are becoming the agent-tech AI platform for all the software delivery use cases, whether it's DevOps, FinOps, application security, quality, reliability, deployment, build—all the grunt work that the developers have to do, but they don't want to do.

And of course, there's a lot of exciting work happening on AI helping with coding. And I always talk about how AI helping with coding is amazing. But coding is actually the interesting work that developers like to do. What if all the non-interesting work that the developers don't like to do, which is taking up 40% of the time, we bring AI to that? And that's our mission at Harness. And a big part of that is security. That's where Traceable comes in. How do you create secure software? How do you deploy secure software? How do you make sure everything is secured all the way through the software life cycle?

So, we're very excited about where the business can grow. We have a sizable business now. This year, the combined companies will be north of $250,000,000 in ARR, growing north of 50%. There are few companies at our size growing at that rate. So we're very proud of that. And we think the momentum with the two companies coming together will continue to grow for the next many years.

‍

John Vrionis:  Amazing. Listen, I really appreciate you sharing the story, being vulnerable as always. I've learned so much from you over the years, so, appreciate being your partner in the journey. So let's wrap up with a few, 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?

‍

Jyoti Bansal: The advice that I just shared already, be flexible, iterate, validate your assumptions.

‍

John Vrionis: What's a book that you think every founder should read?

‍

Jyoti Bansal: Built to Last, Jim Collins. You know, it's the whole concept of building a great company, there has to be a vision and, and some kind of a visionary mindset about your company and 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 very helpful.

‍

John Vrionis: What's the secret to building a great team?

‍

Jyoti Bansal: For me, the secret to building a great team is that you try to hire the best people in the areas that you're looking at. And to me, I believe founders have to lean on their superpower. That's how great teams are built. If I have a certain superpower, I want to use it. And I want to surround myself with people who have different superpowers, other strengths that they are really good at, that I can learn from in those areas. And that's what I encourage. That's how you bring the right people.

The second part to me about building a great team is creating a high degree of alignment. That's something that a lot of times when I build a team, a management team, my focus is, can I create alignment so 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 how we're going to get there, short term today, and two years, three years from now. And once that alignment is there, the teams can just go and run themselves. And then you don't need to—they trust each other. They respect each other.

And now, the third thing that you layer on top of that is visibility and accountability. You have the right people in the seat. You create alignment and clarity around goals. And then you have ownership, accountability, and metrics and visibility that are shared across the team, not just with me, but with everyone on the team. So they share the metrics. There's a good amount of transparency. Interest comes in, and you have a good thriving team that can operate at that point.

‍

John Vrionis: What is the one soft skill for founders that you think is supremely important?

‍

Jyoti Bansal: One soft skill I'd call the ability to sell, or the ability to inspire, or the ability to get people to be part of your mission, your vision. Most founders come from technical backgrounds, product backgrounds like myself. And to me, it was very clear: the soft skill that I needed was to get good at selling.

As founders, you're selling everywhere. You're selling to people to join your team. You're selling to your customers. Of course, you're selling to investors to invest in you, and to all your partners—all kinds of people. You have to become good at that. And selling could be described as storytelling—of who you are, your company, the problem you're solving. It could be creating inspiration around it, but every founder has to do that.

‍

John Vrionis: 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 at Dynamics?

‍

Jyoti Bansal: One truth I wish I knew is that it's not easy. When we see success stories from the outside, it feels very glamorous. But when you start peeling back the layers, which I didn't know before I saw it, it's all about grit. It's all about determination.

Out of ten days, you'll have five good days and five bad days. And you need the grit to get through those five bad days. Otherwise, you won't make it. That's an important part, especially in the startup world, the entrepreneurial world. Leadership is all about having that grit and not thinking it's an easy, glamorous journey. That could be the outcome. But even for that outcome, you have to go through all the hard things.

‍

John Vrionis:  Amazing words of wisdom. Alright. Well, that's Jyoti Bansal talking about Traceable and the journey to product market fit.

‍