Name: Turning POC’s into Revenue: A Framework for Winning Enterprise Evaluations
Uploaded: 2026-06-30T18:17:17.046Z
Duration: 59 min 55 s
Description: Turning POC’s into Revenue: A Framework for Winning Enterprise Evaluations

Transcript for "⁠Turning POC’s into Revenue: A Framework for Winning Enterprise Evaluations": Hey, everybody. We are live. I'm Jared, cofounder of revgenius. The mustache is coming in. I couldn't be more excited about another tremendous session with our friends at Demostack today. As we're waiting for a few people to come in, we we've had over 300 registrants for this. So it means this is a big dot deal, and we're gonna be talking about turning proof of concepts into revenue. So, like, a framework for winning enterprise evaluations. And as much as we'd like to think we're turning them all into revenue, the the facts are we're not. So this is really important. As people come in, let's do a quick icebreaker so that we can get to know everybody and so that these conversations can continue on LinkedIn, in our Slack, in other, places. Drop your, LinkedIn handles in the chat so that I can see that everybody's alive, that we could connect with people further after this, build great connections, etcetera. So revgenius, we're a community. We're now 65,000 people. And we have some really killer events, partnering with some tremendous companies like Demostack to bring you all as much value as possible. Our Slack can get kinda crowded sometimes. So instead of 65,000, you know, an intimate group of a few 100 here to learn, from some of the leaders in the space. So what these, what these speakers are about to chat about is your point of your POCs are are set to fail, and we're gonna be talking about the framework to win it. So we're gonna unpack, you know, different stats as to why they're set to fail. But you're gonna leave today with an actionable framework to make that not the case. So we have John Care, author of Mastering Technical Sales, Gilad, Komorov, three time CRO and G Team adviser at enterprise SaaS companies, for a forty minute, no theory breakdown of why proof of concepts fail. Welcome, guys. Hello. Hello. Hey. Hey. Hello. Hi, everyone. Thank you. Thank you, Jared, for the introduction. I'll give, we're gonna jump right in. And as Jared said, we're gonna talk about, why POCs fail and a practical framework to turn to turn them around and make them successful. I'm Noam Harel. I am the head of growth at Demostack. I have with me, John Care. I'll give a a little bit of a deeper dive into John, a little bit of your background so I don't, so we don't lose it. Managing director and author of, Mastering Technical Sales. It's a book. There we go. It's a book literally a generation entire generation of, solutions engineering teams have been trained on. It's been published around the world in tens of thousands of copies, and I believe, John, a dozen languages or so. Don't quote me. We're we're working on that. It's three or four languages. We deliver our classes in about a dozen different languages. So yeah. And, he spent his, entire career, career building a world class, presales organization. And we have Gilad Komarov. He's a three time chief revenue officer over, twenty years of experience, building and scaling, revenue organizations including, LivePerson IPO, Clarison that was acquired, Feedvisor, Lyteco, and Granley, which was acquired as well by Intel. And for the past two years, he's been working, hands on with, GTM teams, with over, 20 technology companies helping them build and scale their revenue operations. So a bit of context before we jump in. Enterprise, SaaS organizations, they optimize, their funnel aggressively and very, very well. But meanwhile, the deals that go down the funnel and, after twelve to eighteen months sometimes of nurturing and tens of thousands of dollars, they quietly stagnate, at the POC and die out. It's the most expensive stage in the enterprise funnel, the longest stage, and, honestly, it's the one that's often under prioritized relative to how much rides on it. So we're gonna jump right into the session. I'll start with a bit of context just to showcase some real world stats on the cost of an actual POC. These are, recent, recent studies done by credible sources. Average, enterprise, sales cycle is upwards of ten months. You mentioned twelve to eighteen months and being conservative. POC sales cycles are often, four to eight weeks long, and, definitely the longest stage in that cycle. And interesting point, the median acquisition cost, for every dollar spent for six figure ACV deals, is $2. I'm sorry. For every dollar in revenue is, nearly $2, in in spend. And a sad stat, to compliment that is about 40% 40 to 60% of deals in the pipeline actually end in no decision. They don't lose to competitors. They don't, fall out because of lack of product market fit. They actually lose because we weren't able to showcase our value well. To dive deeper into the actual POC, Just a ballpark I'm being conservative here, a ballpark figure of the cost of POCs are approximately 35, sometimes upwards of $60,000, the acquisition cost. But then the cost of account executives, solution engineering, sales enablement, customer success, and the actual infrastructure, that supports showcasing the product value in the real world sometimes gets very, very expensive. So with that sort of background, I gave some some qualitative background on, what the POC means for a business. But maybe I'll throw it over to Gilad. And Gilad, give us, the CRO context of what, what success in a POC or rather what failure in a POC means for a business. Sure. Thanks, Noam. So I'm gonna put on my CRO hat, to answer this. It's been two years since I've been a CRO, but, it's still in my, vein. So, you know, the POC is really where all your previous investment is put on the line. And I think just as you share now, Noam, by the by the time a customer reaches a POC, so many costs are layered on top of that. Right? Marketing has spent months generating demand. SDRs have spent significant time, right, prospecting into the account, qualifying the opportunity. AEs have invested countless hours. Solution engineers, right, setting up demo environments and customizing them and, you know, working with engineering to kind of configure these environments. So a lot of time, effort, and money is invested in these POCs. Right? You showed a median or average of 35 to 60. It can be upwards of that depending on your ACV. So because of that, I don't really see the POC as just another step in the sales cycle. It's really a make or break moment where we either convert all that investment into revenue or lose it. And I'm encouraging everyone here to put that price tag on their POCs. I think it changes the mindset. When you view every POC as a $50.60, sometimes $70,000 investment, it changes your perspective and your approach on these POCs. And I think that the biggest misconception that I see from my vantage point in working with so many, startups and tech companies as an adviser is that the POC is viewed as a technical validation exercise. And don't get me wrong. I think the technical win is super important, absolutely matters. It's table stakes. Right? If our product can't solve the customer's problem, nothing else really matters. But that's where I also see so many organizations tripping and falling. They achieve the technical win, and then to your point, Noam, that no decision comes or they choose a different vendor. And why is that? You might wanna ask. So really is that? POC is just about proving that our tech works, guys. It's it goes much beyond that. We're gonna dive deeper into that in this webinar. But it's really about building alignment around value, around impact, what the customer really needs in order to move forward. And from my experience, that's what really separates the technical success from the commercial success, and both have to be taken into account in order to win POCs. So so, John, maybe, take a different lens on that speaking for a technical cell or for a solution engineer. What what does the POC represent for you? What's the value for the. business? Love to. So first of all, hello everybody from Philadelphia, and speaking as a, like, someone who is now living in The US but is English. If you are a German or a Dutch football fan, I am so sorry about yesterday, but I have to put that dig in. Okay. So it's the so this is the view of the baby boomer who's been doing POCs now for forty years, or so, and has also been a CIO. So I've been on the other side of the table as well and actually had a team working with vendors running POCs. So putting my engineer hat on for a minute, we are talking here about POCs. That's kind of generic term. There are proof of values, proof of concepts, trials. I see in the comments that sometimes they're paid. Rarely, sometimes you get a customer to do a shared investment with you. And most often, they are unpaid. So the POC, to build on Gilad's point, frequently gets treated as the a technical exercise, and that is that that is actually the wrong mindset to to look at it. Certainly, the the technical win is important, and the technical win is when the customer says that you are uniquely qualified to run-in their environment and to solve their business problems. Right? So to get rid of the pains that they may have shared with you and also, you know, maybe achieve some gains as well. So, you know, you kinda need a definition of a technical win, and, weirdly, a technical win is not just a technology. You know, a a technical win is a precursor to getting the business win. Often, it precedes the business win by, you know, something like five or six weeks. So so that's the first mind shift is, if if you're a sales engineer and you view it as my job is just to make this damn POC work and I'm done, like, that is not your job, because you also have to employ the sales part of your title as well, which is regardless if you're on-site or doing this virtually, you need to be framing that POC to create consensus with the customer that you are indeed uniquely qualified to solve their business problems as well as to run-in their environment. And the world class sales engineers working with world class salespeople, are the ones who actually do that. So that's why it's so important. You know, again, we think of it as a technical thing, and it's not. You know, the technology and the business are intertwined like like DNA. Right? The two strands twine together, and you need to get them both completed in order to win that business. So I'll segue before we jump into the actual, killers of a POC. You guys said two things that I'm I wanna latch on. Gilad, I mentioned it and you and you double down on, you know, often they end in indecision, deals end in indecision. And and, John, you said the word of getting to consensus. Yeah. And how do you how do you identify those? And we'll segue right into into, six killers we have identified. But how do you identify when you're not in consensus or where you're getting to indecision? What does that look like? Oh, well, I'll I'll jump in here. So the the the stat we always use within Martian technical sales is about 42% of deals end up being won by DNI. Right? Do Nothing Incorporated. Yep. Whenever I help a company kind of run a competitive analysis or prepare for a deal, you compare against, you know, the the the one or two standard competitors that you have in the field, and you need another column for DNI. And you actually need to treat no decision, whether it's truly no decision or alternate use of capital, actually as a competitor in the deal. And I think that's a mind shift as well because I truly believe it's easier to win a deal and pull it away from no decision than it is to pull it away from one of your competitors. So there's kinda one, again, mindset takeaway I would give people is, you know, compete actively against Do Nothing Incorporated as well as against the standard competitors. And I think that, for the sales team, kind of sets you up as well. And consensus building and land and expand and building out in the client is the way to do that. Gilad, I'll segue into the six killers, and maybe you can take and and and speak to how, you see it as a as a head of a sales or operation, when you start seeing that indecision, start seeing that, that lack of consensus. Oh. We're gonna jump right in and talk about the six killers. And Gilad, take it away. Thank you, Noam. And so as Noam said, you know, I I I think there are more than six killers, by the way. If we had more time. today, we They're probably just funny. another so we'll focus on the ones that, you know, the three of us here thought were the top six. Maybe we should add the top before six now. So these are the the top six pillars, that we, I think collectively see across the board in in POCs. And the first one that I'll hit on is the lack of executive sponsorship. And I think that, you know, I may be stating the obvious, but it's not so obvious. And I can share this, you know, just from my experience working with dozens of of companies every year. I see so many times where there's no executive sponsor or economic buyer engaged before the POC begins. And when that happens, then, you know, speaking of that technical exercise, that's exactly what you're running. You're not running a buying process. And I think that when you or when the seller, makes sure through the champion to understand who this person is, what do they care about, will there be budget allocated to a purchasing decision? Should we succeed with the POC or POV, however you you like to call it? Then, you know, that puts it puts the deal at risk when that is not there. And I can share that as a CRO. That was a prerequisite in any company I was at for entering a POC. K? If there was like, we we would do full MEDDPIC analysis on on deals before going into POC. Why? Because we would have to allocate a lot of time, money, and effort, right, in order to ensure these POCs are successful. So I would always ask, who's the executive, and have they validated that if we succeed, there will be a decision made, to allocate money towards this cause. And so my advice to you on this one is, make sure that alignment is there. It's a great way to test your champion and to filter out tire kickers that are just coming in for a spin, you know, to see how your tech works and and and, you know, experience it. And it, I think, really reflects their level of seriousness around the initiative. Just to reiterate that, what you're saying is by the time you've gotten to the POC, if you don't have an executive pan sponsor, your recommendation is do not enter the POC. Absolutely. Unless, you know maybe if you're very early stage and you're primarily, you know, just looking for feedback on the technology, that, you know, could be a good reason to do that. But if, you know, if you're already, generating revenue and you wanna make sure that your, you know, time and efforts are spent wisely, make sure that that executive sponsorship is is there. Otherwise, you're at risk. I've seen so many POCs reach that, you know, post POC stage. Everything went well, and then that no decision comes. K? So I think this is one of those primary drivers for no decision. There was no executive involved, who, actually saw this as a valuable, initiative that aligns with their strategic goals. No alignment. You're segueing yourself into the next one. What does that mean? What is. the kind of alignment? And I think this is, great for, for you and John to tag team. Both of you discussed it. What does alignment mean when you're going into a POC? So this is probably the biggest one I see, and I'm sure people on this session will will relate. You get into a POC kickoff call and dive straight into the technical implementation. K? John, have you seen that one? Right? You just, like, get on a call, and let's dive in. Let's open up, you know, screens, start configuring away. Let's do a walk through of, you know, the happy flows that you're gonna test. And I'm always like, hold on, guys. Hold your horses. We'll get there. Before that, we need to align on a few things that will ensure our mutual success in this process. And those things are the objectives. K. What do we ultimately want to achieve from this POC? What are the success criteria that we are going to measure against? Who are the stakeholders that are gonna be involved on both sides? What's the timeline? The operating cadence, right, the process, the scope. Right? And this kind of leads me into this silent killer within this killer, and that's the scope creep, k, which I also see happening so many times. And, by the way, another reason for indecision. When you start seeing scope extending and the customer wanting to test another feature here, another feature there, chances are that they are not so sure about what success means for them from this, exercise. And so, you know, defining a scope, sticking to that scope, explaining to the explaining to the customer that in this specific evaluation, this is what we're gonna evaluate, and that should give you enough conviction to make a decision. Anything else that you're gonna wanna test will have to be done in the post POC deployment. And I think, you know, what I'm seeing and I'd love to hear, John, what you see from your, perspective. But, you know, that's sometimes it's a difficult conversation to have with a customer that you're trying to win over. Right? Drawing that line and explaining to them that we're not gonna extend the scope and giving a good reason, you know, behind that. And then, again, these POCs just go on and on and on, and, you know, they get extended more and more and more, and they never end. So is that what you're seeing in the field also, John? Yeah. But I'm always puzzled by the fact that there's, you know, thirty day or sixty day POCs. It's like, why is it thirty days? I mean, if you look at the project plan and it's something you can get done in fourteen days or twelve days, why not make it that? You know? So, Right. that that does shut the the alignment. You know, one of the things that strikes me, you look at these six POC killers, and, certainly, if you kind of dive down on the first four, it looks amazing like deal qualification. I mean, you can map this to, you know, medical, med pick, or, you know, whatever spin, whatever else you you wanna be doing. And that that kinda makes me think, like, maybe before we even dive into the third POC killer here is to encourage the the audience. So I I think this builds on a point that Jason made in the comments is kind of stay take a step back and ask, well, you know, how did we get here? You know, why are we actually doing this POC? Is it necessary? Maybe if you think about the the seven levels of effort there are in order to, you know, potentially close a deal in this type of situation, the POC is like level six. I mean, you've got references, one. You've got reference visits. You've got a lightly customized demo. You've got a moderately customized demo. You've got a heavily customized demo. Then number six is a POC, you know, followed only number seven, which is a full pilot in production. So if, you know, we do the dash to demo, which drives SEs crazy, which is then followed by the push to POC, you kinda need to take a step back and think about your GTM and say, what why are we doing these POCs? Is it something that's actually a necessary part to close this deal? Is there a more lightweight alternative to to do it? So, you know, POC killer number two, that Gilad was talking about alignment on objectives. I think there needs to be an alignment between the rep, the SE, and management above them as to are we actually gonna engage in this POC. I think that's kind of that that's me putting my, you know, my VP of sales engineering hat on there. think that's something I've seen often with the companies I've led marketing with, and product marketing is that alignment doesn't only serve the relationship between, the company and, mhmm. the prospect, but it's also internal alignment on what we're actually trying to accomplish. How much effort does it require? Making sure we don't you meant you mentioned the dash to demo and dash to POC. What are we actually trying to achieve from a business standpoint for our prospect, and what needs to be done to prove it out and not start go and do a cuckoo clock dissection, Yeah. of all the capabilities? Absolutely. No. And I I firmly I say I firmly believe, and we have the the data within my company. Somewhere around 60% of demos are done too early in the sales cycle, and about 50% of POCs are done too early. And it often is because the sales team doesn't know what else to do. It's like, let's do a POC. Right? So, anyway, little off track there. So let's kinda get back to these killers here. Three is the generic environment. Right? And this is really speaking their language. So, you know, we we encourage the sales team to speak the language of the customer. If you're dealing with a pharmaceutical, r and d organization, you're talking about clinical trials and adverse drug reactions and things like that. Same thing applies in a generic environment. I mean, nowadays with, you know, AI, there's absolutely no excuse not to be able to stand up an environment up there in Cloudland or even on-site that truly reflects the customer's, you know, environment, their data, and everything else. And the more you can make it easy for them so they don't have to do that context switching, you know, from generic or, you know, abstract to to concrete, I think the easier the POC tends to go. And that's also a sign of planning as well. Right? So you definitely need that. And then the fourth one is really, you know, no POC management. And and and, honestly, if if if you're not doing this, you kinda deserve to lose the POC. Yeah. Yeah. Yeah. Yeah. So number two is the biggest one from him. I think number four is the biggest one for me is no POC management. You know, I mean, s SEs for you know, ever since sales engineering was created, have been building project plans and outlines as to how to do a, you know, a POC. Back in the old age, you you had these great big nine inch magnetic tapes that you used to lug on to a client site, install, you know, buy the systems program, a beer and cigarettes, he or she would load them up and away you'd go. You know, and that was kind of the management. But now, you know, who's gonna own what? Who's responsible for what? What's the check-in cadence? Are you gonna be online? Are you gonna be virtual? You know, do do you have a bot monitoring what's going on? So all these things are kind of essential. And the more touch points you have with the client, you know, as well as with your internal stakeholders, the more likely you are to win the deal. So POC management is essential, and it's not a it's not a step you can skip. And yeah. And it's bestowled so if every country. POC management disappears, you have zero visibility, right, to kind of lead us into point five. And it's bespoke for every company and possibly for every prospect when it gets to that stage. So management of this complex and deep down stage is critical. Right? If you're if you're failing out on actually, navigating through it, there's a high likelihood you're gonna miss out. Let's race through these because we have a framework to show that'll actually make, dealing with these challenges, practical. So Gilad, what does zero visibility mean? John just mentioned that, there's a lot of touch points. The more that you have, the more important it is to track them. What does visibility mean for you? Yeah. So I think visibility, can be viewed on several fronts. One is, visibility of engagement. K? So, you know, I think, first and foremost, you wanna get everyone in the same room, so to speak. Right? So, you know, creating a, maybe shared Slack channel or Teams room and communicating, you know, through these channels that your customer prefers, obviously, and keeping, the engagement going. So, you know, it's visible. It's there. Everyone is in that room, and they can see, how things are progressing, what the customer is concerned about, and, and and act on it fast. I think the other, level of visibility is, within the product itself. K? So whether you're running the POC in a production, environment, live production environment, You wanna have the analytics in place, to, follow through and see if your customer is actually executing on the agreed upon use cases and the things that we set out to actually test in this POC. And if they're not, then to be proactive about it and, engage the customer. Try to get them back on track. Right? So this POC doesn't just get extended, more and more. I think that another way to tackle this is by, you know, simulating POC environments. That gives an extra level of visibility, you know, platforms like, Demostack. No. You'd be familiar with this, but, you know, that kind of help you read a contain POV, that is not generic. It's very customized, and there is a whole layer of analytics inside that lets you see what your customer is doing every single day and that things are moving, according to plan. And so I think that level of visibility, of engagement and the usage are key in order to drive a successful outcome. And maybe I'll just move over to the last last one, last but not least, which is the kind of the POC wrap up or, you know, some companies like to call it readout. And so let's put it this way. At best, it's done poorly. At worst, I see cases where there's no readout. K? The POC just ends, and, you know, the account executive or solution engineer or both, you know, they just try to kinda move forward, before wrapping everything up. And I think it's really important to pause for a second and plan this ahead of time. And who's gonna be present in this wrap up session, and what are we going to cover? And do a dry run with your champion before to ensure that what you're going to present is supported by your champion because the last thing that you want in the POC readout is to have your champion, contradict some of the things that you're presenting. You wanna gather, testimonials and quotes from users that were involved in the POC. And so I think that leading this phase properly helps create that advancement, and that advancement needs to be a very firm advancement. And this is where I see many sellers actually, fall. There's no firm action plan to what happens after the POC. And? maybe we got a question exactly sort of following up on that and from from David in the audience. What's the best way to get aligned with your sales rep when it comes to taking on these POC killers? Maybe the wrap up is that final stage. So I'm gonna switch right over, to our, framework for pre POC alignment. And, David hopefully will answer those questions. And I think what we what we laid out here is that these killers are systematic, and they are not technical in nature. And if they're systematic and not technical in nature, there is there are technical aspects and proficiency is required, then there needs to be a system to address them. And we've built out for you guys a framework, and that if you didn't screenshot the previous slide, this is a slide to screenshot. We'll follow-up and share it as well afterwards. But we're gonna dive in, to what an alignment framework really looks like. It's an internal one, but one that you also use with your clientele. So, Gilad, we spoke about the killers, six of them. Let's flip it, and look at it the other way around and speak to what really needs to be built out, to build out an alignment framework for POCs. Excellent. So. So so as we as we, you know, mentioned earlier, that alignment before the POC is critical. And two things, from my perspective as CRO have to happen before you enter a POC. One, We need to align on the use cases and objectives of the POC. I recommend creating a pre POC questionnaire for the customer to fill out and provide all the context that we need in order to drive a very focused and intentional POC. The second thing is to create the POC kickoff deck. And whoever is here today, it's your lucky day because we're gonna be sharing a prompt, for Claude that you put in, and it starts asking you questions. And it will give you a customized POC kickoff deck that you can start using tomorrow. And if you have a design system in Claude, you can, tell the prompt to use your design system, and it'll already put it in your branding. And what that deck includes is the POC objectives, the success criteria that we talked about earlier. How are we gonna measure success in this POC? We do not wanna reach a situation in which a decision is made on a hunch or a gut feeling. K? It has to be very measurable and very scientific. It's like, did we achieve it? Yes or no? We wanna know who the stakeholders are. And if you haven't found out who the economic buyer is or the executive sponsor by now, this is a great opportunity to do that. And in this deck, there is a slide dedicated to that. Who is on our side? Right? The vendor side, the customer side, how do we align? My recommendation is always to have a three by three type of alignment. Right? So there's, the account executive solution engineer, executive sponsor on our side. On the customer side, also a a business champion, technical champion, and an executive sponsor. And the more alignment you create there between these stakeholders, the less risk you're introducing into the deal. We want to define the process. So whether it's thirty days, seven days, fourteen days, to your point, John, there is no set, you know, evaluation window or or or or framework. It really depends on how fast you can prove value. If you can do it in three days, great. I worked with a company that did a POC for one day. Why? Because that's all they needed in order to show impact, and that's it. So, And so, we got a we got a question in the audience and had a similar one lined up for you. What happens, when the prospect doesn't want to align on objectives upfront? Doesn't want to, give consent to a certain, road map, doesn't, isn't able to share their, executive sponsor buy in for the process. What do you do at that at that stage in time? And maybe John there we go. Maybe John and I have a I have a segue question to that, which is which is parallel to this, is who owns the process. Right? If we have criteria and we have these definitions in the framework, who owns them, who needs to navigate this conversation with the clientele, And how do we get them to, get them from no to yes? Sure. Well, Yeah. for the for those of you who weren't watching me on video, I I was simulating a walk. So I think the answer to your question there is walk. Always easier for an SC to say than a than an AE, but that's definitely the case. You know, the the ownership depends upon the organization. What I always fall back on is the fact that when you go and ask customers, whether they're execs, middle management, or individuals in IT, who provides the most value during a deal and who do they trust the most, it's always the SE as opposed to the AE, right, unless there's a big preexisting relationship. So the SE is in that position of trust, which I think is a vastly underutilized weapon or advantage that we sales engineers have. So in terms of ownership to to actually lay out the the specifics of the project plan, I think the rep kind of owns the overall framework and making sure it's in place. But the actual there's some of the specifics that go into it. I think people look to the SC as being the expert. I mean, you're the surgeon who's done this, you know, heart surgery 50 times before. You're the one with the expertise. The majority of customers, not all of them, but the majority of customers are gonna be willing to to listen to the SE and take them on board as maybe not a trusted adviser, but certainly an expert in that area. So, you know, that's a long winded way of saying it's it's a blend, but the SE drives it with trust and value. Yeah. Well said. I I think it you know, it's definitely a joint effort. It's a tag team type of effort. The way I've always structured it is that the AE is responsible for kicking off the POC properly, then he he or she, they pass on the baton to the SC to lead the actual evaluation. AE steps into the driver's seat. K? They're still there with the maps navigating. Right? They're not kind of, you know, just Yep. releasing the, letting go of the control. They're there. And then towards the end, they come back into the driver's seat with the SE supporting from the passenger seat, and bringing it, you know, to a a wrap up and to a close. And so I think it you know, the AE and SE have to be joined at the hip and aligned at every stage of the POC. I think, you know, just to go back to that question, which is a great question, because, again, when you see that happening, k, there is no intention to share objective success criteria, bring other stakeholders in in into the, process. That is the biggest red flag for an indecision outcome that we talked about earlier. And so you do, wanna walk away or at least explain to the, buyer, to the prospect that, you know, we're gonna be investing a great amount of time, effort, resources to ensuring the success of this POC. And in return, you know, the the the minimum that we ask for is for your engagement and for your team to be involved, and I think it's fair play. I think sometimes what I do see is that prospects or customers, they won't really know what the success criteria are because they just don't know, because they've never evaluated a solution like yours. That is not necessarily a red flag. I think it presents an opportunity for us to educate them on the typical success criteria and actually to help define the success criteria. And guess what? If you're bidding for an RFP and you're helping shape that RFP according to success criteria that you can actually, you know, improve the most, then that that's gold. So just on that point, I think, you know, if you see that's the case, then take the time to educate them and help shape those success criteria. And I think yeah. Just moving along here. Go go ahead, Gilad. Yep. I just wanted to to to to sort of, expand on that a little bit. There's something you mentioned in the killers, in the in the objective alignment that there's, often scope creep. And we got a question from the audience about, POCs being very technical and laborious and time consuming. And you just mentioned that oftentimes the customer won't know what their objective is. They won't know what they're looking for until they see it. And I wanted to ask the both of you, how you navigate between agility and, in in being responsive and reactive to what the customer needs and wants as they explore and discover, and consistency throughout the process and being, you know, confined or or or aligned on the objectives you've laid out in advance. How does that balance happen? I think there's a there's both a salesmanship aspect and a and a technical aspect that needs to be navigated. Yeah. I mean, I'll I'll jump in on the the tech two business side. I I started putting this in the comments. I think one of the other areas where the SE can really help be the catalyst for that trust is to help the customer define what success is in terms of what I commonly see when working other customers who are similar to you or in your industry or of your size is x. How does that sound to you? And then sharing that with the customer. I mean, it's a little bit of the challenger sale. Right? You're you're kind of suggesting, you know, here's how we define success. How does that work with you? If if the customer can't define success or will know it when we see it, I I kinda disagree. I think that is a bit of a red flag or at least it's a pink one. You need to be pretty aware of because, you know, if they don't know where they're going, how do they know when they get there? Right? Then they suddenly say, oh, we're done. Like, never ever in forty years have I suddenly seen a customer say, oh, we're done. Right? I mean, it's you know, it doesn't happen. So you you you kind of do need that that plan, at least some guidance in the general general direction of where you're going. So I think I'm on the other side of that one. In the singular? Yeah. Not much not much to, add there. I think I think John summed it up pretty well. I think that, you know, just moving along here with with the framework, the streamlined execution of the use case, again, ensuring that, you know, we understand what these use cases are. We're not, you know, kind of veering off to other use cases, and it's very tempting to start, you know, showing other aspects of the product of the platform, seeing this happening a lot. And so, again, confining the POC to the use very specific use cases that are aligned with the objectives and success criteria. And then lastly, the post POC alignment, right, the wrap up, treating that with the utmost respect, coming prepared, doing a dry run with a champion, gathering testimonials, as we said earlier, from participants that really, saw value in the POC, showing the success criteria that were defined and how we, achieved them, and then wrapping up with the next steps, k, to avoid a soft advancement. As we mentioned earlier, we want a very tight, plan for advancing this POC into a deal. And so the more alignment you do around that, before the readout and during the readout, after the readout, I think the higher the likelihood of you bringing this deal to the finish line. So I'll ask a. leading question, to John. You said it's not a, we're talking about a framework here, and we're talking about, a lot of alignment with the client. But it there is a technical aspect. And in today's day and age, you talked about being able to spin up, a lot of, a lot of things, whip them up quickly. But it's also there's a velocity to the pace the there's a high velocity of the pace of release of products. How do teams, navigate the agility that's needed with the proficiency they have to have that's applicable? Not everyone can know everything. And how. is that, segue between, sort of walking the walk and talking the talk and the POC handled technically these days? Yeah. So so, obviously, you know, agility and adaptability of your vendor is important. And much as we would love to say, no. We we said we're gonna do these nine things. We've done these nine things. There's always, you know, item number 10 and item number 11 that comes up, and you kinda need to be prepared for that if it makes sense and even if it's in the flow of things and if it fits back to meeting a, you know, a business requirement. I mean, let let let me just step back for a second and, if I can share with you a CIO story. So I think this will bring together a whole bunch of different points and answer a few of the questions we've had as well. So way way back when we were evaluating programmer productivity software, and we kinda went through discovery and we set up some POCs, and we actually had three vendors come in to POC the product for us. And they were each about seven, eight days. It wasn't a large one. But it was a significant sum of money. I was gonna spend $4,500,000 on this software. And one vendor did a little bit better discovery than the others and really uncovered why we needed programmer productivity software, and they discovered that my company was coming out with a brand new product and that IT was on the critical path and that we were actually gonna delay the release of this product because we couldn't get the IT systems, our infrastructure, in place and time to support selling the product. And it's gonna cost my company $8,000,000 and a delay of eight weeks to get the product out. Right? Unacceptable. So that's why we need to program a productivity software. So they came in. One vendor scored 74 points, another one scored 70, and another one scored 58. Right? So one who scored 58 clearly out of the picture, we got one with 74, one with 70. So in a normal case, you would go with the vendor who scored 74 points. Right? Makes sense. You know? They were highest ranked one. But what actually happened was when the vendor did gave their final presentation back to Gilad's point, what they did was they said, and, John, by doing this, this is how you can save two and a half weeks off your development schedule. And by John, by doing this, this is how you save another twelve days off your development schedule. And by the time they'd finished their presentation, guess how much time they'd saved? Right? Eight weeks. What a surprise. And so they did the absolute best job of linking their features to the advantages, to benefits, right, being the fabulous sales engineer. And it's the SEU did this, and I went with the company that came second. And I spent almost half $1,000,000 with the company that came second because after the POC, they did the best linkage of their technology back to solving my business problems. Right? And so I so it's not always the best product that wins. It's the people who link the tech back to solving the business problems and providing gain. You know, puppy dogs, unicorns, sunsets, walks in the beach as well. I got to keep my job, right, which is awesome. So, so that's my CIO story, but I think it puts everything in context. So it's a great story, John. And, just to kind of, add to that, for whoever's read the challenger sale, very, famous, sales literature that, I highly recommend to read if you haven't. But they they they share a very interesting stat in that book, and that is that after analyzing, I think, millions of of sales processes, they found that 53% of the purchasing decision had nothing to do with the product, but with the customer's experience throughout the evaluation process. And I think that is, very much aligned with your story here because you ended up choosing the vendor that maybe scored less technically, but you actually believe that they would be a much better partner. And this is something that I continuously have told my teams, ad nauseam. It's like your prospect is not just evaluating. your product. They're evaluating you as a partner and as a domain expert and as someone that they can actually, see as a trusted adviser in their business. And so your story there, John, just, reminded me of that, and I think, it's a very, very good point. Okay. So we're almost at the end of our time, and, wanted to bring up, one last thing, before we have, Jared, do we have questions from the audience for the forum? We have a few questions, but I I I also have a high level question or two as well. Go for it. Well, first and foremost, we're talking about, bringing proof of concepts to to paying customers. That that's massive. I'm curious as to, like, the benchmark averages. Like, what what what's good that we should shoot for? Like, the average conversion rate or or, like, above average and, like, the different levels. Alright. So let me take a shot at that. So like everything in sales engineering, Jared, the answer is it depends. And there's about 200 people out there laughing hysterically at this point. So the best conversion rate is one that is 10% higher than what you have now. It no. It varies. So I've seen conversion rates, like, of as low as 30% for, you know, simple, you know, one off products where it's just kind of mass produced. Right? And so, you know, everyone and their dog does POCs with this product. They get a 30% conversion rate. I've seen the conversion rate as high as 92 with a company that has a very complex product that reaches out and touches everything. So it it is kinda situational, but what is important is that you kind of meter it and analyze it and figure out exactly what is your win rate, why do you win, why do you lose, are there some products that POC better than others, Are there some regions that POC better than others? Twenty years ago, I was working for a vendor, and we discovered that ANZ, Australia, New Zealand, was closing POCs 20% better than EMEA and The Americas. So we looked why, and we stole their ideas. Right? So, you know, the the the the metering, the analysis, whatever sales ops can, provide you with, that's essential as well. So it depends, but it's directly proportional to the complexity of your product. I and I'm, curious, if oh, go on. a a stat that I saw, I I think it's in it's in one of our references in this for in this webinar. CSO insights said that, enterprise win rates are have gone down in the past few years. I don't recall if it was from '24, '23 down to this year, from '25 down to 17 or 18%, win rates. So if you're thinking about, elevating from that, it's definitely a competitive market, and winning is becoming more and more difficult. So having a a solid framework like this is becoming critical. Oh, did we lose John? Perhaps temporarily. I'll I'll wait for him for a second here. No. Here he is. Hey, John. You know, personal question. Like, with with the, the rise of product led growth and and, you know, enterprise tiers after that, are we seeing, in general, like, an increase of POC to to paid folks in in those cases because they're in the product earlier? And they're building some sort of comfort with at least, the ungated part of the ecosystem? I will say from from my experience, the Demostack, from our experience in the company is that there is a certain kind of product and a certain kind of enterprise, SaaS company that is able to do, PLG motion, or a a low entrance tier, but there are many, many very large organization enterprises that just cannot. Their product doesn't doesn't service that kind of emotion, and they they're stuck with it for better or for worse with the sales of motion have to go through these, through these sales cycles. And in showcasing the value, and these companies that have complex products require building out these frameworks, identifying the killers, and having systems in their back end that can show that value effectively and efficiently. And just to add to that, love if if I if I may, be careful not to get into a POC with any type of customer. And I think, you you know, these are very costly engagements as we showed earlier. So you. wanna invest them in the very, like, you know, top tier customers. Think PLG motions are great for, you know, the smaller SMBs, small business type customers that may just need, you know, a very short taste of your product, very basic features, and away they go. Right? They can sign up, you know, after a few days of running a free trial. But if you need to get into a more complex use case that requires customization and integrations and security audits, things of that nature, that typically does require a more structured POC. Hence, the, need for running one even on platforms that offer a PLG offering. Oftentimes, it won't be aligned with what the enterprise customer wants to test. And it's also there's, there's a myth around PLG, Jared. You can see many many companies that started in, SMB, mid market, motions that actually go up to enterprise, and they find themselves building, and maintaining large enablement and large sales teams because they they've identified that they need to service enterprise customers. They need to go up market, and they need to service enterprise customers at a different level. Totally. And, quick question from, well, from Ryan. Curious what percent of large POCs are asking for skin in the game payment from customer even if some or all is credited back towards the deal when they sign? I I am not seeing a lot of that. We we have within Marsh and Technical Sales and Up 2 Speed. I think we have over, like, 500 clients. I am seeing a minimal, like, single digit percentage of customers with skin in the game, whether it's, you know, I mean, you you got time, money people. And they'll put they'll put people in it. They'll put time in it, but rarely is it money. I actually, will respectfully disagree, John, with you on that one. Okay. Awesome. That's why we're here. and so, yeah, I'm actually seeing talking. it happen. I'm I'm seeing it happening more and more more and more often, and it can be done in several ways. You either put a price on the POC and you explain to the customer, you know, this is, you know, just your skin in the game to show us that you're serious about this. Oftentimes, companies will have a budget for for POCs. And, by the way, I don't know if it's, you know, just kind of a a coincidence or not, but I'm seeing that price being in the ballpark of 10 to $15,000 to test out a product. Those are the budgets I'm seeing procurement teams allocate when they are open to it. And what I've done as CRO in the past, is actually we the way we've structured deals is using a framework agreement, meaning that we would sign a twelve month agreement with a three month opt out. The first three months, they were paid for, right, but they were considered POC. It does require a bit more effort upfront, right, to go through the MSA negotiation, etcetera. I'll put that caveat, out there, but you're saving a lot of time, negotiating the deal after the POC and the customer rolls over into the longer term agreement. So, again, I'm not prescribing this to every business, but whenever you feel that customers have the inclination to get that out of the way and they have a budget, right, for testing out products, then definitely go for it, pick up that budget, and and get their, you know, their their their skin in the game for their engagement. It's I I I love both sides of that. From, Camilla, our software requires a lot of setup and hand holding. We lose deals after most of the trials. What's the best language to use to prepare the champion in case there might be some technical challenges, in in autonomous use. That's a tough one. Say say that one again. So, our software requires a lot of setup and hand holding. We lose deals after most trials. What's the best language to use with the champion of the deal in case there might be some technical challenges in autonomous use? So I I look at autonomous uses like giving it back to the client. Right? Like, Self serve. everything is. fine I'm sorry. when we're in the picture, but when we give it. back to them, shit falls apart. Pardon my French. Yeah. Yeah. So I I think one one of the great let let my big technical tip at the end, so I'm gonna preempt no one asking me this, is if you have not built an AI bot that is sitting over the top of your POCs monitoring what's going on, right, with the client's permission and reporting back to you, I mean, kinda like an Apple Watch or a Fitbit, then you are losing out big time. So you should be getting a steady stream of information back even if the customer's using autonomous use, unless it's production data, just so you can keep an eye on what what the heck is going on. John, you're stealing that would. be my big thing. You're stealing me thunder, John. As a demo stack, platforms like, to Camilla, platforms that offer product simulation layers that give you granular. analytics on what your prospects are actually doing during the POC. Gilad mentioned, set up a Slack channel, set up a cadence, set up an alignment framework, and set up a platform that gives you deep understanding of what the prospect, every individual touch point is doing within your platform, so you're able to get that signal before it's too late, before the POC has died out. Yep. You're you're welcome. Hey, sir. And and and that's a good closing. There's. a couple questions that we can't get to. I see James here. I'll share with these speakers, to to reach out directly and when not to answer it. But this has been an outstanding session, gentlemen. Thank you to Demostack, the tremendous sponsor of this who makes POCs easier and really every you know, from an enterprise standpoint, leveraging their demo platform in so many ways internally and for you all for being here. Is there anything, anything you wanna add, though? No. Thank you very much. We will be sharing, the six POC killers, the framework as well as the prompt that we'll build out a full out POC deck for, for the people who wanna, who wanna build it out autonomously, with questions. And I wanna thank Gilad and John, for joining me. We really appreciate the time, Jared. It's a pleasure. And, everybody, connect with these gentlemen on LinkedIn. Check out Demostack.com. Yeah. Chris. They're they're building the agentic future for for getting this right. Thank you all for being here. Thanks, Jared.