When Build vs Buy Is Rigged: Selling to Enterprises That Prefer...

All right, nice to meet you all. Um, getting started as uh founders, it's our job to sell to enterprises. Um, but uh many enterprises especially security teams uh have a build culture. these two sometimes uh clash and uh create headwinds for growth as founders uh especially for early stage startups. So today I'm just going to go over um some of my experiences uh with respect to that subject. Um the premise of the talk is that usually as founders your uh most uh fierce competitor is not another uh security startup but basically that internal build uh in-house culture that some companies have. Essentially it's that script that someone some security engineer built a few years ago. They may

have already moved on um but the company and the organization is left with that. So, how do we position oursel against that? Um, and how do I know that? Um, I'm a second time founder. Um, started a company back in 2018, sold to Fortune 100, um, uh, government organizations, other security firms. Uh, have some battle scars in this space that I would love to share with you all. Um, and, uh, basically want to go over uh, a few different subjects here. So the most important takeaway that I want to leave you guys leave you all with today is that you are not selling to an organization or a company. You're selling to a human. Whether that's the

CISO, whether that's the security engineer, um the software developer or CTO. Uh that's the most important lesson that I've learned through the years. uh you need to have that um understanding of their motivations, background and what they're looking for in that sales motion or that buying journey essentially. And once you understand that, the next next most important thing is to really know your customer, understand the personas behind uh those individuals. And um again in security um through my experience I've realized that there are three primary personalities that you are facing especially in uh internal tooling or build in-house organizations. Uh the pragmatist, the hero and the strategist. The rest of this talk, I'll go over each

of uh these or these personas and I'll give you some playbooks and practical lessons that I've learned through the years um to how to position yourself when you are communicating with these different personalities. So first one with pragmatist their most important um uh priority is to keep things flowing with as little risk as possible. So change is considered disruption for them. So they will always ask a question of do I need to make this change now? Do we need to create this disruption? Is this going to be disruptive or not? And so you need to kind of understand that motivation behind how they are thinking. They need to understand or they need to make sure

that this new tool saves time without adding complexity. So they're always working through these trade-offs of complexity, timesaving, uh value, uh ROI and so on and so forth. Um so they're in their head the buying journey that they're going through looks like this. By the way, um I was inspired by Gartner's uh B2B uh buying journey. I think Giana, another presenter in this room, uh shared the original slide earlier today. It's a really cool slide to look at. It's super uh heavy and dense. Uh but in this presentation, I'm trying to kind of condense that into the specific personas that we are dealing with. But really for a um for a pragmatist, the very first question

they're going to ask is that can we technically build this in house? um that's going to change the direction of the rest of the conversation. If we can then do we have the headcount, do we have the resources to do it or not. Um essentially they're going through the entire journey of seeing if it is feasible technically and um from a resource perspective to build it in house or not before they really commit to buying it um um basically from a third party vendor. And your job as founder is to show them that delay and waiting is not neutral. Uh they're exposing themselves to um revenue growth uh issues or revenue block. Um they're exposing themselves to compliance and

audit and security risks and engineering opportunity cost. Just a process of exploring the options, exploring the physibility that takes time and resources and you need to kind of you know show them the fact that they are expending uh resources that could otherwise have been solved by going through uh the buying journey from a third party and so that's kind of the messaging that you know really helps um break through with a pragmatist personality. One really powerful tool that you can use is uh help them do an ROI analysis and each organization is going to do ROI analysis differently. So you need to work with them. You need to help them really understand what they are gaining

um versus you know what they are spending on on your software. um things that are more most important to pragmatist um personalities low on boarding disruption uh low workflow disruption and low integration degradation. So the most important items are for you the cost of on boarding and trying the product is minimal. They're going to make it as easy as possible. Again low risk, low disruption. On the other side you're not going to get a service disruption. Uh your engineer doesn't need to you don't need to on call engineer once you grow the software from you know using internally by one department to to many more departments. I know this personally uh one of the tools I built at a previous company

myself uh was started to be used by only a team of four over the course of a year the usage expanded to a team of 400. So for me you know as a single engineer to maintain that um initially I thought I'm going to answer to maybe four engineers going that from four to 400 changed the whole game now any disruption was catastrophic for the company I had to go to engineering team and get more resources on call engineers and so on and so forth and that kind of journey was um a really I think eye openening issue for me and one of the messages that I also try to um to communicate uh to companies when I'm talking to them.

