Sales Engineering discussion with Ramzi Marjaba

Guest Speaker

About the Podcast

In this episode of Proof is in the Pudding podcast, Vik and Ramzi discuss various sales engineering topics such as proof of concepts, building sales engineering teams, tools among many other interesting topics.

Transcript

[00:00:00] Intro: Welcome to podcast for sales engineers, Proof is in the Pudding. This podcast is brought to you by smart POC platform, Pudding.app and I’m your host Vik Arya.

[00:00:13] Vik: In our podcast today, we have Ramzi Marjaba today. He has been working in sales engineering space for a long time and networking and test measurement space. Hello Ramzi. How are you doing?

[00:00:24] Ramzi: I’m good. You’re actually one of the first people to pronounce my last name hundred percent correctly.

[00:00:30] Vik: All right, great. I’m glad I did. So, one of the things we had a chance to discuss before and we, about a sales engineer. You have been working in sales engineering space for a long time and you run an organization called We the sales engineers.

[00:00:44] I think in the sales engineering space, there is not a lot of content available out there. And you are one of the person or one of the organization who are building some really quality content for the sales engineers. So, first of all, thank you for that.

[00:00:59] Ramzi: Thank you. I appreciate that.

[00:01:00] Vik: What motivated you to start We The Sales Engineers platform?

[00:01:04] How did you get started with that?

[00:01:07] Ramzi: I am already moved to SE, so there aren’t any, SE’s around me or at least in my previous company, there weren’t any sales engineers around me and I started learning about sales engineering for my sales person. And he taught me the spray and pray method very well.

[00:01:24] Are you familiar with the spray and pray method?

[00:01:27] Vik: No, I’m not. What is that method?

[00:01:29] Ramzi: Spray and pray, so, we have a portfolio of 600 products that we sell and every time we go meet a customer, we just go through a PowerPoint presentation of all the 600 products and see if they’re interested in.

[00:01:40] Vik: Spray and pray means you just throw the information out there and figure it out what sticks.

[00:01:45] Ramzi: Pretty much show up and throw up spray, whatever it is. And I went through an experience where we had a big deal coming up and we invited the VP of sales, the senior VP. So, everybody in the sales structure, sales chain, and I, we went through one of those spray and pray methodologies.

[00:02:06] And afterwards the VP calls me into their office or the conference room. He says, Ramzi you didn’t do any discovery. Which then that was a year and a half into my career as a sales engineer. And I wish point, I asked, what is a discovery? So, a year and a half into my career, I didn’t know what that was.

[00:02:23] Vik: Right, right.

[00:02:24] Ramzi: And I found the other people in my company have the same issues where they don’t know what sales, like, how to do sales engineering, and the best way for me to learn, talk to other people. And so, I started a podcast and invite people over and they started coming on and it’s been going for a couple of years now.

[00:02:43] Vik: Yeah.  You, I saw you recently completed more than a hundred podcasts, which is a feat in itself. And are, are you planning to write a book or something with your experience running the podcast?

[00:02:57] Ramzi: I haven’t thought about it.

[00:03:00] Vik: Okay. It could be a great book actually, because so many people came across with so many ideas.

[00:03:05] It could be a great to compile them as a form of a book, maybe.

[00:03:09] Ramzi: Yeah, like a kind of Tim Ferriss’s Tools of Titans.

[00:03:13] Vik: Tools of Titans, exactly. Tools of Titans. You named that the gap. Can you share some of the interesting conversations that you had, which could be useful for the listeners especially around in the sales engineering area, some of your guest, which mentioned something that was interesting.

[00:03:30] Ramzi: Yeah. So, I’ve had a lot of different guests. One of them was John Care and he was on show 100, at which point my co-host Benny was talking about how the salesperson owns an opportunity or owns the customer account. And John Care corrected him and said the sales team owns the customer account, not just the sales guy, because as soon as we say like this guy owns this, the SE owns that.

[00:03:57] We’re washing our hands from some responsibility that we have. I thought that comment was great. A big takeaway that I’ve had from the podcast is that many SEs are not involved in discovery meetings. And that’s a big struggle that they have.

