Transcript:

Brian: Welcome back to Experiencing Data. This is Brian T. O’Neill. Today, I have Nishkam Prabodh from Venture Guides on the line, Boston VC, ex-product person, right?

Nishkam: Yes, yes.

Brian: [laugh]. So, we met at the CDOIQ symposium, which is here in Cambridge every year, and I was not expecting there to be a panel with VCs there, and so I was excited to go to that session that you had there. And I grabbed you in the hallway and asked you if you’d come in here and talk to our founder-operator audience of people trying to create new data-driven products right now in this crazy AI filled world right now. So yeah, I would thank you for coming on, Nishkam. It’s great to have you here.

Nishkam: It’s great to be here, Brian.

Brian: Yeah. Tell me just for listeners here. You’re a Boston-based early-stage VC firm. Tell our audience, like, what kind of stages you work at and what your portfolio companies tend to look like.

Nishkam: Absolutely. So, Venture Guides, we are an early-stage venture fund focused on infrastructure software, cybersecurity, and data. This team has been investing in this space… investing and operating in this space… for the last 30 years. Created and ran this practice at Bain Capital Ventures, where in fact one of our partners was a managing partner, and we were early investors in companies like Rapid7, Sysdig, Dynatrace, Solarwinds, Archer Technologies, Turbonomic, amongst many, many others.

In fact, Turbonomic, funnily enough, one of our partners was going in the wrong direction. Our partner was invited to join as a leader, interim CEO initially, which became permanent, and a couple of years became about eight years, and they eventually ended up selling the company to IBM for $2 billion. A whole chunk of the team worked there. We started back in 2022 after Turbonomic had been sold. In our investing lineage, about 80% of our investments have had positive outcomes. That’s extremely unusual at the stage we invest in, which is seed and Series A. Typically, you see 20% companies having a success rate returning capital. In our case, it was 80%.

A further 40% of our companies had billion dollar or multi-billion dollar outcomes. That is even more rare. Typically, that number tends to be around 1% or maybe one-and-a-half. The few things that we do differently as a fund, so we’ve raised two funds, $216 million was the first one, $262 million was the second one. Of the 488 we’ve raised, $51 million has come from us as a team. That’s a GP co-invest of about 11% compared to 1% in the industry. We do that to keep our incentives that much more aligned with our founders. It creates alignment, which is something that we care about deeply.

Another thing that creates alignment is our operating focus. So, everybody on the team, you heard about, you know, the leadership team’s background, you know, a big chunk of the team worked at Turbonomic, but we’ve been CEOs, COOs, CFOs at multiple venture-backed companies who’ve, you know, gotten really good outcomes in our space, and we bring that operational to the companies we invest in, and we help them with things like recruiting, go-to-market, helping them figure out who their ideal customer is, producing collateral, and so on and so forth. And then lastly, we invest in very, very few companies for a fund of our size. You will see, typically, maybe 50, 60 investments from a single fund. In our case, we invest in 15, and the idea is if you’re really going to be helping them so intimately with all of the things that I mentioned, you can’t do that if you’re invested in 50, 60 companies. There’s just not going to be enough time and resources.

So, that’s the whole strategy that Venture Guides has built around. I came up in similar ways. I graduated as an electrical engineer almost a decade ago now, then a management consultant for a few years, then a product manager at an early-stage health tech company. Came here in the states for my MBA. Ended up becoming CFO and then co-founder at an early-stage company, and joined Venture Guides almost three-and-a-half years ago, and I focus on our security and data investments.

Brian: Got it, got it. Tell me a bit about when you look back at the track record you’ve had, especially in the B2B space and the data space in particular, what separated the companies that stalled? How much of this was, like, raw technology skill, like that the IP was amazing versus something to do with product or getting user adoption early. Like, is there a pattern that has emerged?

Nishkam: I would say the meta pattern is there is a belief in our industry that you know great companies are born that somehow, like, you decide on day one that this company is going to be great. And you see them raising, like, huge rounds, $50 million, $100 million seeds. We believe that every company goes through S curves, so they grow and they plateau out a little bit, and then they grow again. It is, in fact, you know, your board’s job and your investors’ job, at least partly, to help you through those S curves. In terms of patterns and what worked, what did not, I think every company, to the best of our ability, when we, you know, partner with them, we look for defensible tech, right?