Second personality is hero. So for a hero technical leadership is really important. These are kind of you know the engineers who take pride in their technical ability uh not just internally but also show it to the world. What they want to um make sure that they keep access to is flexibility, visibility and ownership. And so the questions they're going to ask is that um is this new solution is this third party vendor solution technically superior to our own tool um and does this uh free me up to get to work on more interesting stuff and so it gets really I think especially in the past few years um harder because with AI with every any new technology

past few years AI and LLM uh a lot of engineers now want to work on cooler stuff. They want to work with LLMs. They want to work with AI. Maybe they want to use that for as their um part of their resume for career progression and so on. And so for them, a lot of times when we going into these having these conversations with them, the engineers are more interested in building something in house because they get to work with really cool technology. Um so you know again the job is to our job is to show them that it's not just you know working on the cool part of the you know um software development or product

development but there is a lot of toil and a lot of grunt work that you need to do to build let's say AI or LLM based uh product solution show to them that you know using a third party venture um third party um vendor will free you up from working on the grant work you don't need to worry about uptime all the time. You don't need to worry about integrations, building integrations all the time because maybe 10% of you know building a new LLM based tool is going to be working with the AI and uh you know getting into the really nitty-gritty of AI. The rest of it is still building integrations. It's still doing the the boring job. So

highlighting how much of your solution automates that ground work is going to be critical in them opening up and getting more interested in trying the product. Um and of course they care about you know building a portfolio, building an interesting resume. So for them it's also important that um they get an understanding of working with a third party vendor doesn't necessarily mean that they are they don't have that skill set. They can you know you can work with them. They can expose them to some of the learnings that you have and you can work together with them especially with you know build cultures. Uh it's important to show yourself as a collaborator and not necessarily just a

vendor. um their buying journey. Usually it starts with is this even a fun problem to solve or not? This is a fun project to work on. If it's really fun, I want to work on it or at least I want to get really involved. Um can I get approval from my manager to build this? Uh can I build this on my own or not? So all of these questions, you know, they're thinking about these as you know way for them to to work on something cool, present at a, you know, company at at besides or another um conference. Uh get them involved as much as you can. um tell them about hey we're gonna define

the project the case study we can present together we can you know put together some uh papers out get the name out also you know establish yourself as a thought leader in this space um the message again goes back to presenting oursel as a collaborator and not a vendor this is the type of you know company that has that build culture and so for them uh they're used to building things uh internally working with a vendor might be a deviation from that pattern. You don't need to necessarily enter with going really strong on the sales side. You can start with um we are working on a similar problem. It looks like you are working on an internal tool to solve the same

problem. Let's exchange notes. We are dealing with this type of problem LLM's hallucination or uptime or you know keeping the cost down or keeping the latest down. what are you seeing in your tool? That really opens up that conversation, shows them that you care about what they are doing as well. You're not just trying to sell to them. Um, but also I think it shows them all the challenges of building a product, especially a product that eventually is going to, you know, um, the company and the organization is going to rely on. Uh, and that will, uh, definitely open up the conversation for down the line collaboration. One example from a previous company I used to work with. Um

we had a data security product and uh one of our leads was a public social media company a strong build culture. So for them the most important item was that our problem are so specific and so um bespoke that we do need a customized solution. So we've always been building a customized solution. How can you build something that is even better than what we can do? So our starting point was not just to show them metrics and dashboards and you know what we can do but we knew that they have a strong enough engineering team to be able to pull that off if he had they had dedicated those resources to it. Our job was to work

with them um over a few months to show them all the challenges of building something in that space. Specifically that product was uh heavy on integrations and ingesting large amount of data. We started to have these regular monthly or bimonthly meetings with them. Every time I showed up with something, a story that I had faced over the past, you know, time. For example, an integration broke uh or an API endpoint broke without us getting notifications in advance. Show them how our platform was able to pick that up within minutes and then we had uh a fix out uh within an hour. And you know that kind of a started to open up the conversation about yes we are seeing the

