POC Success and Win rate discussion with Jeff Blake

Guest Speaker

About the Podcast

Jeff Blake is a sales engineering leader with 25 years of experience in sales engineering. He is currently working as the “WW Head of Sales Engineering” at Nozomi Networks. In this episode, Jeff and Vik discuss fundamental sales engineering activities, defining winning success criteria, POC success rate, key insights for SE’s, and many other sales engineering topics.

Transcript

Vik: [00:00:31] In our podcast episode, we have Jeff Blake today. Jeff is an accomplished IT professional with over 25 years of career work in corporate development shops and enterprise software organizations.

Jeff has recently taken on the Worldwide role for Sales Engineering with Nozomi Networks, a company dedicated to reducing cyber risk for worlds industrial OT and IOT organizations. Before Nozomi, Jeff was among the first

[00:01:00] hundred hired at Splunk, helping to drive unprecedented growth leading to their IPO in 2012. And, Jeff has managed SE organizations at various organizations like Informix, Tibco, and Ingres. And before embarking on a string of startup ventures. Jeff has a BIS from Wayne State University and has an MS from Northwestern University and to support his global organizations, Jeff travels regularly, but makes his home in Austin, Texas with his wife and twin sons.

Hello, Jeff. Welcome to the podcast today.

Jeff Blake: [00:01:34] Thanks Vik. Thanks for having me.

Vik: [00:01:36] Jeff, you have this amazing sales engineering experience, and, you know, we, we have a very few guests who have that deep and long experience in sales engineering.  Can you talk about how did you get into sales engineering?

Jeff Blake: [00:01:49] Sure. Like a lot of folks have probably a similar I, I got a engineering degree, undergrad and studied a lot of Computer Science. I was in the Detroit area when I graduated and ended up working for Ford motor company for about four years in there IT teams and learned a lot about    fundamentals which to a, my first vendor was a informing software.

I was recruited by a local team there and that was many years ago. And every, every job I’ve had since has been within sales engineering. So, it’s, for me, it’s been a great job. It’s a very, no two days are the same, which I love. I, I never saw myself sitting in a cubicle writing code or configuring machines all day.

I really like the, the varied tasks that SEs do and all the different industries that software companies serve. And so, started out small got into leadership after a few years. And you, you, you rattled off a bunch of the companies that I worked for. Recently, I finished 13 years with Splunk and

[00:03:00] was hired in as an SE and, and left there as the Global VP for the Centers of Excellence. I’m now working as the Worldwide Head of Sales Engineering for Nozomi Networks and I’m hoping to do the same thing there. So that’s, it’s been a great career. It’s been a great a lot of fun.

Vik: [00:03:20] That’s awesome, Jeff, you know I was just thinking, what kind of journey would that have been, you know, joining early.

And the first a hundred and Splunk, and then getting that kind of growth. In fact, in my last startup, I was the first member of a sales engineering team in Preempt Security, which recently got acquired by CrowdStrike. But even, you know, we had a pretty significant growth, but having seen the growth likes, like the Splunk debt, I’m sure that would have been an amazing experience.

Now, how do you define a fundamental SE activities? You’ve seen many organizations across the board. And how do you define, what are some of the fundamental sales engineer’s activities?

Jeff Blake: [00:04:00] Yeah, that’s one, one great thing about working the same role at a number of places as you’ve confined a lot of common denominators, and you can really understand what works and you know, we’re coming out of March Madness here, Vik, with basketball.

I, I always like to focus on fundamentals, just like a lot of basketball coaches really attribute their success to, focusing on the fundamental activities, you know, in basketball, there’s dribbling, shooting, rebounds, and just physical endurance.  I, I tend to see three or four very core fundamental activities that every SE needs to be good at regardless of what they’re selling and regardless of what industries they’re selling into, and those generally center around.

Discovery meetings, discovery calls, finding out, you know, what requirements your customer has for your potential solution.  It involves a lot of demonstrations and sometimes those are, out of the can, so to speak demos.

[00:05:00] Sometimes you build bespoke, customized demos with customer data and then proof of concepts, POC, POCs, are pretty ubiquitous in our industry.

And we tend to see that in just about every sales activity, sales cycle that we get to get pulled into. There’s a lot of other things proof other proof events like value assessments, or we might do health checks and things like that for existing customers. And a lot of SEs get, especially you spoke about startups earlier, you kind of have to wear many hats.

And a lot of times the SEs are in the center of all the customer facing activities. So, we ended up getting into some post-sales or adoption type activities to ensure that we’re keeping the customer successful so that we can continue to maintain them.