There is a whole framework through which we score our companies so that it’s consistent, it’s comparative, it’s chronological, and you know, you look for decent markets. You look for defensible tech. You look for, sort of, you know, go-to-market efficiency, and so on and so forth. Still, I think we tend to partner with folks who are really, really good at the technical stuff. GTM tends to be a blind spot, especially for companies which are transitioning from founder-led sales motion into something that is much more repeatable and forecastable, that’s where you see a lot of the fall off. And in fact, if you see, like, the failure rate is highest in that C2, sort of, A transition range, that’s where I think, you know, people who’ve done this before can be really helpful.

Brian: So, let me try to play back what you just said. It sounds like defensible tech first, founder-led sales things are good. Founder needs to pull out of this so you can repeat the go-to-market playbook, you can bring a sales team in. Something happens at this point where the traction seems to slip off when the founder is no longer doing the selling. Did I get that correct?

Nishkam: Yes, right. I mean, conceptually, yes, absolutely. So, I think what ends up happening is you see the person who started the company has a vision in mind, right? They understand the customer’s problem intimately, they know what the solution gaps are in the alternates that are available in the market. It’s not always straightforward to transition that knowledge, that storytelling, that vision into the people that you then bring into your company, right, that deep, intimate understanding of this is who our customer is, this is who we call an ideal customer, this is what their problems are, this is how it relates to their business use cases. And then, even if you have the best technology in the world, it becomes really hard to explain to someone on the other end who’s never heard of this, if you don’t have that domain depth. And it’s that transition, I think, that is quite challenging for early-stage companies.

Brian: Got it. So, when you talk about, like, so translating… I literally talk about this in my own company, translating technical complexity into commercial clarity… is the issue here that the product is not selling itself? So, especially since we’re talking about software here, the product, the experience of the product, is not from you know website to product itself, that’s not doing a good job expressing its own value, like, say in the POC phase, or is it literally messaging? It’s market positioning. It’s… which aspects of this, like, amazing tech that does 25 different things for your business, what language do we use to talk about it? Is it more in the positioning and the selling, or is it more in the product itself where there’s this gap that the founder was filling on you know on a phone call, but when it stands alone, it falls apart? Where’s that gap?

Nishkam: I’d say maybe it’s across, sort of, three different work streams or verticals or ways of thinking. First is the focus, right? You’re an early-stage company, and take your pick. Say you’re selling, I don’t know, GRC software, Governance, Risk, and Compliance, or I don’t know, data engineering, right? Say your pipeline looks like it’s eleven different sectors, five different revenue bands, seven different geographies. You don’t accelerate learnings across different customer prospect conversations, right? So, you’re not learning from every conversation and saying, “Okay, I understand intimately not only why this buyer wants our software to solve a technical problem, but also how this relates to their business.”

Right? So, I mean, again, take security. Why do people buy cybersecurity? It’s for risk reduction. Why do they need to do risk reduction? There is usually some mandate coming from your board or from your CEO saying, you know, we need to adopt AI, but we need to adopt it safely. We don’t want any incidents, we don’t want to be on the front page of The New York Times, you know, we don’t want any breaches.

And what we see a lot is sometimes your seller will do a really good job of explaining that how you solve this technical problem with our product, but they don’t always do a great job of explaining how does this technical problem correlate with your business use case. And when that handshake is, kind of, broken, it becomes more about technicalities. And there is always going to be another competitor who can come in and say, “Oh, we solve that plus something else,” or, “We solve that; we do it cheaper,” “We solve that and, you know, do it faster,” or something, right? So, the more you make the conversation about use cases and technicalities and less about the business use case, the harder, kind of, it becomes to communicate value.

Brian: Got it. But I guess my question here is, is the value communication problem is this happening asynchronously? Meaning, the value is not being communicated at the time the customer is, say, in a POC, and like, all the stake, like, management… you know, let’s say it’s customer support software with automated bots, you know, answering phone calls, there’s a manager that’s looking at the overall queue of calls and efficiency, call time reduction, all this, maybe there’s human call center agents that are working with the bots who care more about individual call remediation, there’s a fiscal buyer who’s looking at, like, are my costs going down? Am I getting less calls or am I resolving them quickly? What’s the dollar value of this given what it costs to bring in this software?

There’s a data team looking at, you know, regulatory compliance, whatever. Some of that can either be in the product itself, in the experience. Do you have the right surfaces for the right user types, like, that need different things out of the software? Versus this is happening in the sales call, in the marketing, in the sales conversation, it’s dying way upstream of the POC. Where do you see that gap, that communication gap, falling? Is it in the product or is it in the sales in the conversations?