[00:04:14] Vik: I agree. Yeah. I think in some of the cases, especially what personally my experience has been, if there is a one-to-one, a mapping between account executives and sales engineering SEs still get a chance to go in some of those early meetings and hear from the customer first, but in other places where, in some cases where you have let’s say pool of SEs where they are, or they’re supporting multiple account executives, it’s been always challenging to figure it out what customer wants to do. And they definitely miss out in those discovery meetings and understand what the customer pain point is.

[00:04:49] Ramzi: And from my experience, at least from the people I talked to, that generally shows in the demonstrations where they go in and don’t demo what the customer wants to see. Or don’t have enough information. So, we have one guest we recorded the episode, but the episode didn’t come out yet. And he talked about how his company doesn’t do discovery calls.

[00:05:13] Like they didn’t want to bug the customer. They didn’t want to keep asking him.

[00:05:15] Vik: Oh, really? Okay. That’s interesting.

[00:05:17] Ramzi: Yeah. Yeah.  The inside sales rep does a bit of discovery, says their information out to the sales engineer. To the salesperson who then does sets up a demo instead of setting up with discovery call and over a few years of this particular SE just nagging them and telling them like, let’s just talk to them for five minutes, 10 minutes, whatever they started doing it.

[00:05:41] And now, although he doesn’t have the numbers, his close rate for the demos went up right. Yeah. So yeah, the key to a good demo is a good discovery.

[00:05:53] Vik: Absolutely. I think discovery. Yeah. I think it’s probably one of the, like you said, even though I see more and more people focusing on it, I think it’s still a lot of people struggle while doing discoveries.

[00:06:04] And I would say both at the sales and sales engineering level.

[00:06:35] Ramzi: Yeah. My pet peeve with POCs is right now, we are having this discussion with the customer we’re talking about his needs. And then someone would say, Hey, we can give you some licenses if you want to try it out. That’s the biggest pet peeve I have it. What are they going to try out? How are they going to try it out?

[00:06:54] Who’s going to support them? What’s the success criteria?

[00:06:57] Vik: Yeah.  That is correct. Yeah. I totally agree with that. So, can you talk a little bit about your personal experience as an SE what has been working well for you both let’s start with demo first, so in, let’s say, when you go out and do the customer demos, one of the things that we talked about is discovery, but usually what are some of the thoughts or some of the best practices you can share that has that have been working well for you as an SE.

[00:07:25] Ramzi: I, when I’m preparing for a demo the question, so what? Pops so often in my head that it hurts my head after a while. I’m trying to show this to the customer. I want to show this feature. So, what, how is that going to help the customer? A lot of people show the feature just for the sake of showing the feature.

[00:07:44] It’s a cool feature. I like it, but it doesn’t matter to the customer so we always have to think about it from a customer’s perspective. The best demo I’ve done I did by accident and I’ve learned a lot from it where we’re talking with. I didn’t do, I wasn’t part of the discovery call. It was early on in my career and a sales guy comes out of the meeting and he looks at me and says, you have a demo next Friday for virtualization.

[00:08:09] And you have different platforms for virtualization, ESXi, KVM, whatever, and ask them alright which platform do they want? Like they want to talk about the platform or they want to talk about our product running on the platform so they can go to the platform on our product. That’s fine. All right. Which platform it is?

[00:08:26] Is it, he said, it said ESXi. Huh? So, I went, spent my day prepared for it. And then I showed up to the meeting. And within the first two minutes I asked. So, you my sales guy mentioned that you guys want to do this on ESXi they’re like, no, it’s KVM. So that’s talking about the platform altogether, their infrastructure, and just talked about our product and saying whether it’s KVM or ESXi, it works the same.

[00:08:52] Look it’s running. It’s done. My demo went down from an hour to five minutes.

[00:08:57] Vik: Okay.

[00:08:58] Ramzi: And it just, the point of the story, is I started at the end. I didn’t show them every configuration step. I showed I started at the end and that was one of the best demos that I’ve done. And since then, I’ve been starting at the end.