Vik: [00:05:47] Yeah. I, I think you, you absolutely said it correctly, that SEs, they juggle a lot of work.

And which also means is that they have tons of activities in their plate. Typically, how do you validate the priorities in, for the SE activities?

Jeff Blake: [00:06:02] Yeah. So, having just come to a brand-new organization recently you can really tell the priorities that the, that the organization is emphasizing by how they’re enabling their teams.

So, for SEs if, if you arrive and, and on your first couple of weeks, whatever they begin teaching you. That’s, what’s important at that point in time. And these things are circled like trajectories for small growth companies. They might be different than a well-established market dominant company.

But whatever you’re going through in your enablement, if you have a bootcamp enablement, or even if it’s informal whatever your supervisor is teaching you, if you’re an SE those are the things that organization is finding valuable. That’s what that’s sort of intrinsically sets up the expectations for you as an individual SE.

And those are the things that you have to get good at quickly. So again, generally, just as sort of a non-scientific and anecdotal analysis, I see discoveries, demos, and POCs as the key fundamental activities that we generally get involved in the most.

Vik: [00:07:18] Great. So, Jeff, having you today in the podcast, I think you know it, it’s a great time for us to focus on some of the core sales engineering activities.

So, in today’s podcast, I want to, where I really want to focus, is how do SEs get POC success? And how do they get improve their win rate, wherever they are? What, what are the, some of the things they can do to increase their win rate and get more POC success? And that’s what I want to focus on today’s this podcast episode discussion with you.

So let, let’s start with some POC fundamentals. How do you define what are some of the POC fundamentals that you have your defined in your organizations? where, you worked with your, SE teams that you’ve managed. What are some of the POC fundamentals that you define, in your processes?

Jeff Blake: [00:08:06] Yeah. Yeah.

That’s, that’s a great question, Vik. And it really does speak to the maturity of the organization and how successful their team is going to be. So, for me I like to see a very specific set of criteria put in place before a POC is executed and I think, most SE leaders would agree that, you know there has to be some sort of line in the sand.

We’re not just going to jump into a POC because A, they are expensive to do you know, they’re, they take time, time is money and B, they introduce risks. So, the longer your sales cycle goes.  The, the more risky it is for, for closing, right? Because anything can happen. Time, time steals all deals.

I’ve, I’ve heard sales people say in the baths. So, you really want to get through your cycle as

[00:09:00] quickly as possible. And that means being really well organized in terms of what the POC is going to do. And that usually involves a bit of documentation specifically what I wanted to talk today about the success criteria.

So, that’s really what I wanted to talk about today, you know, the other core activities demos. There’s lots of guys that are probably way better at me describing demos. There’s a zillion books on demos and in Amazon. So, but today it’s how to build the POC success criteria exactly.

To your point to increase the win rate. And there’s another activity in there that I’ll, I’ll save it as a teaser, but there’s a linkage between, you know, too, that can really help everybody increase their win rate and I’ll get you that.

Vik: [00:09:49] Absolutely. And I think you know, if you’re talking about the win rate and about the POC success, I think the most important topic is success criteria.

Because that is the definition that defines and kind of, it puts the boundaries around what POC success is all about. So yes, let’s, let’s talk about the success criteria. I mean it, it is, it is definitely a most important piece in the POC document. Can you talk about, you know, how do you see success criteria’s, what are some of the things that people don’t do well, or they should be, you know, looking into when they are defining the success criteria’s.

Or their discussions with their customers which, where, the content of the discussion goes into the success criteria’s. What’s your take on what’s the best way to handle these things?

Jeff Blake: [00:10:33] Yeah. I, I love the way you framed that out because the success criteria really is, the, the crux of the entire document.

I’ve worked at many organizations where we produce these enormous documents and really at the end of the day, what they focus more on is how you’re going to do the POC and where we all really need to be is why we’re doing the

[00:11:00] POC. And so, you can make a very concise, much smaller document. And my argument is if we’re to explaining why we’re doing the POC that makes it easier to do two things.

It gets everybody aligned in terms of what the, what the subsequent success criteria is going to be. And it also sets you up to take that document if you’re the sales rep or the SE, however you’re organized it helps you get that, that test that POC itself, socialized at your customer above the people that you’re working with.

In other words, the folks that are going to potentially be involved in the decision-making even potentially the economic buyer to steal a term from med pick, whoever is going to sign for the PO or whoever’s going to pay you for the, the solution you want them involved earlier than later, and that’s the, that’s the key.

So, why instead of how, I think that’s, that’s the takeaway.

Vik: [00:12:03] Makes sense. So, now a, let me ask you this question, let’s say if somebody has designed a success criteria document and you haven’t seen that before, let’s say it comes in front of you. And you have to let’s say, look at it and look at whether it has been designed well or not designed well.

