Skeptic or saboteur
Testers, or any curious cybersecurity person will have a tendency to go off track when placed in front of a new platform to evaluate. Without an anchor, expect them to push every button, turn every knob, scroll through every list, nitpick, and ultimately waste the entire eval picking holes in the product instead of figuring out if it solves their problem. This is called scope creep. It’s natural, it happens in pretty much every proof of concept I’ve ever run, and it has the ability to kill a deal if not addressed properly.
But scope creep isn’t always random. Sometimes it has an author.
Person vs. Structure
There has never been an enterprise deal I’ve been involved with where the hands-on-keyboard tester was the only influencer on whether or not a technical recommendation for purchase was made. Generally there are three personas: testers, recommenders, and buyers, and there can be multiple of each. In an eval with several testers, you can bet your bottom dollar that at least one of them is keen on keeping the status quo.
This is structural rather than personal. Your product threatens somebody’s existing routine, expertise, or personal preference, in every deal. There can be a million reasons. They could really like an incumbent product, maybe they’re an expert on it and worried about what happens to their job if something new gets implemented. Maybe they’re retiring soon and simmply don’t want to learn something new. They could have had a bad experience with your company in the past, at this organization or a previous one. In a bakeoff, they could quietly prefer a competitor.
None of those motives are unreasonable. Most of them are things I would feel too if I were in their shoes.
Skeptic or saboteur
The distinction that matters is between an honest skeptic and a saboteur, and it’s all about how they object.
An honest skeptic can be abrasive, and that’s fine, as long as it pertains to something in the test criteria or the problem they’re trying to solve by testing your product. They may pick up on something in scope that they don’t agree with, and that’s a discussion worth having. Good evaluations always have some pushback.
A saboteur goes out of scope, raising issues unrelated to the actual need behind the testing.
The biggest difference is what happens when the facts change. An honest skeptic can change their tune when presented with new information. If an argument finishes with something to the tune of “well, I just don’t like it,” you’re dealing with something else. Timing tells you too. Those objections almost always arrive in the demo or late in the eval, trying to stop the deal from starting or grinding it to a halt before it finishes.
What it sounds like
Armed with solid, measurable, approved success criteria, a good SE can make these conversations easier. Three testers on an eval check-in, along with the recommender, the buyer, and the sales team. the champion wants the product, one tester keeps raising objections, call him Nay-Sayer (This is an actual scenario I witnessed during an engagement)
SE: Thanks for joining. We’ve been making great progress, moving into phase 3 of the evaluation plan this week. Are there any items top-of-mind before we start the review?
Nay-Sayer: Um, yes. Your product doesn’t integrate with Splunk natively.
SE: Gotcha, yes, that’s true. How important is that to you?
Nay-Sayer: Pretty important. Most products in your space have prebuilt integrations.
SE: Agreed, several of them do. Let me check my notes here… interesting. I didn’t know you guys had Splunk. This is the first I’m hearing it mentioned.
Nay-Sayer: Well, we don’t have Splunk today.
SE: I see. Is it something you’re planning on implementing soon?
Nay-Sayer: We’ve been looking at it.
SE: Nice. Yeah, great product. Currently we don’t have native Splunk integration on our list of success criteria. Based on the use-cases we’ve discussed, I don’t really see a need for it. Please correct me if I’m wrong.
Nay-Sayer: No, but it’s still important and you guys don’t have it.
SE: Here’s the thing. Evaluations are complicated, with a ton of moving parts. From where I’m sitting, we have a solid testing plan with criteria designed to prove whether our product can meet your needs, that your team signed off on. I’m hearing you say Splunk integration is important and I don’t want to discount that. I know it’s on our roadmap, and depending on when you plan on testing it, we may be able to move it around. How about I add you to the enhancement request we already have in Jira and get you on a call with our product team to talk about it. Does that work?
Champion: Yes, that would be great, let’s do that.
Nay-Sayer: Sounds good.
Notice a couple of things. The SE agreed with Nay-Sayer that the product was missing that functionality and that it was important. The next, critical step is to break it down logically.
Agreeing first matters because the product genuinely doesn’t have the integration. Arguing that point costs the room’s trust in everything said afterward, and we’re not in the business of talking anybody out of facts. From there the questions are ordinary ones. How important is this to you. Do you have Splunk today. Are you planning to. By the third answer the objection has resolved itself into something smaller than it sounded, and nobody had to say so out loud.
Referring back to the signed criteria is how you anchor any conversation that starts to go off track. This is why it’s so important to get them agreed upon in writing before the evaluation starts. Without that document this is one person’s opinion against another’s. With it, there’s a reference point the whole team already approved.
The everyday version of this is the triage question: “Does this prevent you from continuing to test?” or “Does this issue prevent you from making a technical recommendation for purchase?” It disqualifies dead deals, and for everyone else it puts the problem back in proportion.
These are tools in the belt, not moves for every deal. It takes experience, curiosity, and awareness to use them properly. Every objection has a motive. It’s up to your team to figure out what it is.