Nishkam: I mean, that’s a great question because, and I’m going to give you a non-committal answer.

Brian: The answer is yes [laugh].

Nishkam: Yeah, the answer is yes, right? It tends to happen. I mean, of course, the biggest fall off is, like, you get somebody on the call, they don’t even want to see a demo, right? Like, that’s where the biggest fall off usually is. Which is fine. Not everybody is going to be a buyer. They might not have the budget authority, or timing might not work out right.

But say you clear those hurdles. Say now you’re, you know, involving your account executive, your sales engineer on that call. So, your company is actually putting some real resources behind this sale. That’s where the fall off really hurts, right? Otherwise, you got somebody on a call, they didn’t like it. It’s fine, drops off. You didn’t put that much time into it.

But now that you’re doing a demo for them, maybe you set up a POC for them. Communicating value in that stage, I think, is really crucial, and that’s where the whole conversation I had about you’re not just solving a technical problem, you’re solving a business use case becomes that much more important. But the fall off absolutely happens much more so on the earlier stages, percentage-wise, less so on the latter ones, but the latter ones tend to hurt that much more.

Brian: Sure. I sometimes talk about this, like, buyer experience, right? And the buyer here can be multiple stakeholders who are, you know, vetting the product from different angle with compliance or end-user experience, again, the executive oversight, all of that. I’m particularly curious, like, for, like, say your cybersecurity plays and your data plays that you’ve had in the past, I’ve seen a lot of technical products like this where, you know, “We can do you know red-teaming of your models and we actively will have bots out there trying to exploit your models and look for you know security holes and all this,” so they get really into the technical weeds about all the things it can do to find holes.

But then there’s, like, the question of, like, well, what’s the value of plugging all these holes or doing root cause investigations into hacks that came in? The technical part is where the founders often live is, like, how to technically solve all that or automate it and show the lineage and how they came up with the recommendations and all this, but then there’s the what’s the business value there, so that some buyer can justify this to a procurement or budget holder. Do you have any stories there you could talk about, like, closing that gap? And I’m assuming there’s a gap here from just what we’ve talked about so far, that sometimes there is a gap here.

Nishkam: Absolutely [laugh].

Brian: [laugh].

Nishkam: Not to sell our own portfolio, but we do have a company in our portfolio that does automated red-teaming and successfully communicates business value. No, but you’re totally right, Brian. So, I think a lot of it is, first of all, a function of who you’re on the call with, and I mean this with the utmost respect, but there are people in the organization who make the purchasing decisions, and then there are people within the organization who are users of the product. So, a difference between buyers and users, and especially executive buyers, you know, the people who actually are on the operational end of your product. So, you’ve got to be in front of the executive buyer as early as you can, and there is a separate conversation that happens with the user, and a separate conversation that happens with the buyer.

The buyer is not going to be in the weeds, right? Your CDO, your CIO, your CISO, like, they care about very different things than what your directors, VPs, and managers care about. Your CISO cares about… I mean, they are under pressure, right? To the example that I quoted earlier, their CEO has, maybe in their earnings call or, you know, public-facing materials have mentioned that this is the company’s strategy, this is what we are trying to do, say adoption of AI, and we are trying to do that safely. It is the CISO’s job. The safety part is the CISO’s job, right?

And there is a pressure from your board, from your regulators, from your CEO, and there are certain business mandates that the CISO has to meet. That then flow into the CISO’s direct reports as technical use cases, right? Your product, of course, has to clear the barrier on both technical use cases and business mandates, but the conversation you have with your CISO, better be about those business mandates and not about those use cases, right? That’s where I feel, A, either you’re not at the right level, right? You’re either having a conversation with someone who can’t make that purchasing decision, or you manage to get to the right person, but you’re telling them the wrong story.

Brian: Yeah.

Nishkam: Again, very, very common mistake. And I could yes give you a thousand stories there, where… I mean, this example that I’m quoting of AI safety, it’s actually from a real company, a real live conversation, and the company that I’m thinking of… not a portfolio company, but you know… ended up making that mistake of really getting into the weeds of, you know, this is how agents work, we collect traces from here, and then you know, we put them in a knowledge graph, and your CISO neither understands nor cares, and they, sort of, lose their audience in that process.