What are some of the things that you look for? Let’s say, if you have to rate out of 10, what, what goes 10 out of 10? What goes, let’s say two out of 10. What defines that success criteria document?

Jeff Blake: [00:12:31] Yeah. Yeah. I’m chuckling, cause we’ve all seen, we’ve all seen probably way more weird ones than, than really good ones.

But for me, and I tell this to my team all the time, I think you could make us, I think you can make a pretty good POC document with one or two pages. And to me, I only care about one thing and that is the success criteria. The success criteria has to have some alignment with the business problem. It has to be, it has to capture the reason why we’re

[00:13:00] there in the first place. It has to tell the customer, why our solution is going to help them. And then the rest of it is just we’re, we’re there to validate that technology. And we, we tend to spend so much time on describing the environment and the technical aspects of this solution and all the things that we have to do to get the tests running and you know, all the data and all the configurations and all the machines that are going to get touched in the customer’s environment.

Those are all important, of course, but if you really want to improve the win rate, you really need to be, you really need to spend a lot more time on the, on the business side of the fence and the problem. So that that’s, that’s where I like to see people focused. So, that’s probably going to get you to use your scale. That’ll probably get me to the seven or eight out of 10. If you want those extra bonus points, what you’d like to do is have

[00:14:00] truly quantifiable information. That frames out what their business problem is. So, for example, if, if they’re experiencing downtime or if they’re at that customer is bringing you in because they have transactional performance issues or whatever it is, you, you want to ask some very pointed questions like does an hour of downtime cost your business?

And then how many hours of downtime, unplanned downtime do you have in a week or a month or a quarter, then you can go back and put all that together and come up with a very convincing model that says the cost of their problems. So, if, if there’s downtime and it happens frequently and they know that it you know, if they’re not pushing workers out the door, if they know that they have 10 people tied up at a $200 an hour per person. Those are very quantifiable and you can, you can add

[00:15:00] all that up and say, you’ve got $150,000 problem, or you’ve got a, you know, a, a $500,000 a year problem. Then it makes a lot, it makes it a lot easier, to come back and give them a proposal for your software, especially if it’s less than their, than their cost, their problem, because it really takes all the teeth out of them, arguing about negotiating over price.

It really maintains the price integrity, and it really helps align the business with that. And I think that’s where most of our teams need to get a little bit more encouragement to go, go find those answers. I gave you that a teaser earlier, you find those answers during your discovery calls. You find those answers earlier in the cycle, and you’re your sales rep.

If you’re an SE your sales rep has to know who’s going to sign for the PO, anyway, they they’re going to need to know who’s going to

[00:16:00] actually pay for this it’s rarely, is it the same person that you’re doing, the POC for we’re usually working with the technical folks and somebody has to sign for the check at some point, if they’re going to buy your solution.

So, I just say to our sales teams, if they have a fairly not very well formed POC document, I’ll say, hey, you should go find the economic buyer, now you should go find them sooner than later. So that you can come back and align with them after, after you discover what their problem costs.

Vik: [00:16:32] Right. Right. So, you know, this is really interesting success criteria or defining the success criteria is, is a very kind of a topic I really care about. In fact, when we were building this success platform for POC management, one of the thing that we always saw was and that we have the different kinds of SEs with different experiences.

Some SEs are really good in extracting that information, building the success criteria document

[00:17:00] and then converting into an eventually a win.  There but, there are some SEs who are, let’s say joining the organization recently and they still don’t know what is the best way to define the success criteria’s and how to do it.

So, one of the things that we did, we built in the platform was that how we can reuse the same success criteria, which has been winning a lot of POCs. So, if there is an SE, who’s using the success criteria, and we are, let’s say winning a lot of those POCs, why can’t another SE can use the same success criteria if the use case is same, let’s say if I go to a customer and they say, you know, these are the things I care about.

I have what customer wants, what the business use, you know, business metric is for the customer. I can now know what is the best way to define those success criteria. So, so that, that is definitely is I think one of the most important piece of creating the POC. But in, in your experience typically how would SEs get this information? One thing that you mentioned is a

[00:18:00] discovery, but I guess my question is that sometimes you have customers who are very technically savvy. They know exactly what they want in the POC, what success criteria it is. But, what about if let’s say SEs are going and meeting a customer, who does not know what they want.

They didn’t know they have a business objective, but they don’t really know exactly what the success criteria would look like. How would you recommend the SEs to navigate in those situations?

