Name: Global Partner Webinar: From MDR Demo Rockstar to POC & Winning the Business
Uploaded: 2025-10-14T15:16:07.569Z
Duration: 1 h 12 s
Description: Global Partner Webinar: From MDR Demo Rockstar to POC & Winning the Business

Transcript for "Global Partner Webinar: From MDR Demo Rockstar to POC & Winning the Business": Hey, everyone. Welcome to part four of our managed detection and response webinar series. This time, we are talking a bit about some key strategies we use here at Rapid7 to ensure a smooth POC that highlights targeted use cases and drives value all the way across the finish line. But before we get into it, let's do some introductions. If you are around for part three, you already know me, Zach Jones, senior solutions engineer here at Rapid7. But today, I brought a buddy of mine along, someone I work really closely with, Matt. Hey, Matt. Do you wanna do a quick introduction here? Yeah. Thank you, Zach. Everyone, my name is obviously Matt Howard. I work very closely with Zach here in the Mid Atlantic region of The United States, working with our partners to help deliver effective solutions specifically around MDR to our customers. So excited to get into today, specifically, MDR POCs and how we effectively work with our partners, to deliver those effectively. So, Zach, I'll let you keep running with it here. Awesome. Before we get into talking about what it takes to really run a successful proof of concept, I wanna take a moment to recap what we've talked about so far. So for anyone that is just now joining us for the first time, this is part four of a five part series on Rapid7's managed detection and response offering. And what you've missed so far is part one, where Mikhail and Renee ran us through the overview of Rapid7's managed detection and response solution, which, by the way, is a end to end solution and partnership where Rapid7 helps with everything from being proactive with vulnerability management and doing threat hunts, all the way through investigating detections and alerts in customer environments. And then all the way on the other side, having uncapped and untimed incident response included as well. So that was part one. Part two is where Ellis and Connor talked a bit about the strategies you can implement to identify opportunities for your customer base, helping you know exactly what to look for to perfectly align your customer needs back to Rapid7's detection and response. And, of course, in part three, I walked through the technical demonstration of InsightIDR, our SIEM, as well as some use cases and examples of how InsightVM, our vulnerability management, and InsightConnect, our automated store workflow solution, how they all work together as part of the technology and backbone that makes this service work. Of course, if you did happen to miss any of these other previous sessions, you can head over to the manage detection and response position prove protect webinar series page and scroll to the bottom to find and register for any of the previous sessions in the series. Also, don't forget to check our partner portal webinars and events pages regularly for any future planned webinars. So, Matt, I think a good place for us to start today would be maybe outlining some of the goals and objectives for today's call. Absolutely, Zach. And so I think our goal for the session today is to bring you all, the partners, into Zach and I's world as we're setting up these evaluations so that we can more effectively work together throughout an MDR POC. In order to maximize the success of a Rapid7 MDR POC, it's critical that we understand the criteria the customer is utilizing to evaluate solutions, the prioritization of that criteria, and what use cases may be unique to their business so that we can build out an effective plan. This criteria will also determine how we drive the POC process and communicate business outcomes to the customer that ultimately meet their needs. And so some of the key areas we're gonna focus on throughout today's session include qualifying and MDR proof of concept. A lot of these topics might seem a little repetitive from the other sessions that we've already had, but it's really important at the start of a POC that we fully understand the scope of the project so that we can effectively drive the POC process, but then ultimately executing on the business as well. Then we'll move on to scoping and use cases. This is obviously critical to understand that what the customer is looking to achieve are outcomes that Rapid7 can effectively deliver on. And then thirdly, we'll move on to the POC process and building towards driving the purchase. So what is the POC gonna look like from technology setup to validating criteria to hopefully if things are going well throughout the POC driving that business earlier on in the process? And then finally, we'll speak to more specifics around you, the partners. How can you guys ultimately add value throughout the process to make it run as smoothly as possible, both from a sales perspective, but then more importantly from a customer perspective as well. So, Zach, I think that's a lot of what we'll hope to hit on here. Awesome, Matt. Thank you for that. Let's go straight to the top of this and start talking about some of those qualifications. One of the first things that I do as a sales engineer is to review conversations that we've had so far and chat with my account executive, like Matt, and my partners to get a sort of preliminary alignment on what the customer is most interested in and possibly what we might be competing against. Matt, what else here is key? Yeah, Zach. So there are a few questions I'm asking when I begin speaking with yourself, I begin engaging with our partners when we're discussing a proof of concept. And, surprisingly, one of the first questions I might ask is, does a proof of concept even make sense in the first place? And the reason I'm asking that question is, first and foremost, the customer is about to dedicate a lot of time, generally thirty days, to this evaluation. Is there any way that we can save them some time and resources they can be allocating to other projects, by validating that criteria in a different manner other than getting them hands on with technology. And selfishly, the second reason is as sales professionals, our goal is how can can we accelerate the deal cycle, shorten the deal cycle a little bit, and maybe there's, you know, one or two conversations we can have with other stakeholders in Rapid7 to help validate some of their success criteria that circumvent the need for a POC. So I'm gonna be asking that question, and a lot of the time, some of this criteria that we're able to validate by circumventing a POC is gonna be asking questions like, what's the day in the life of a customer look like? How will I engage with my cybersecurity adviser? So from the customer's perspective, that dedicated point of contact with Rapid7, what does that look like? And then how is the SOC team ultimately working on my behalf in the background? I wanna get an understanding of that. And so those are some of the questions that customers might be asking from a services perspective that we can help validate in other ways besides a POC. And so the way that we're able to do that is, you know, a customer reference call, giving that prospect or customer an idea of, like, hey. Is there another organization of a similar size? They might be in my industry as well that can give me their firsthand experience working with Rapid7's managed detection and response. Getting a dedicated cybersecurity adviser on a call with the customer is another way. So having that cybersecurity adviser almost do a mock engagement with the prospect to give them an idea of, like, hey. Here's the level of support I'm gonna provide to you guys on a regular basis and what you can expect when you're onboarded as a Rapid7 customer. And then the third thing that we're able to do is actually bring on a member of the SOC team to give the customer an idea of, hey. An alert fires off in my environment. The SOC team sees that alert. What does their workflow look like? How are they triaging an alert, validating that it might be an actual event, and then taking action action ultimately on the customer's behalf. And so those are some of the ways that we can validate the customer success criteria without actually having the POC. But now I don't think we're always trying to avoid a POC at all cost per se. So let's assume that the customer does want a POC. It's part of their process. It makes sense for their situation. What are some of the questions that I'm ultimately asking from a business perspective to determine that this engagement makes sense? And so diving in here, this might be a little bit repetitive from some of the other sessions that you guys have already watched here with our team. But the first question I'm asking is, you know, what is their budget for this project first and foremost? Is there an incumbent solution that they're gonna be leveraging budget for and we're gonna be swapping out with that solution? Is it a dedicated line item for this year to implement a new managed detection and response provider, or are they looking to POC or test to ultimately purchase this next year, and they're currently going through their budgeting process? So budgeting is number one. Then we're moving on to who are the technological and economic buyers in the situation. Obviously, whoever is able to give the ultimate thumbs up that Rapid7 is the right chosen partner to deliver on the use cases that they're trying to accomplish. We want that person to be heavily involved in the POC planning process and then validation throughout the POC as well. But then the second piece is who's the economic buyer? Who signs off on this purchase? It would be great if they're gonna be highly involved in the proof of concept. A lot of the time, though, we understand that this won't be the case. So we wanna understand that if we do get the green light on the tech side of things, what's our engagement look like with that economic buyer post evaluation? Moving on from technological and economic buyers, we're then asking, what's the timeline here? When are they looking to implement a solution? When are they looking to purchase? Because Rapid7, what we're able to do generally is do a POC for thirty days. We can then host the customer's environment for another thirty days post POC. So in order to lighten the load, oftentimes, what I like to do is reverse engineer that timeline with the customer to say, hey. We're gonna test for thirty days, then post POC, assuming everything goes really well, we have another thirty days to execute a purchase so that then we can roll your POC environment right into production and lighten the load on you from a resources perspective when you're onboarding. So what's that timeline look like for the customer? And then the final question that I'm gonna be asking is what's the size of their environment? How many assets do they ultimately have in their environment? Reason being that Rapid7 licenses RMDR based on the number of laptops, workstations, servers in the customer environment, anything that's gonna be taking a Rapid7 agent, And this is gonna allow us to align on cost ahead of the POC. We wanna validate with that economic buyer that assuming everything goes well as we're walking through and validating the success criteria, they're gonna be able to move forward with the purchase and that the cost we present to them is ultimately working. So, Zach, those are a number of the the questions that I'm gonna be asking when engaging with yourself, when engaging with our partners to determine that a a POC engagement does make sense. But curious if there's anything more on the technological side that you're thinking about when we're having these conversations as well. Sure. Yeah. After we sort of validated things on the business side, we wanna make sure that we validate on the technology side. So let's start with use cases. We we may want to kind of review again those use cases they're bringing to the table to make sure that the problems that they're looking to solve are problems that we can clearly demonstrate solutions for and show examples of during the POC itself. This may be a bit obvious, but certainly something we wanna consider before starting the proof of concept. Next, we want to also sort of evaluate the use cases to determine if they can be easily validated. In other words, are the use cases more subjective or or are they clearly objective? Without having a concrete way to demonstrate that, what they're looking for is something we can provide, we may end up having moments during this POC without sort of clear direction. I'll chat more on that later. Lastly, what else do we know about your customer's evaluation? Are they also looking at other solutions? Are they evaluating our solutions, as they are all planning to leave a previous solution? We wanna make sure that if there's any major differentiators that could be helpful for the customer to experience, then we make sure that somehow we include those in those use cases. And, of course, in a few cases, you may have customers with limited event sources or, complicated multi domain structures or a changing environment due to things like acquisitions. All this can make for a more complicated proof of concept. Make sure to check-in about the Rapid7 solution survey that we have so we can get ahead of any technical requirements that we may need to be addressed, may need to be addressed or considered as well. That's really helpful for us. Alright. So let's take a look at some of the actual use cases that we may be running into. Generally, what we see are use cases that fall into three categories, basic, standard, or advanced. If the customer only has a few things that they want to see, sometimes we will want to suggest a few other use cases that maybe haven't been considered. We wanna match these use cases with the customer's technical ability and understanding. If this is a customer's first time working within a SIEM, we likely want to stick with the basic and standard use cases here. Things like Rapid7's dashboards that are a single click for them to create and use or maybe something out of the box like some reporting that is available would be great here. If the customer is a bit more experienced, then we want to start and lean further into the advanced side. The advanced use cases tend to be a really great way for us to differentiate from some of the other competitive solutions they may be evaluating. If you're not sure, then the absolute best way is to continue to ask the customer for use cases and ask directly. Now often, what they may say to this is, they may start to list event sources. They may say things like, I wanna make sure that you can ingest, logs x, y, and z. And this is fine, but you wanna do your best to drive this conversation towards actually experiencing the tool itself. Sometimes I'll even say on the call, team, I know we want to test all of these sources and make sure those work, but what I'm really interested in here is making sure you have a chance to play within the tool and experience the SIEM and how it may come into your day to day activities. Lastly, one of the most important things to consider here is how you plan to validate those use cases. Sometimes customers will come to the call with very objective cases like, I wanna see if InsightIDR detections are better than what we have today, or are the reports that we're gonna get from InsightIDR, are they better than what we see today? If you get these kind of suggestions, try to turn them into use cases that you can actually validate. If they want better detections, ask them for examples of things that maybe have been missed in the past with the previous technology. We can't necessarily trigger those things to happen during a POC, but by knowing a specific example, you're much closer to being able to actually validating this through demonstration or reviewing detections hands on or even bringing on a Rapid7 SOC person to the call. If you keep these things in mind, you'll have an incredible set of use cases that will certainly check off those boxes for what they're looking for and get you closer to that finish line. Now let's take a moment to actually look at the POC process from start to finish. Okay. And so let's take a look at our timeline here. We're obviously gonna start on the front end with a proof of concept planning call before we even dive into the POC and cutting on access for the customer. So a lot of what we talked through during the qualification phase of this session is what you're gonna be validating on that proof of concept planning call. So establish success criteria that both meet the customer's business outcomes but are also achievable within Rapid7 Spanish detection and response solution, determine what event sources they're gonna be testing throughout the process. So we obviously want the customer to be confident with all their security event sources, but it's pretty important to understand which ones are we gonna focus on to drive a lot of that success criteria and also set a firm understanding with the customer on the amount of work that goes into the actual setup of those event sources and of Rapid7 itself, which which Zach will talk through a little bit more. And the final item that we wanna hit on is mapping out a timeline, which is critical for the POC process from a business perspective. We want them to understand, okay. Today is, you know, the planning day. When are you gonna actually configure Rapid7? When are we gonna kick off the POC to begin validating? And then when does wrap happen? And what happens after wrapping up the proof of concept so that we can move forward with executing a purchase? So that's a lot of what I'm looking to cover on the proof of concept planning call. Zach, I don't know if there's more that's going through your head as well. Yeah. For the planning call, again, I like to really lock in these use cases and those event sources and have everyone agree on the call that that's what we're gonna do so that it doesn't sway, move, or expand as we move along. Then after that, I basically give them a little bit of homework to consider before our next call, which would be the kickoff call. The homework there is really simple. We want you to log into the platform, grab the installation package for that collector, and install it on whatever host that you've set up, be the VM or whatever service you've got available. Then once the collector is there, we want you to next take that agent installer and put that on a handful of machines. I like to give direction here to say five to 10 or fine. You don't have to go much more than that. I would I would wanna see agents on a workstation and a server. If you've got Linux or Mac in your environment, then maybe put them on different, OSes as well just to validate what that looks like. So that's the homework between the planning call and that first call that we have, which is the kickoff. We're gonna ask the customer to do those things. Now we'll get on that kickoff and validate that all this is installed and looking good. If there's any troubleshooting that's necessary, this is where we'll do that. So that's the deployment of Rapid seven SIM section. Now from there, a week later, we're going to jump in, and the homework that we're gonna give them, I should say, between those calls is event sources. We're gonna take those event sources that we've talked about so far, make sure they have the right documentation to get started on those, and we'll give them a week to work through that. Then during that check-in, we're gonna do the same thing we did for that first call and validate. Is there any troubleshooting we need to do here? Let's see what kind of logs are coming in and make sure that the technology is looking good. Now between those two sessions, that is sort of the, the first chapter. That is the technology stand up piece to the POC. I really want for most of my POCs to have all the setup complete by the end of that second meeting. So this means that the rest of the POC timeline is all about getting into the tool. It's all about going in and actually experiencing, the different sort of use cases and validating there. So by that third call, I'm gonna wanna make sure that they're feeling familiar with the tool. I'm gonna show you them show the customer some tips and tricks, give them maybe some homework to build a dashboard or, export a report. I'm then going to also make sure that I'm focusing back in driving to the very beginning of the conversation where we've talked about that success criteria. During these calls, I'm gonna make sure that the things that they are experiencing directly align and solve for those problems. Then at this point, depending on the sort of time they've put in, we have maybe checked off a couple of those use cases already. But we have another week left to really go back and fill up any of that time with those use case scenarios that we've talked about, but also reinforcing where we can that this is truly solving those problems. Then from there, after that sort of four week period, we've got the technology completely stood up. They've gone through all of their use cases. We will then go to a POC wrap call. Now for myself, when we get to this wrap, I like to be very explicit. I like to say, okay. Let's take that list of success criteria that we started with, and let's all look at it together. Starting at the top, how do we feel about the first one? Were we able to successfully do this for you within the POC? And I am gonna go for essentially giving green check marks across the board so that at the end of this, we could say, these are the things that you needed to solve for. We've successfully solved for them. What are the next steps? And that's where I'll pass the mic back to Matt here to kinda work through the rest of the wrap. Yeah. And so as Zach alluded to, getting that green check mark, getting the ultimate thumbs up that Rapid7 is the technology of choice or at least a viable solution is absolutely critical just to ensure that you verbally get that commitment from them. But then you as partners where you're able to step in here on the wrap call and post wrap call is how can we drive the process forward of actually entering whatever their procurement, legal, and purchasing process ultimately looks like. We wanna move from the POC wrap into that later stage as quickly, effectively as possible. And so getting alignment with the customer on what that ultimately looks like is kinda where we go from here. So, Zach, I think that really encapsulates from front to back what the POC process looks like and where we're driving to from there. Awesome. Well, let's jump into next some ideas around closing and winning the business, and let's talk through some of those key points. Okay. So throughout this session, Zach and I have covered a lot in terms of a proof of concept from qualifying it on the front end, talking through the planning process with the customer, setting proper expectations as far as their engagement, and then the actual detail of going through the proof of concept itself. So now as we wrap up here, I think it's important to talk about how you all as partners can help us accelerate the deal cycle, effectively run the POC, and some of the key areas that you can add in expertise in order to help us win the business in the end. So a few quick bullets here. I think, really, the first one is confirming that success criteria. Now you might say like, hey. This is something that starts earlier than a proof of concept. Like, yes. It does. So early on in that discovery process, the sooner that you're able to put in our year what the criteria the customer is driving towards, the better so that we can help validate that during the discovery call, whatever demos that we have to go through, the POC planning process, and POC as well. And the other part of this is that you all are obviously agnostic advisers to the customer. So at the end of the day, you're able to help even more so reinforce that success criteria and how it aligns well to, you know, rapid seven and effectively delivers on whatever, yeah, the outcomes are that they're hoping to achieve. Now bullet two, aligning that success criteria to business objectives for the leadership team, I think there's really two prongs to think about when we're hitting on this item. And number one is that you're having conversations with your customers on a weekly basis. There might be some perspective on their business that you have that they don't even recognize, or maybe it's just a normal part of their day to day that Rapid7 from an MDR perspective can align to. So maybe the customer has objectives a and b that are super critical for this project, but maybe there's c and d that a managed detection response partner can help them drive towards that they're not even thinking about in the front of their head, but you're able to add additional value and help us close and accelerate the business based on us achieving a number of criteria, a number of business objectives. And that takes us to prong number two, which is communicating those objectives and outcomes up to the leadership team. I think throughout the course of a proof of concept, a lot of the time, there'll be a few technical folks heavily involved in the evaluation. Maybe they're not the ones at the c level or at the board level having the conversations about how this investment is ultimately gonna help have, and achieve business outcomes. And so you helping us understand, like, hey. What does that conversation look like in the background after we wrap up the POC? Who do we need to build out a presentation for? Can we meet with them to help them sell this up internally? Helping us navigate those waters is super critical so that, you know, we're not only selling to the people that we're testing the technology with, but we're also able to effectively sell to whoever's operating in the background as well. And I think that brings us to our final point where it's you know, we have, you know, the hands on folks that are doing security on a daily basis. We have their leadership team. But then who are the other stakeholders in the organization that get involved with security, they could potentially stop things, and they're part of navigating this ultimate purchasing cycle. And when's the right time to engage them? I think oftentimes in a proof of concept, if things are going really well, we're building positive momentum. Maybe in week two, week three of a POC, it makes sense to start sending along legal documents, getting in talk contact with that person from procurement to understand what the rest of the process looks like. So how can you help us navigate those conversations and accelerate the deal cycle? The more effectively we can cover off on these three points, the more efficiently that we're able to run a sales process quickly, help deliver effective outcomes for your customers, and win the business. Thanks, Matt, for joining us on part four today and helping us walk through qualifying a POC, planning for effective success criteria, the POC timeline, and some great advice, on closing the deal. Now before we wrap up today, I'd love to take a moment to remind you about the packed partner program and partner resources we have available for you. To support our partners, the Rapid7 partner portal has a wealth of tools and resources available, including information on your own PACT program progression. From finding sales and marketing tools to registering your deals, progressing opportunities, and checking on renewals, the partner portal also includes access to our formal partner academy training in important certifications. Some of our key detection and response resources available to you via the partner portal are noted here. Please feel free to leverage these assets in your conversations with customers and prospects or just for your own learning as you dive deeper into the product. To take the next steps in your learning journey with Rapid7, please visit the Partner Academy. Go to partners.rapid7.com and load your Rapid7 partner portal homepage. Next, navigate down to Partner Academy and go there. When the page loads, you'll see a brief summary of the Partner Academy and a orange button titled start your journey. Go there, and a new tab will open automatically displaying the Partner Academy home page. That's it. All of your certification achievements in Partner Academy will be tracked and automatically updated within the PACT partner portal to advance your progress within the program tiers. Reminder, this is a requirement as a member of the PAC program as well as a benefit. Rereveling occurs in January, so get started today to unlock your PAC program benefits and incentives. The packed program tier re leveling will occur in January, so make sure you meet all of your training requirements by completing your partner academy certifications. Click start your journey and get started today to unlock all of your packed program benefits and incentives. Once within the partner academy, you just need to identify your role and your knowledge level. Whenever you log in, you will always find your learning path under the partner learning journeys. If you are a sales rep, which we call the Rapid7 sales professional learning path or RSP for short, all you have to do is click the RSP tile to access all of the courses available, that are focused on building your knowledge and skills for your role. If you are a solution engineer or a solution architect, which we call the Rapid7 technical sales professional learning path or RTSP for short, your home page tile will look like the second one here in the image. Clicking this RTSP tile will give you a focused view of all the presales technical content you need to build your knowledge and skills around Rapid7 solutions with as much breadth and depth as you like, including some advanced technical certifications that provide a deep dive into product features. But let's say that you are a longtime partner with Rapid7 and already have a ton of experience selling, positioning, demonstrating, and validating Rapid7 solutions. You may not necessarily need to explore the extensive content within these courses, but still want the recognition for your expertise in these areas. All you need to do is prove it. The tile on the right side of the slide is where you will have access to all of the certification exams to validate your knowledge and skills without spending the time required to complete all of that coursework. Click into the certifications exam tile on the home page to take advantage of our test out option and collect all the badges badges that you want. Each badge you earn counts towards your tier progression in the PACT program and includes the functionality to display officially on your LinkedIn profile for public visibility with your customers and prospects. This reinforces your crucial role as their trusted adviser. Please refer to the PACT partner program guide to see how many certifications are required for each of the program tiers. Of course, the ultimate goal is to drive impact and business growth for everyone. As you identify opportunities, don't forget to register your deals only partner portal. It's quick, simple, and the best way to protect that deal, securing it to you and your partner business in the easiest way to garner the highest discounts available. Thank you for all the questions during the session today. If you need any further help, please don't hesitate to reach out to our channel account manager or partners@rapid7.com. I'd like to add a quick reminder to please register for the last session in the series. We have so much more information to share. The details can be found on the partner portal. Also, please be on the lookout for the regular Rapid7 partner business communications, which detail product and solution launches and improvements, important partner program updates, and information on all upcoming new and on demand webinar sessions available. And with that, thanks everyone for joining us today. Have a great day. Bye for now.