Brian: You have a product background, right? So, I’m curious, how do you advise your portfolio companies here? Like, I look at that and I see that this is a product and a fundamental design issue because what you haven’t done is thought… you’re not aware of all the personas who are in the loop here as part of the buying experience, and so maybe you’ve spent all your time on the end-user who’s doing, like, the red-teaming of the… like, some data person or machine-learning engineer or data scientist who’s in charge of, like, the red-teaming of the models, for example, but no one gave any intentional thought to where is the Chief Information Security Officer, the CISO, or another compliance person, what do they need to see? When do they need to see this or experience it? Or how easily can you know a person down the chain get that person what they need from this POC that they’re doing, literally, there’s just not even been a discussion about this person or any direct product effort towards that because they are not a user of the software. Like, how do you advise your companies? Is this, like, product management 101, or, like, I’m curious, especially with technical founders who tend to lead a lot of these types of products.

Nishkam: You are right. A well-built product will answer a whole lot of these questions, and increasingly, I think with you know what AI has done for our industry… and I spoke about this in the panel we met that, you know, people tend to be moving away from this product gives me outputs and to this product actually accomplishes certain outcomes for me. Like the difference being, an output is something that you take and then, sort of, you know, take to completion to achieve an outcome; an outcome is basically something that you’re happy with, an end product. And your product in its UI, UX, in its functionality should communicate as much just where we are today.

Yes, it’s about design, you know, as few clicks as possible. Yes, it’s about deployment. You know, you want to get the customer to value as fast as possible. There is a whole bunch that you can prove out in the POV if you do this hard work, like for example, getting credentials or getting internal IT approvals. The sooner you can parallelize that process, the easier it makes for you to sort of demonstrate value.

But back to your product question, yes, absolutely, especially for some of these top-down enterprise sales, as few clicks as possible, and as clear a dashboard that demonstrates an ROI as possible. And ROI has got to relate back to either this is how we improve your revenue, reduce your cost, or reduce your risk. And I don’t know if that answers your question or not.

Brian: Yeah. Talk to me maybe about how that’s, like, resourced right now because, with all this AI stuff, there’s all kinds of opinions out here about what’s happening with, like, where do we invest our money in human capital versus getting agents to do work. I’ve seen everything from, like, product management is so much more important now because delivery is no longer the bottleneck. I’ve also seen, you don’t even need product people anymore. Engineers can write requirements documents themselves, and because we can build fast, the learning cycle is so much shorter. We don’t need product management.

Same thing with design. Like, oh, now we can build GUIs so fast with the tool. On the other hand, people are saying, like, now judgment really matters if you don’t want to just produce average stuff and you really can’t generate user experiences. You can just generate user interfaces. It’s all over the map here.

So, given the gaps that you’ve seen here with the communicating the value to the right person at the right time, what skill sets in human capital do you find is essential, or I don’t know if you have, like, a playbook where it’s like our portfolio teams, we really recommend you know for cybersecurity and data teams, you really need these core you know disciplines on your team. These are, like, non-negotiables. Or maybe just talk to me a little bit about where the, like, human talent is really important, and where you’re like, no, I think machines. My teams are doing really well using machines to do that kind of labor and skill?

Nishkam: Oh, boy. Uh… [laugh].

Brian: Sorry, was… [laugh].

Nishkam: No, no. I mean that’s… I mean, you are asking me about… I don’t… first of all, I don’t think anybody has a good answer to that question. I think it’s changing so fast. What you thought was value-added and what you thought was business critical, AI seems to be, sort of, traveling so fast on the skill ladder that increasingly the skills that I would say were relevant, I don’t know, definitely five years ago have become commoditized, maybe even two years ago have become commoditized, right? So, to anybody, not just product managers, but just because I’ve, sort of, been in that function before, product management is about a lot of things.

It cross-functional collaboration, it is about, you know, producing collateral [laugh] with clear communication, it’s a little bit about project management as well, and I think ultimately yes, you do need technical understanding of, like, how do you translate something that you learn from the customer into something that you know can be reasonably built in a reasonable amount of time with a reasonable amount of resources with the constraints that can be expressed with technology and engineering. You sort of already hinted at it. The more your job is oriented towards judgment and actual critical decision-making, the more you are quote-unquote, “Immune” to AI one day, sort of, obviating what you do. If what you’re literally doing is, you know, taking information from a whole bunch of disparate resources and sort of synthesizing it into something that is more readable, consumable, I think we’ve seen how AI can do that better than a human already. If your job is mostly about getting people together in a room, we have seen that AI tends to do a fairly good job already of those kind of things.