[00:09:11] Plus I read a great demo book by Peter Cohen. He talks about the same thing. So, it’s not just my idea. Where you started at the end, and then you go back to show some details based on their needs.

[00:09:24] Vik: Right. So now the, one of the interesting thing is about that their products come in different spectrums.

[00:09:32] So for example, there are some companies who are pretty new in the space and their products, or even the product itself is new in the space. So, people don’t know anything about the product. But the network and test measurement space has been there for a long time. So, when you go out it’s more, most likely that customer has seen some flavor of it.

[00:09:54] So do you think that changes your strategy in any way when you let’s say, do a demo for the customer? Or how do you or let’s say, do you think if let’s say you wouldn’t have done a demo for product that customer never saw it before that would have changed your strategy?

[00:10:11] Ramzi: For sure.

[00:10:11] So right now, most of my customers are existing customers. So, the number of demos has significantly reduced. Because they already know the product. They just buy more ports or more licenses, more chassis, whatever it is. So, the demo gets smaller and the type of customer obviously changes the way you do the demo, because if I’m demoing to let’s say Cisco, I don’t know if you’re familiar with Cisco.

[00:10:39] It’s the biggest, one of the biggest networking companies in the world. They write most of the standards. And I’m demoing to someone who wrote the standard is going to be very different than demoing to their manager. If I’m demoing to them, we’re going to get into the weeds, we’re going to get into the smallest details, the bits and bytes, the manager just wants to know if it solves the problem.

[00:11:26] Vik: Do you in your, for your product, do you still do POC or it’s mostly around demos? How do you how does your sales cycle look like?

[00:11:33] Ramzi: With networking test and measurement, almost every customer wants to try it out on the on, in his environment that gets, because now almost everything is you inter operate with between our device and their device.

[00:11:46] Now they want interoperability always causes issue. So, they always want to try it out. So, the sales cycle, it looks like, we get a lead, a customer calls in, or we get a lead from marketing. Sales guy does the qualification. We do the discovery together demo proof of concept close the deal hopefully.

[00:12:09] Vik: So, in POC, is there any best practice that you follow that has been working well for you? Over other POCs?

[00:12:18] Ramzi: Yeah. What I do is I like to, I learned from our mistakes initially, we just used to bring in the equipment or play with it and then no one will play with it for two weeks, three weeks because they got busy with their own thing.

[00:12:31] So right now, when we do a POC, I like to get commitment from the customer that this specific person will be working on it for these five days.

[00:13:01] They’re just gonna go and move on to play with other things. Whereas if I’m there, I can support them. So, we get the agreement of who’s going to work with us. Second of all, we get agreement on what they want to do during this proof of concept. What are the test cases? What are the scenarios they want to run?

[00:13:16] Because if we don’t do that, every time we finish the scenario, they’re going to come up with a new scenario. And then there is no limit to the scenarios that they can come up with. But customers should know that not every scenario is going to work, work on every single product. If there’s a scenario that we need in the future, we can open a ticket, open a feature request.

[00:13:38] But what are the most essential tests that you need to run or scenarios that you need to run for this part to be a success?

[00:13:49] Vik: Yeah, that is correct, I think scoping the POC, making sure that we define a limited scope. It’s definitely a key to make sure that POC finishes on time and it is successful.

[00:14:01] Customer also feels that they have got something out of the POC, which is they were looking for. So, I think, yeah, that’s a, there’s definitely a important part of it.

[00:14:10] Ramzi: Yeah. And we could use that to steer the POC towards our strengths. If we can help the customer out by, we’re going to fill in the POC scope and then we’re going to give it to you and you can modify whichever way you want.

[00:14:24] So with that initial draft, we can steer it towards our strengths and then it’s on them to actually change it to if most customers are okay with it, because our, what were you, what we wrote down will solve their problem. But if there’s something specific that specific feature they’re looking for, they can add that at that point before we started the POC.

[00:14:45] And then, we’d have the time schedule we go in and we do the POC. I expect someone from the customer working with me, whoever decided to work with me, that they’re going to work with me and not be pulled into different meetings.