Jeff Blake: [00:18:28] Yeah, that’s a tough one, Vik, and it’s also very confident as well, you know if you ever persuasive sales person or you, if you have an outbound marketing team, that’s getting you leads that becomes a, a challenge sometimes.

And you really need to, sometimes it’s, it’s tough once you’re down the road, talking about a lot of detailed pieces, especially, you know, we’re all engineers. We like to build stuff we want to, you know, we see an interesting problem we want to tackle it.  But you, you need to go all the way back to the beginning

[00:19:00] and, and maybe re-ask the question multiple times, you know, why did you call us in, what, what do you think, what do you think about our solution and that can help you, and sometimes they haven’t framed it all out in their mind.

It, it requires you to kind of tease it out of them, ask them the same question in different couple of different ways, or really hone in on the problem. And if you’re, if you’re talking to someone and they can’t articulate a new issue with their business, if they don’t feel like there’s a lot of compelling problems or, or if they don’t know any of the quantitative information around that, you’re, you’re probably not appealing to the right person.

And you know, what you need to do is tap truly, find out who else on the team is responsible for these things. Try to navigate wider out of the organization is, is the answer to your question so that you can ask those same questions to multiple people, but it’s really, it’s really attempting to focus on the, the business issues and the dollar impact of that, that we tend to skip.

Vik: [00:20:08] Right, right. Yeah. I think the, the key point is, that by the end of that discussion, whether it happens in one rounds or multiple rounds, the key players who were involved in the, in the POC. They all understand the success criteria’s clearly, there should not be, oh, we are accepting it because you are saying so, the customer should know exactly what they’re getting into.

Otherwise, what happens is they start with something that they don’t know. They just accepted the success criteria because the SE said, so. And then somebody else come becomes a subject matter expert comes in and he totally says, oh no, this is not what matters to us. And now we want a totally different kind of criteria’s.

And then POC, there you go. There’s, there’s a scope creep and then you you’re running those POCs for months and months. So yeah, I think the success criteria definition is really important, but one thing very interesting that you said earlier, actually you said start with a business problem, not the technical problem. Can you elaborate on that? What do you mean by that?

Jeff Blake: [00:21:05] Sure.  I think again as engineers or as stewards of the company that we’re representing, we love to listen to a couple key words, come out of the customer’s mouth and then jump right on that and talk about our technology and talk about all the other customers in similar industries that have solved similar problems to their, as in how well we did that, that’s the natural inclination of a, of a sales team.

And what really has to be done is understanding again, why are we there? Why are we there in the first place yet? You have some specific issue or problem or challenge, what is that challenge and what does it mean to your business? You know, what’s broken and what is its impact?  And if you can get that tied back to dollars, then the rest of it’s easy because you know what you’re up against, you know, what, what size of a problem it is, and you know, where your, your solution can fit into that.

Vik: [00:22:06] Right, right. So, no, this is really a great discussion. Before we wrap up the discussion on POC. I have one last question for you. So, Jeff, you have been in various leadership positions in many different very well-known organizations. What are some of the key metrics that you track as a, as a SE leader?

Especially we already talked about the win rate and POC success.  Can you talk a little bit about what are some of the metrics that actually show you that whether you are going to have a better win rate or not, or how, how the POC, what all things are going, what are some of the key metrics that you really care about?

Jeff Blake: [00:22:43] Yeah, I think there’s some there’s this great question. We could probably have an entire podcast, but I’ll give you a couple of the ones off top of mind. In terms of the sales cycle, I think there’s some good metrics that the SE and the

[00:23:00] sales person really need to make sure they’re capturing. And it usually, centers around qualifying the opportunity, right. So, is, is it a valid problem? Is it an, a budgeted project?  Is, is there some quantification associated with the problem as an impact to the business?  Those are good things to capture in terms of personal progress or personal measurements of a, of an individual SE I think looking at their win rate is pretty good.

Some, some organizations split out the technical win from the overall win. In other words, we’ve all been part of sales cycles where we do a really great job in terms of the POC or the proof points or the demos, or maybe all the above. We really, we really killed it as an SE team, but then we ended up not getting the deal for one reason or another.

So, a lot of companies will split out technical win versus deal win or however it’s framed out.  Those are, those are

[00:24:00] interesting ways to, to get a little deeper dive. And then in some of the past places I’ve worked I look at success rates and then you know aligning enablement or certifications or some of the other specialty backgrounds that are associated with the roles for the SE or the level of that SE whether they’re a senior SE or a early career SE.