If your job is more about judgment, looking at data, which is going to be incomplete, which is never going to give you, you know, again, quote-unquote, “The objective right answer,” and you’re supposed to make a judgment call with incomplete data, the more you’re oriented towards that, I think the more irreplaceable you are. And that’s, when it comes to product hires at least, is as part of the recommendation that we give to our portfolio companies. Like, look for people who’ve done that, who’ve demonstrated that, who are willing to do that, and less so people who are more about project management, which is, you know…

Brian: Do you think the… I guess I could generalize this too… especially for these technical data products and things of this nature, is product management still an essential role to have in these organizations, in these startups that you’re helping fund?

Nishkam: I’m going to try and take the, sort of, judgment out of this because I, honestly, first of all, I’m scared [laugh] that I might get letters…

Brian: [laugh].

Nishkam: But also, like, I don’t know for sure. So, here’s what I’ve actually seen, right? Typically people used to hire a senior product manager at, you know, starting the Series A stage, when you’re beginning to have some product-market fit.

Brian: Right.

Nishkam: I see more and more companies delaying their first product hire because initially a lot of what, you know, especially if it’s say not a VP of product management or a head of product management, it’s more someone that is doing the legwork, that is, you know, more and more subsumed within the engineering function, or your CTO can do it, or you know, even someone who is running operations can do it within the company. So, that hire is getting more and more delayed. When they come into the business, I am seeing a higher premium placed on domain experience. So, if you’re a data company, you tend to hire people who worked… or you tend to hire product people who, you know, done data work before, and similarly, observability, resource management, and so on and so forth. It’s because if the job is going to be more about judgment and less about, you know, producing collateral and scheduling, it helps if your ramp period is going to be lower within this space.

So, I guess it’s a long-winded way of saying I think the days of the generalist product manager are numbered and domain experience and slightly more… the floor has shifted, I guess, and I guess that hopefully sort of answers the question. The three themes are basically it’s getting slightly delayed, it’s getting more and more oriented towards judgment, and you know, people are prioritizing domain experience over generalist capabilities.

Brian: Got it. Got it. I guess the model that I think about here is, when you have limited resources, how are you deciding what gets love and what doesn’t? Like, for example, should we be creating a, you know, a dashboard for the CISO? Like, we need to, like, have an aspect, a control surface for the product that’s really only there for the POC to convert. The end-users are never going to care about this, but it’s highly relevant. You know, we have this hole in our buyer experience that needs to be filled.

And then your founder might say, “No, no, no, no. We’re trying to do, like, support Linux as well as you know Windows for our red-teaming software, and we need more core product work going on.” Someone has to decide what engineering is going to work on. What is the most important product work to happen right now? And to me, that’s a judgment skill.

Whether it’s titled as a product manager or not, that’s often something I see there’s not always a lot of discipline in this space, and the with technical founders, the work tends to be more on building more product, building, making the product better, but not necessarily addressing the feedback, the learning they’re getting from the field. That doesn’t get addressed as much. So, I’m curious if you’ve seen that as well, or not so much.

Nishkam: Yeah. So I think that had sort of two questions rolled in one. One is kind of like functionality versus dashboarding and reporting, right? Like, just how many more features do you have versus how do you present them.

Brian: Yeah, I mean, whether it’s a dashboard or not, the point is, like, there is an unmet need here, where, like, someone in the buyer loop or during the POC or whatever, someone’s needs aren’t being met, and it’s causing the sale not to go through, or the user adoption of the product isn’t there, like, it dies internally for whatever reason. There are unmet needs, and who’s deciding? A, who’s even aware that those unmet needs are there, and whether or not they should get attention from your limited you know, engineering resources that you have and all that kind of stuff?

Nishkam: No, I do appreciate it, and, of course, there is no silver bullet, right? I mean, think about it, right? Like, if you are an early-stage company which is building dev tool and your go-to-market motion is, you know, someone swipes a credit card, gets your product, maybe it’s open-source, you care very little about, sort of, how the value is being communicated on a sales call because there is no sales call, right? So, when I’m answering this question, I’m thinking this is a top-down sale, B2B enterprise, you know, typically someone in the C-suite. If that’s who you’re selling to, I think again, you know, sort of, a thin balance sheet, you’re trying to spread your resources wisely, you’d better, sort of, prioritize things that your customer wants first.