same thing uh we've built the same integration we are ingesting the data but two weeks ago it broke down internally and it created this you know issue within the organization. Those conversations eventually led after almost a year to them signing up with us uh even though they had built the tool internally as well. And so you know that collaboration and collaborative conversation really helped us build that trust with them especially in security. Um a really powerful playbook here is to start inside their tools get to know their tool stack because again this is a company where they take pride on the tech stack and the tool stack that they've built. um they usually are bigger organizations

when um their problems and challenges are unique and so they have developed over the years a set of tool stacks and tech stack that really caters to those challenges. So um once you start the conversation by saying oh you need to change this workflow that's usually the end of the conversation. So you need to be able to show them how you plug into their existing um existing tech stack from the beginning. And so in that case showing that how fast you can build integrations, how you can uh basically be flexible, giving them the building blocks to work uh with your um product without changing their stack is really powerful. Start by building uh an API

they can use, scripts that they can write against your application. Those are going to be super powerful. Again, we are talking about organizations who love to build first, not necessarily to buy from a vendor. And um the last persona is the strategist. Strategists are usually a few steps ahead of everyone else. So that's how they think. The most important you know things for them that is that you're within bigger organizations, larger organizations have different ways of doing things. You need to basically be able to build alliances inside the organizations. You need to think about your control and political control and political cap capital. And so that's what they are working with. that's their currency and they want to

make sure that working with you, working with your product helps them advance their team, their organization, their careers. Um, they optimize usually for business risk, compliance and influence. And so the type of questions they usually ask is that are we giving up control by buying versus building in house? Are we putting oursel in a corner by relying on third party? Especially for earlier stage startups, you know, now I'm building another company from the ground up. conversations I have is that how do I know you guys are going to be around two years from now? I'm putting you know my political capital or potential you know future career um into working with an earlier stage startup.

How do I know you guys are going to be around? So you need to derisk that understand that you know where they're coming from that's most important for them. Um their buying journey again they care they they uh worry and they care about visibility um and social and political capital within the organization and so they want to first see if this is a high visibility problem. Is this something that you know uh a VP or higher level cares about they can maybe uh present at the company retreat next company retreat. So that's important for them to kind of you know show the high visibility of the problem. Um if it's something that they can get more

headcount for that usually translates to to more influence. So for them uh to build something in house um they also want to see if that's going to increase their influence within the organization or not. Um is there any risk in the team being able to pull this off or not? Again they don't want to embarrass themselves. This is a you know high visibility role that they are talking about. um and then eventually can I trust this vendor to to deliver not just now but a year from now two years from now am I going to embarrass myself by working with this vendor so again your job is to you know help them walk through this journey as a collaborator

as someone who is helping them understand the trade-offs uh as they're going through this journey the messaging the best messaging I've seen working with these organizations is that um basically tell them or to communicate get in a way that shows to them that by working with us, you're still going to own the result. It doesn't necessarily mean that you're giving up the recognition for the result. It just means that you are giving away the risk of this working or not. If it works, you get the recognition, you get the result because you were the one who brought the tool in. If it doesn't work, we own the risk. We own that because, you know, we are a

vendor. you can always, you know, use us as as that. And so building in house, it has its own risks that you need to make sure they understand. It may not work as advertised. It may not be able to keep up with the latest threats. um or the person in charge may leave the company, leave you with an orphan tool that now you have to find someone else or uh some um um support from internal uh from inside the team organization to to keep the product to keep the lights on basically. Um so again the messaging is we'll own all of that risk. You own the outcome. You own the recognition. Um a playbook that really works well um

is give them control of the narrative. um help them talk about this at conferences. Bring them out on if you have a podcast, bring them on the podcast. Uh if you have a newsletter, highlight them at the newsletter. This way, the visibility, the outcome, the recognition is theirs. Um it helps them make that decision, helps them ease making that decision for you. um quantify risk reduction um regular updates. Creating a dashboard where they can share those metrics internally uh is super helpful because again part of their influence and capital internally is showing those hitting those KPIs. Showing those metrics, show them how many risks you identified or prevented in the last month uh or cycle. um show