And if, if people are, ahead of the curve in terms of taking their training, getting their certifications, understanding what they’re, what they’re delivering. It shouldn’t be as surprised, but those are the folks that tend to tend to have higher win rates folks that are behind or, you know, and this is not just an indictment on younger, less experienced SEs versus senior SEs, a lot of senior folks are behind the eight ball because they’re juggling a lot of plates and they don’t get around to the certifications. And it’s, it’s interesting to kind of note that in many cases they may be

[00:25:00] their win rate might be below baseline. And that could be an indicator of other things, you know, just general disorganization or maybe they’re working with some reps that are really chaotic, spell these numbers and being able to look at things objectively often help you dig into the situation and find out if you need to help an individual or, or maybe move them to a different part of the team so they can, you know, get a little bit better traction.

Vik: [00:25:27] Awesome. Well, that’s a great insight, Jeff.  Now, I think I want to ask you now a couple of question’s a little bit in different direction. So, now that you, you know, you have managed a team of sales engineers, you have worked in many different companies. What are some of the tools or you have found useful, or if you have any hacks or productivity hacks that you can share with us that you found that really worked well in managing your, you know, juggling things, managing teams. Anything that you can share with us?

Jeff Blake: [00:25:56] Sure. So, I think  I do have a couple that come to mind quickly, but I do want to say this before,  one thing that I think is crucial in terms of hacking for success would be just an overall, an overall philosophy of sharing and a couple of the organizations I’ve worked for in the past have, have been really good about being completely transparent with every aspect of every sales cycle information  whether it’s product information or sales cycle information, or even third-party partners or external kinds of information, anything that could help and anything that I find that it helps me if I can, if I can get that out to the rest of the team.

And everybody else feels the same way. I think that’s, that’s always an organization that’s going to be higher, performing higher functioning than a team, that’s got a highly competitive environment and people keep things to themselves. So, it’s, we all face the

[00:27:00] challenge and you’re solving part of the challenge with Pudding, but a lot of that is centralizing the information and giving access to everyone.

I think that’s a key philosophy that every leader that wants their team to succeed really needs to explore and develop.  So that’s, that’s a very pie in the sky answer, but you want some, some actual on the ground answers. I think if your team subscribes to that it it’s, it’s good to get aligned with.

Your, your IT team or whoever builds out your CRM extensions and put some of these things into the CRM immediately, it can be as simple as let’s attach the document templates to every Salesforce record. And we won’t do a POC unless we see X, Y, and Z. For example, that’s a simple way to do it. If you, if you have the resources and you can do this, go ahead and set it up.

So, all of that data can be field driven and you know, you can input the, the notes or input the metrics or input, whatever it is, tie it to opportunity records.  And if the more that you can have automated and field driven into a, into a centralized data store, then the better you’re going to be and the easier it is to share again, back to the core philosophy. 

Vik: [00:28:12] Right. No, I like, I like what you said. I think that definitely is a you know, kind of a quality of a high-performing organization. So.

Jeff Blake: [00:28:21] Yeah, I can tell you one, one last thing that’s helped me recently is, I use Evernote quite a bit. I use it for taking notes, I use it for sharing, I use it for constructing lists which is great.

But I, I, I tried something based on a couple of articles I’ve read recently about not using to-do lists and instead, you know, we all have lists and everybody always says before you go to bed or before you close your laptop for the day review, what you want to do tomorrow and check off a few things, you know, don’t try to boil the ocean, pick off one or two or three.

[00:29:00] Big hitters and tackle those as soon as you can in the morning. Well, that’s great until you wake up and find out that something’s burning or on the other side of the world, or there’s a catastrophe or a, what happened to me a month and a half ago?  The entire half of the world didn’t have power or water or gas.

So, things get in the way. But what I’ve been doing is instead of making a list with my top two, three, four things, I will actually block time for each of those and for points in my calendar during the day and that way someone can’t schedule on top of it. It doesn’t, it doesn’t mitigate the dumpster fire down the street, but it, it does help me.

Look at my calendar and kind of move from there because we all, we all have meetings. We all have calls, especially in this world with Zoom, so it’s important to a block out time. And, you know, I tell all my team block out a few hours for yourself, but really what goes the extra mile is put that one item off your to-do list in there. Don’t get off that task until you’re done.

Vik: [00:30:11] Oh, that’s, that’s a nice hack. That’s really definitely. I can definitely see the value. It’s a great hack. Well, Jeff, it was, you know, pleasure talking to you. I think we covered today, one of the most sought-after topic in POC world.  I think anybody who’s doing a POC cares about the success criteria, cares about the win rate, and cares about the POC success. So, thank you for sharing your insight, and we really had a pleasure talking to you today.

Jeff Blake: [00:30:35] I need to thanks a lot, Vik. Appreciate it.

Vik: [00:30:37] Thank you, Jeff.