And it is so crucial in those early days when you don’t have product-market fit, when you don’t know what I’m building, is that going to resonate with buyers or not. And don’t get me wrong, there are some founders out there who are a little bit ahead of where the, sort of, even the buyer is, where the market is generally, and they will say, “I can do that consultative selling and I’m going to tell the buyer this is what they need,” and they, in that process… like, this is the old Steve Jobs kind of a founder, right, like who actually, convince the customer that you didn’t even know that you needed this, but that’s not the sort of generality that you build for. So, if there’s an executive buyer on the other end, you don’t know if your product is going to resonate with them or not. You let the aggregate feedback guide what you build. You ideally pick a design partner… this is in the very, very early stages… you ideally pick a design partner or two, you meet with them weekly, you gather as much feedback as possible, and yes, from those conversations, learn where your buyers’ eyes are going, right?

And you will see, Brian, in that conversation, like, do they care about whether we have Linux coverage or not, or do they care more about, like, how this product is communicating value, right? It depends on the domain, it depends on what you know what your GTM motion in long run is going to be, but typically, the answer ends up being that in those early conversations, they tend to care a little bit more about, you know, how the value is being translated to the business use case and less about whether this is feature complete or not. Like, they know they are buying product from an early-stage company, it’s never going to compete with and Databricks in terms of feature parity.

Brian: Right, right. Let’s shift here for a moment. I wanted to talk to you a little bit about moats right now, particularly for data products. Like, how are you guys thinking about those and leading up to that is probably this buy versus build conversation. I’m imagining with everyone, both the software vendors that your portfolio companies using AI to do a lot of coding, there are also data teams… I’m talking to a guest coming up about literally, they’re having a competition between vendor tool or internal build, and what’s going to win? Like, we’re going to look at the value created, and that will help us decide whether or not to buy a solution. So, what are you seeing in the buy versus build thing, and how does that translate to, like, moats that you might be thinking about? How do you protect your… create a fiefdom?

Nishkam: So, let me address the buy versus build first. Last year, if you remember, this report came out from MIT, which kind of talked about how 90% of enterprise deployments failed. That’s no longer the case. Like, that’s, you know, increasingly changing. If you dug deeper into that report, you’d realize that two-thirds of the projects that failed in their sample set were projects which were internal, and the ones that succeeded, the disproportionate majority of that was buy-not-build.

So, just one, sort of, data point when you think about the buy versus build decision, it’s a bit of an obvious thing, but AI has definitely reduced or compressed the timeline from an idea to something that is minimum viable, like, a demoable product, but something that runs in production, you know, doesn’t require or requires minimal maintenance, and so on and so forth, I think we are still in the first innings of that, right? So, just because you’re getting to code completion with AI doesn’t mean that you have a product that, you know, whose output is verifiable, is going to work in all generalizable cases, and you know, so on and so forth, it’s secure, et cetera. Et cetera. So, that’s just one aspect of it.

At the same time, I will concur, if your product, especially in the CDO world or data world or codegen world, if your product is doing something that, you know, Claude can at least… or Claude or Anthropic, I’m using Claude Anthropic, OpenAI, or whatever… can produce you know 80% of that, 70% of that, at the very least, it’s going to increase sales cycles, right? If your buyer is going to consider build, what it ends up doing is, even if they don’t succeed with their build, it tends to increase the sales cycle, it puts pressure on, you know, the ACV that you can get from your customer. These things suck the energy out of the room and that’s sort of the number one problem I’m seeing companies, which are building in spaces that Anthropic or OpenAI directly compete with, face. Now, the competition between buy versus build and sort of moats from that perspective, look, the conversation about moats has changed completely, I would say in the last six months or so, even for us, right?

Like, the way we used to think about moats was static, right? Like, there is some engineering complexity in your product or some architectural choices that you’ve taken that give you a head start, right, that keeps you ahead of the market for 18 months, and hopefully you continue to make those choices and stay ahead of the market. So, the conversation about moats has changed completely in the industry and also at Venture Guides. We used to think about moats as something that was static, right, like, some engineering innovation, some architectural complexity, some proprietary data that you had access to. Some of that still applies, but we feel that moats are so much more fluid now.

And what I mean by that is, first of all, you need to have some kind of post-deployment, I don’t know if moat is the right, but some kind of defensibility. Once you’re in an account, you need to have some kind of recursion in your product that is providing the customer more value on day two, day three, day thirty-one versus day one, right, the idea being that you’re learning from the customer’s context, that your software is getting more used to their way of working, rather than the other way around. And it’s a mentality shift because that’s the way software is operated for the longest time, that it’s the users that learn how to operate the software, not the software learning how the organization operates, right? So increasingly, we look for that in how we underwrite tech, right? Like, is there something in this product, is it learning the customer’s context, is it generating proprietary data that again, like, resides at the customer, but which helps the product provide more value to the customer the longer it stays deployed?