them that progression and they use that as ammunition in inside the company as well to make sure your product continues to be to be used by the by the organization. Again, their uh capital depends a lot on the metrics that they can hit and the KPIs. Um, one important thing when you are working with organizations, especially organizations where they have the build culture is also understanding the motivations behind that conversation or the person you're working with. A lot of build versus buy conversations um have motivations beyond risk, cost and other um surface level conversations. I stole this from Travis McPe's presentation at Besides SF last year, but essentially some of these conversations happen for reasons other

than technical reasons. So as we are going through this journey with the company, I think one thing to keep in mind is to understand when to move on. not necessarily give up but move on or at least put that conversation on pause until you really understand you know what's going on uh below the surface as well and so um just wanted to share this with founders because as founders one of the things that is the hardest for us we have that grit and we have that sense of ownership that moving on from a conversation is hard but also understand that some of the time the motives especially underneath might be different for different organizations. And I want to leave you with three main

takeaways. The most important thing again to remember is that you are selling to humans not companies. And so you need to understand the motives beyond cost. These motives can be risk, social capital, um technical capital and technical um um recognition and uh finally lead with help not hype or sales tactics. I think throughout the day, especially in this room, we learned a lot about how to be helpful, how to present a persona of help and uh be able to uh create that trust and social capital using newsletters and LinkedIns and videos and podcasts and so on and so forth. That really matters a lot especially when you are working with organizations where their um first

reaction to a problem is let's build a tool in house before going to a vendor. So I know we had um the full hour for this talk um but initially my talk was uh scheduled for 30 minutes. So this was a shorter presentation but I would love to use this opportunity opportunity for two things. If you have a stories of uh selling to organizations where you know um the first reaction was we can build this in house. Would love to hear that. Otherwise any questions um or any other stories that we can share would love to hear more. assume that a certain size is like do you verify that they're considering building house you open with

or you just >> I think it's best if you can verify in the beginning usually when you have that first conversation um they say something like yeah we've been playing around with LLM for example like a lot of conversations these day I have is that yes we built a script internally that does something similar. So validating that need is helpful plus that's also validating that they they actually have a need for this they are you know they are u dedicating resources. Um but it's also safe to assume that at some point during the conversation that question is going to come up that can we just build this in house. Um, so it's always safe to assume that companies uh with large

enough apps teams or security teams uh they probably have the build culture. Emily related to that conversations with folks where it's not I can create a Google Gemini to do this or something where it's like technically still alive but it's like >> I think in my opinion the best answer to that is that yes we can always do that. Um but then there are these challenges like how how many team how many people on your team are going to use that? um do you have any issues with access control for example do you have you know if there are enterprise that they care about those things uptime access control um security AI security and so on those

are some of the you know maybe attributes that you can ask questions and just be curious um I think it's with those conversations what I've realized um it's best to keep that conversation going but don't expect immediate results because until they see it through they usually are not ready to give up their internal tool um and and and sign up with you. Um but like I mentioned the case from that public social company a few years ago that's this was before chat GPT. So the main issue for them was to build integrations and do data ingestion and make sure that the uptime is there and you know data injection does not break. For me what worked was

just meeting with them regularly just sharing the stories sharing the stories as in like you know war stories about hey like this happened have you guys seen this for example or we saw this H case have you guys seen that or not sometimes that brings about issues that they hadn't seen and that triggers a conversation internally to to buy versus build >> let's say let's say they have you ever been in a situation where now you'reing And how's that? Was it an ROI? Was it more winning? How did you win that battle? >> It happens. Um, and it has happened, you know, more often than I thought it would. Um, in one case it was, for

example, you know, they started playing around with uh with those tools and APIs, realized that's um hard to scale. They built the first two integrations saw that it takes six months to build one instead of three weeks that they initially thought they would. And so for them going from two to five integrations meant should we wait another year or should we go with this vendor. Um but my experience was that they never were ready to do that before they see one cycle through. So you needed to stay in touch. to kind of you know keep reminding them that we just built this integration in three weeks and so if you guys want you know five more

integrations here is how you can on board uh that was one case that helps the other I think messaging that helps a lot or playbook that helps a lot is integrating with their internal workflow and just show them that just because you build that integral tool um or that bespoke tool it doesn't mean that now you need to change your workflows to to work with us so we can replace, you can almost be a drop and replacement. And so that being able to work with their workflows uh was always uh super helpful. In reality, most organizations that even when they say we build bespoke tools, in reality they fall within a few different buckets. So even though they think that