[00:15:18] Vik: And work with them or be present with them. But what would you recommend to the SEs who are, let’s say covering multiple States or a bigger regions where they cannot be with the customer all the time? What would you recommend? How they can get a better response time, or I think one thing that you mentioned very important is that if you’re running a POC, your product much better than customers.

[00:15:43] If you are there to guide them, it can move definitely much faster than letting customers just play on their own and figuring it out. And when they’re stuck in the problem, they will probably move on to something else because they have to then wait for your response. But how would you, let’s say how can person who’s working remote or working in a different time zone?

[00:16:02] How can they make sure that they are also moving their POCs faster, any tips for that that you’ve seen working?

[00:16:08] Ramzi: Yeah. So, I would say make sure that they understand that you’re going to call them or message them a few times a day. It’s not to bug them. It’s not to see if are you going to buy it’s more to see if they run into any problem or to get an update because you are expecting an update about the scenarios, especially if it’s a, short-term like five-day POC.

[00:16:29] Or like 10 day, whatever it is, you’re expecting updates on what’s working. What’s not working so that if something’s not working, you can get someone to help them or you can help them yourself. So, I let my customer know, like if during this POC you might get tired of hearing my voice. I’m not doing this to bug you.

[00:16:46] I’m doing this to make sure that we’re moving forward. I understand you have other responsibilities, but this is still like high on the list, which is why we selected this week. Where you said you’re free to work. All right. And make sure that a big mistake that I did early on in my career is I don’t hear from the customer that everything was going fine, which turns out it’s not true.

[00:17:12] If I don’t hear it from the customer. It’s very potentially they haven’t even looked at my, my, POC at that point.

[00:17:19] Vik: I agree. That’s probably most likely the case.

[00:17:22] Ramzi: Yeah, so find a cadence that works for you once. Like maybe once in the morning, before you head out to meet customers or during lunch, you call them up whatever it is and if you are in town drop by see them, when there is a POC, I would recommend you be able to visit locally once.

[00:17:43] If it’s important, again, depending on the size of the deal and all that, that will change the way you react.

[00:17:49] Vik: Those were some really great tips. I think it will be very helpful. I, as a final part, I want to come back to you the We The Sales Engineers again. So now that you have completed more than a hundred episodes, and I think you have your latest count when I saw the website was around 105, I think.

[00:18:06] Ramzi: 106 was on Monday.

[00:18:09] Vik: All right. So, what’s do you have any other plans for we the sales engineers or what’s your next milestone? Are you looking to complete another 50 or a hundred podcasts? What’s coming next. I guess that’s what I’m asking for we the sales engineers. What’s coming next?

[00:18:24] Ramzi: The funny part about that is there’s a lot of things that have happened next that I once heard about. So maybe I should go there. We do have a forum on we the sales engineers, which is to foster that relationship between different sales engineers. So, if you have any questions you can pop in and ask your question there, you’re going to get people answering those questions.

[00:18:44] I do have YouTube videos that are coming out on a weekly basis, especially during our lockdown right now, previously it was once every two weeks or at least when I got the chance. But right now, I have a little bit more time since I’m not driving as much. So, there is that What’s next. I just sent out a survey to the sales engineering community just to see what they need help with and based on the responses from there, I guess I’ll decide what’s next and I’ll let you know.

[00:19:12] Vik: Thank you so much for building this content. I think what you’re doing. You’re spending time and resources to build this extremely useful content for sales engineers. So, we really appreciate that. Thank you so much. And it, it’s great talking to you and I look forward to what else We The Sales Engineer does.

[00:19:29] And I’ll be always looking for the updates.

[00:19:32] Ramzi: Thanks, Vik. This was fun, I appreciate you taking the time to talk to me.

[00:19:35] Vik: Thank you, Ramzi.

[00:19:37] Outro: Pudding is a smart POC platform that elevates the POC experience for sales teams and their customers. Sales engineering teams use Pudding for tracking, managing, and automating POC activities. Find out more at pudding.app.