Of course, that is not to say that we ignore the, sort of, architecture and engineering complexity pre-deployment, right? We do look for those things, and we work very hard to understand, you know, what is it, where is it that the founder, you know, took a right when the rest of the world was taking left? What is the insight? You know, what’s their vision of the world, and how is that reflected in the engineering and architectural choices that they made? But it’s just a different lens, that moats are no longer static and you have to think about how do you provide more value in the long run? Does that answer your question?

Brian: Yeah. Do you have any concrete examples, like, on the, like, showing the value… I like this idea of, like, showing the value day two and day thirty, especially if the customer’s whole headspace right now is, like, day one, burning problem. I heard you guys are solving this. My CEO has a bug up his pants about this. Can you guys do it? Oh, you can. But they’re not yet think… maybe they’re doing the buy versus build, maybe we think we can build this in house, but let’s see what you that you guys have cooked up.

You’re trying, as the founder, you’re like, yes, and we solved that. Yes, and we also will have the audit trails, so you know, when the police come and look into investigating this thing, whoever the police are in your particular domain, you’re going to be able to go and defend your AI’s decision to automate something that happened down the road, which you probably aren’t thinking about right now as you do your internal build competition. We’ve thought through all that. Do you have any concrete examples from your portfolio companies that have done that or, like, actively thought about that as a design problem and addressed that?

Nishkam: Absolutely. And I mean, you actually touched on one of those, like, this idea of provability and auditability, right? So imagine, sort of, an outsourced data engineer, right, they were doing some kind of data… this was before AI was there, right… so they were doing some kind of data movement. Something triggered that action, right? Like, there was a Slack message from someone you needed to move this data from this source to that destination, that data movement is not always well audited. The reason it happened, the reason you interpreted a particular field a certain way, that alone, you know, sometimes generate an incremental value.

But let me give you another, sort of, more concrete example about context. Everybody is trying to chase the reason behind something happens within the enterprise, and you know, it’s part of what we mean by context, and… this is a live example… revenue gets interpreted differently within different teams within an organization, right? So, if it’s the accounting organization, it’s cap revenue. If it’s a sales organization, they probably mean ARR, which is going to be treated slightly differently. Now, if your agent has a way to capture this feedback from the users that are prompting it, it produces better outcomes for those users, right? If the audience is accounting versus sales or finance, interpreting what they mean by a certain thing based on the rules inferred rules of this organization increases the acceptability of your outcome. That’s one example.

Knowing… and this is very commonly stated… knowing why you know a certain healthcare customer was given a discount and you know a certain technology customer was not, you know, from the organization’s context, is another example that improves the acceptability of the outcome that your agent is producing for you. Does that kind of answer your question?

Brian: Yeah, and on the buyer side, is this something where you feel like the buyers are actively pursuing that as a value that they seek, or that is a sweetener that they’re not really thinking about that yet, but it’s like, oh, I never thought about that, but yeah, it would get better at this, or over time, this would compound… I actually call one of my three moats, my model here is this compounding institutional knowledge moat, which is what I think you’re talking about… are the buyers actively seeking this, or is this something that’s a value-add that the founder or [laugh] the sales team sort of has to introduce to them as, hey, have you thought about this longer-term?

Nishkam: That’s a great question, Brian. And I mean, your guess is probably as good as mine here. Because when I speak with some of these customers… and it’s a big part of, by the way, how we figure out where to invest, and we go and speak to customers and ask them what’s keeping you awake… when I have those conversations, I don’t think that’s exactly the way I described it, or the way you described it, like, that compounding value-add is how the customer perceives it, right? Because they care about…

Brian: Institutional knowledge. Yeah.

Nishkam: I mean, just like, I wanted an answer to a question: did I get it or not? How much time did I get it, right? Like so, their evaluation criteria tends to be much simpler, but the technical complexity that goes into you know actually providing that simplicity is what they perceive… or is what they never see, but is what makes the simplicity actually possible. Does that make sense?