you know their tools are bespoke at the end of the day most organizations at a certain scale and level face similar problems and so um sure maybe Netflix you know 15 years ago had really unique problems but even after that you know after a couple of years a lot more organizations uh caught up with them. I used to work at Capital One when banking industry was not you know yet in the cloud. Um they were the first movers to the cloud. We thought a lot of things that we were doing were unique and never is going to be relevant to any other company. I know personally 25 30 different open source projects that came out of capital one I still than there is

still being used. So that shows that there is a much bigger market beyond that. It might be a matter of time but most of the time >> there are other companies >> whatever you build it's gonna be something that everyone uses or needs in >> Exactly. Yes. >> Yeah. The the the problem is there otherwise no one would have you know given you the resources to build it. Maybe there are other companies who are just scratching the surface of the problem or they're you know starting to have awareness of the problem. They're not ready to commit but it doesn't mean that the problem doesn't exist. Yeah. How do you view selling top down versus bottom up in the sense of what a

siso would typically want to see might be different from what analyst want to see and there's different features you might show them. So how do you see those two angles? That's a great question because I think it goes back to you may run into many of these different personalities or personas in one single deal. And so then your messaging needs to adjust to that type of conversations you are having. You might to start having a conversation with let's say a staff engineer where they have that hero mentality. I can build this better than anyone else. And so at that level you need to have the conversation about hey you doesn't mean that you're not going to work on cool

stuff. you can still have that, you know, exposure or understanding or experiment with LLMs if you use our tool. It doesn't necessarily take that away from you. It just we're just taking away the ground fork. But then, you know, when during the deal conversations you're talking with the CSO or, you know, someone higher up, then you need to have that conversation about you own the outcome, we own the risk. And so sometimes that messaging will change throughout the conversation, but it doesn't change the fundamental fact that you know there's usually motives beyond cost and you need to kind of you know talk to those motives when you're talking to the different parts of the organization. Even when you go through

procurement um motives are not always just cost. There's usually something that bubbles up during those conversations in procurement that you need to also have that clarity. ask one quick follow like um >> how would you like if you're to take a step back and you're in the build process of your product like how do you sort of see building features that would you know feel more align to what you know a staff engineer would care about versus like dashboard so how do you see >> yeah that's a problem earlier stage companies always face you know what feature to prioritize first I think you need to have you know some level of those different features in the

beginning. Um, build a few integrations but immediately build a dashboard because at some point you're going to run into those you know conversations about metrics. How do I present this to the rest of the team? Um so you know for example in my company right now we are doing something you know automating threat modeling for example it doesn't necessarily need to have um a very strong dashboard culture but we had to build one because you know people were asking how do I show the team how much value I'm bringing um and so it depends really on your your journey on the the deals that you get throughout your journey of building the uh the startup

But I wouldn't prioritize one or the other just because you know by fundamentally I think one is better than the other. It depends on you know your journey. It depends on what conversations you're having as you go through the process. Again we had to adjust our strategy as well at the beginning as you grow. How do you teach yourself for to have those conversations >> uh grow as a founder >> as a company? as a company, >> your company grows now, you need to delegate that to the Salesforce. They need to develop the same. >> That's true. That's a good point. Um, I think it really depends on So, each company has their own sales pitch book

and playbooks and so on and so forth. You need to be able to understand the market, understand, you know, what's really hot on the market right now because the technologies that are deemed cool will change over time. And so, you need to be able to also um adapt to that. having as many conversations with your users as possible. I think that's always the golden standard of just you know uh keep learning as you grow the company. Um and then getting in front of as many uh users as as possible. Uh that's the best that I've learned over the years. Uh that works. Uh but also some some of the signal you get from every conversation doesn't necessarily mean

that's a strong signal or a valid signal. Um, like I mentioned, there are some other reasons that companies don't sign up or decide to build in house other than just cost or trust or something else. >> Did that answer the question? more how to actually teach a sales force to >> so I think um what Salesforce really like to see um in my opinion is the journey um for the different personas. So identifying and putting different people in those personas might be the trickiest um kind of art. Once you put them into that persona, the rest is more science than art. So I would say the the piece that you need to have experience is is that and maybe you can handhold