Brian: Yeah, no, I understand what you’re saying. Yeah, they’re operating on a more basic level, but I guess the spirit of the question here is particularly when you have an army of engineers at your side and you have smart internal technical people on your team, I think there could be a perception that we could build some of this stuff in house and some of that longer-term value or the consistency that the answer is going to be right, and it’s going to be right in the context that this employee needed at this moment, for example, if you’re some kind of answer engine or whatever it might be, it’s hard to evaluate whether you’re getting that internally. Like, they’re probably not doing a long-term study to understand, are we right enough most of the time for the most important people in the org? The vendor is probably thinking very much about the accuracy of the data as being essential because the trust can be broken so quickly there. So, I’m kind of just curious, like, how to balance this thing where it’s like, you’re never going to have a perfect product. How much are you going to put all your resources into that, especially when the buyer is evaluating on a very surface level and doesn’t even know what it doesn’t know about, all the rat holes and places this could go wrong, and the audit trails and the downstream stuff that might become really relevant sooner than later.

Nishkam: [laugh] I have also spoken to customers who’ve tried, sort of, building themselves, and I mean, you should hear the frustration they feel when they see their Claude build and they do, like, the time it took to produce, like, I don’t know some presentation deck or some data movement from here to there, it should not have taken that much time. It should not have taken that much cost. And you see, like, if you ever click on when Claude says ‘thinking,’ if you ever click on what it actually is thinking, right, and where it’s… if you’ve connected them to a few repositories within SharePoint, your mind jumps to why are you going there? The question I ask has got nothing to do with that, right? So, why does Claude… I mean, it’s almost like, and I’m giving you a very, very basic answer, but this is from my perspective as a user… like it always starts from scratch, right?

Like, the whole concept of caching isn’t quite there. The concept of, sort of, token management, I don’t think it’s in their best interest to, sort of, figure out okay which model should be used for what thing. Should we probably be caching some of this information that’s going to be repeated across this organization a whole bunch of times? That’s what a good harness does for you. And we somehow didn’t mention that word up until now, but…

Brian: Right.

Nishkam: … the model, yes, is kind of like the, you know, thinking brain, but the memory, the retrieval, the harness, the tooling, the skills, like, that’s what a good product builds around all of that. And increasingly, this model capability, as bizarre it seems to say, is going to get commoditized as open-source models catch up, and the whole value is going to move towards all of this other stuff, and I don’t know, I hope your readers relate to this. I, as a user, certainly do because that is perceived by the buyer, right? Like, they might not have the language or the framework to describe it yet, but if you speak to the individual users and the buyer who cares about that bill will tell you that this is quite frustrating and somebody that solves that, they’ll be willing to purchase from.

Brian: Yeah, yeah. Nishkam, thank you so much for coming on here. Do you have any, like, closing thoughts? You know, if you could get every technical founder to invest in one, you know, unglamorous thing, perhaps that reliably can move the, you know, user adoption, sales movement forward, things like that, what would you recommend? Is there a theme, a message that you feel like the people aren’t getting, [laugh] founders aren’t getting, and they need to hear this?

Nishkam: I mean, founders have a much more difficult job, so what I’m going to say is, you know, might sound obvious to a whole bunch, but customer-centricity and focus. This is early-stage company. You know, if you’re a founder and you’re trying to figure out what to build, focus on your customer, and then please, please keep it focused. The, sort of, wider you go initially, the harder it becomes to crystallize what’s signal from noise. So, pick one customer, pick one industry, pick one revenue band, and just build repeatability there before you, sort of, branch out and start worrying about coverage and you know repeatability.

Brian: Got it. Got it. And just to clarify, since you know, I’m so customer focused in the work that I do here, when you say that, what I think you’re saying is vertical positioning, or, like, get it right for the CDO. Don’t try to also sell into this person and to a security officer. And this went, like, the CDO is evaluating on this, and you know, pick a vertical slice as well… real estate. Like, don’t try to be for financial services and for healthcare and for this, but rather, get really specific before you broaden. Is that, kind of, the message?

Nishkam: Absolutely, Brian. Yes [laugh]. I would go even a step further. Like, even within healthcare, pick one revenue band where I’m going to serve customers which are typically this size, and I’m going to pick one geography, and just go from there, right? Because that’s how you build a flywheel, and that's the number one mistake that we see founders make.

Brian: Awesome. Nishkam, where can people follow your work? Is there a good place to just follow your writings or thinking and that kind of thing, get in touch?

Nishkam: Typically LinkedIn, and please go check out our website. A lot of the things that I talked about our values and our frameworks, and the help we provide, ventureguides.com, you can find all of that there, too.

Brian: Cool, awesome. Well, I will put your LinkedIn and the website for the company Venture Guides in the show notes here, so thank you so much for coming on Experiencing Data.

Nishkam: Thank you.