them putting you know this person is really motivated about building something cool or working on something cool or having that technical uh ownership or representation or this person cares more about their influence inside the organization. Once you help them put them into those um I hate to use a term bucket but personas uh then the rest becomes more science. This is something that is teachable. You can share this with your uh salesforce and they'll be able to tell you here's the stuff that they are really stuck on but before this how do I how do I put them into these different one of these categories. This is art. You need to work with them. This is what you would

teach them in the first 50 sales calls, 100 sales calls where you are mentoring them or you are pairing them up with a more experienced salesperson.

>> So how do you deal with a case where you have maybe different stakeholders or different buckets they have conflict like internally? How do you deal with that? the internal conflict. Yes. Um, that's a tough one because sometimes the CTO is, you know, motivated in something and cso is motivated in something else. You need to know your buyer and who has the purchase power first. That's like the first thing you need to do before you even go into the deal. Who is going to make the purchase decision here? Um, and yes, there are going to be blockers. Maybe CSO has the purchase decision, but uh, CFO wants to listen to CTO as well or wants to bring CTO along. Um, but at

the end of the day, there's one person that usually makes that call. There's one person that owns the risk and for them, you know, they need to do something to mitigate that risk. Um, and so catering to them usually is the most um gives you the most ROI, but it doesn't mean that you need to ignore the CTO because they can delay the deal, they can block the deal um for a long time. What I would say is start with having those conversations individually. Um, and you can work out, you know, a setup that caters to to everyone at the end of the day. Usually what happens is that, um, some people care more about

recognition, some people care more about the control, and you can come up with a way to to cater to both. But again, there's usually one person on the deal that you need to pay the most attention to. Anything else please? Yeah. When you're doing that partnership and building as

you >> That's a good point. um we actually are going through that in my um new venture with a couple of companies I know that they are building something you know internal um I would say there are two things one is trust you you need to be able to trust each other um and then second is that I think the more there's a certain level of IP that you don't you don't want to necessarily share um and so that's something that your code base for example or if you have a you know specific you know trade secret. You don't want to necessarily share that. But the more that you share with them, the more that you earn their trust. Two

things happen. One is that they see you as a collaborator and not necessarily a vendor. And that's a huge thing, especially in, you know, these days like security market is saturated. So you're going to see a lot um and then two, they're going to see the challenges. So this, you know, you are usually a few steps ahead of that internal team, uh, as a vendor just because you have more resources. this is your entire livelihood at this one as opposed to someone else's you know pet project. So of course you are a few steps ahead of them. Try to highlight those as opposed to necessarily like all the trade secrets and ask them questions about

what are you doing about this. Sometimes the answer might surprise you. They might actually have created a clever solution to something. Um so for you that's also a learning experience. But if you see a response where you have an opportunity to show them how you cleverly came up with a solution for that, I think that will increase the chances that they eventually say, "Okay, so every time that I'm talking with this guy, he comes up with three interesting questions that I had not thought about. So maybe for the next budget cycle, I need to work with them." And so for me that's always been just you know lead with the questions as opposed to lead

with solutions or lead with um maybe complex algorithms or something like that. But also you need to be aware of the fact that yes some some teams are going to look at your product build something you know internally similar to that and just move on with that and that's a risk that as a founder you need to kind of in my opinion accept. >> Yeah. Is there something you can put in the contract? So there's certain level that you can put in the contract. Of course, there's some IP, you know, clauses that you can put in the contract. In tech, it's always hard to enforce because you change one small thing about an algorithm and it's a completely new

thing. I think it's more a trust than a conversation issue. But another way that I've derisked it, at least in my current role, is that you put a very clear time um time bomb on it. Basically we do this for 3 months after 3 months if we hit these you know metrics you know let's talk about the next stage and so maybe the first the initial conversations are going to be surface level you're just talking them as a collaborator not as a vendor but once they are ready to let's say get user accounts before give them user accounts so that they can come in and play around with the application have that conversation with them put

that into the contract or at least be very clear with them that this is only for three months after the three months here's what you're going going to do or let's have a conversation after their three months as opposed to an open-ended let's just try the product, let's just collaborate.

Any other questions or stories or other insights? We're good. Thank you so much for coming.