Overcoming a Technical Sales Ambush Best Practice #3: Request a Prospect Business Executive to Observe
December 31, 2017 § 1 Comment
The next installment of this ongoing series about thwarting technical sales ambushes highlights the value of having a line-of-business executive from the prospect participate.
Recall that a technical sales ambush is an ad-hoc, often last-minute meeting meant to derail a highly complex technology sale. Of course, I’m not referring to legitimate questions that may arise at any point in the cycle, but am instead warning about bad-faith efforts to stop a sale that is progressing towards a successful conclusion. I’ve seen my share of technical sales ambushes, and very often they’re initiated by relatively low-level staff that are threatened by the progress that you represent.
In the absence of more senior staff – particularly business executives, the technical staffers will go back to their management and report that the vendor (that’s you!) can’t or won’t meet one or more important requirements. Unsurprisingly, this bulletin delays – or torpedoes – the sales cycle.
A good way to head off these unfortunate situations is to request – and even insist – on a representative from the business side of the prospect’s organization. They’re much more capable of seeing the big picture, and often are the ones who will benefit from the product or service that you’re selling. To keep things simpler – and give you the appearance of innocence – your sales partner should make this request. The executive is much more likely to keep things moving, and avoid the dreaded technical “fishing expedition” that can demolish even the most well-planned sales opportunity. As an added perk, the low-level technical staffer is likely to be on much better behavior, since they’ll wonder (and rightly so) if their business colleague will see through their plan!
Overcoming a Technical Sales Ambush Best Practice #2: Request a List of Questions in Advance
August 3, 2016 Comments Off on Overcoming a Technical Sales Ambush Best Practice #2: Request a List of Questions in Advance
Continuing this series on technical sales and sales engineering, a technical sales ambush is a situation where prospect calls a technically-oriented meeting with the hidden (and bad-faith) purpose of introducing impossible or unreasonable requirements that end up monkey wrenching the entire sale. Naturally, legitimate technical questions are part of every sales cycle, but an ambush is deliberately meant to derail the sale while making it look like it’s the vendor’s fault. Any new product or service can be disruptive and threatening, so you should be on the lookout for it.
While ambushes can’t be totally avoided, they can be managed through proper preparation. For example, you should avoid open-ended “discovery” meetings at all costs. Instead, all interactions should be structured: by simply requesting a list of questions – well in advance of the meeting – you have an excellent chance of thwarting surprises. In fact, scheduling the meeting should be gated on receiving the list of questions, and you should also keep the decision makers in the loop.
Once you have the list, prepare to put your answers in writing, and distribute them to all prospect constituencies (including line-of-business leaders) in advance of the meeting. During the session, you can discuss the answers, provide demonstrations, and so on. This is much more effective than an open-ended “fishing expedition”. And if unplanned questions arise, you can either address them on the spot (and append the written list), or use the time-tested “I’ll get back to you on this” response, and simply come back with your answers once you’ve done your research.
Either way, this strategy gives you much more control over the interaction with the prospect, and can help you win the opportunity.
What do all effective custom demos have in common?
June 29, 2016 Comments Off on What do all effective custom demos have in common?
Selling a high value, technically sophisticated product or service usually means showing it to the prospect before they’ll buy. This makes the demonstration an absolutely essential task, yet many businesses – both large and small – take a very haphazard approach. Naturally, these oversights often lead to unwanted outcomes and lost revenue.
I’ve been involved – as a spectator and participant – in an uncountable number of these events. Based on my years of experience, here’s a subjective list of what the most successful demos achieve:
- They’re concise
- They’re bulletproof
- They’re repeatable
- They’re adjustable
- And most importantly, they’re part of a well-designed sales cycle
I’ll be writing about each of the recommendations in future posts, but for now it’s worth pointing out that I’m not talking about something that’s shown to just anyone (such as you might find in a recording or on a website). Instead, these suggestions refer to custom demos that are directly linked to a sales effort.
If you’d like to discuss how fine-tuned demos can help you win deals, feel free to email me.
Overcoming a Technical Sales Ambush Best Practice #1: Include the Sales Representative
September 30, 2015 Comments Off on Overcoming a Technical Sales Ambush Best Practice #1: Include the Sales Representative
As I recently depicted, a technical sales ambush is a scenario where a prospect convenes a technically focused “review” meeting with the hidden purpose of introducing impossible or unreasonable requirements that end up monkey wrenching the entire sale.
While ambushes can’t be totally avoided, their outcomes can be ameliorated through proper preparation. For example, sales representatives – at least those that are making or exceeding quota – are masters of interpersonal relationships and reading between the lines. I’ve found that the best reps can instantly sniff out an ambush or other situation where the prospect’s technical experts are not acting in their employer’s best interest, and are advancing their own private agendas instead.
A proactive sales representative will quickly take steps to stop an ambush in its tracks. This can include entirely rejecting the meeting without adequate representation from the business, or demanding a quid-pro-quo about what happens after the meeting (like setting up a proof-of-concept).
One of the most important things a rep can do is simply make sure that they’re part of the meeting: a sales engineer (SE) should never face this type of audience alone, especially when it appears that an ambush might be in the cards. Having the sales rep present frees up the SE to focus on making a good faith effort to address all technical questions, while strengthening the case that the vendor is making to the prospect.
Five Ways to Overcome a Technical Sales Ambush
August 20, 2015 Comments Off on Five Ways to Overcome a Technical Sales Ambush
As I’ve described in other posts, there are many advantages to being a sales engineer. One of the most attractive benefits is generally being free of the politics, mind games, and brinksmanship that take place during a high-value, strategic technology sale. These are usually the domain of the sales representative, which is why they get such big commission checks – or get fired.
Unfortunately, there are circumstances where sales engineers can be dragged in to some distasteful encounters with a prospect, which usually revolve around a live session to go over deep technical aspects of the proposed product or service. I label these interactions as “ambushes”, because an unsuspecting SE often has no idea what they’re getting into until it’s too late.
I’ve been on both sides of the table in a technical sales ambush, so in this series of blog posts I’ll provide some guidance about how to avoid them, and what to do if you get caught up in one.
First, what are some of the signs that you’re about to walk into an ambush?
- You are selling a product or service that will replace an in-house solution created or maintained by people still on the prospect’s payroll, or there’s an alternate offering from another vendor that has passionate backing from some members of your prospect’s technology team.
- You’re in the mid to late stages of a sales cycle, when it appears that your solution actually has a chance of being chosen.
- The prospect has requested a live, onsite meeting at their offices. They may call it a “review session”, or a “technical deep dive”.
- The prospect has invited a large and diverse group of technically focused people to the meeting, often including someone with a title like “chief architect” or “lead engineer”.
- The prospect can’t (or won’t) provide you with a list of topics for discussion in advance. Instead, the session is billed as a “friendly, open-ended exploration to get more technical details” about your product or service. Trust me: there’s nothing “friendly” or “open-ended” about an ambush.
At first glance, none of these attributes necessarily indicate that the meeting will be an ambush. However, when you step back and look at the big picture – especially from a cynical perspective – you begin to realize that the true purpose of the encounter is to introduce fear, uncertainty, or doubt into the equation, and thereby torpedo the deal if at all possible.
I’ll write about guidelines to cope with an ambush in some upcoming posts, but for now here’s a high level list:
- Make sure the sales representative is in attendance.
- Request a list of questions in advance.
- Encourage one or more of the prospect’s business executives to observe.
- Consider bringing someone from your own engineering team.
- Don’t take the ambush personally.
Bad Sales Engineer Behavior #2: Skepticism
June 19, 2015 Comments Off on Bad Sales Engineer Behavior #2: Skepticism
As I continue my tour of seven of the worst sales engineering (SE) traits, let’s take a look at skepticism. Selling complex, high-value products and services is hard enough even when everyone on the team is upbeat and optimistic. Long hours, grueling travel, and the interpersonal challenges of coping with mercurial prospects all result in generous amounts of stress and significant sales professional turnover.
An already-difficult job is made much tougher when the sales team is burdened by friction between the sales representative and the SE. In particular, skepticism is one of the most toxic attitudes an SE can display, and it’s often one of the biggest sources of tension in the relationship.
I define skepticism as continual – and even adversarial – questioning of sales representatives by their SE colleagues, especially in the early stages of a sales cycle. SE skepticism can emerge even earlier, such as when marketing leads arrive, or on initial telesales qualification calls.
I once had an SE on my team who needed to be sold – every time – on why he should deign to deliver a demo. Unsurprisingly, this created extensive and unnecessary hostility between him and his sales partner. This SE lost sight of the basic reality that his customer was the sales representative, not the prospective client.
Don’t get me wrong: rational, unemotional evaluation of potential opportunities is essential when allocating scarce sales resources. But unless something looks really off, the SE’s job is to give 100% and be an encouraging participant as the deal moves through the funnel. If something appears troubling about the prospect or opportunity, it’s most productive for the SE to position it as a challenge that can be solved by positive, constructive teamwork.
You can learn more about sales engineering here.
Proof of concept best practice #3: The POC must have a clearly defined set of goals
February 3, 2014 § 3 Comments
In earlier posts in this series, I’ve talked about why proofs-of- concept (POC) are so essential when attempting to get customers to buy a complex product or service, how they must already occur as part of an active sale, and that they must have a sponsor at the prospect – on both the business and technical sides.
Now, it’s time to discuss how to increase the chances of your POCs succeeding by setting well-understood, widely communicated goals up front. After all, the sale isn’t going to happen without a POC, and the POC itself is much more likely to ignominiously fail if you neglect to gain agreement on exactly what concepts you’re supposed to be proving!
Don’t lose sight of the fact that the burden of proof for a POC falls squarely on the company trying to make the sale, and that the sales engineer (SE) is usually personally responsible for ensuring a positive outcome. Despite this reality, I’ve seen astonishing numbers of POCs that proceed without a single written sentence that describes what’s supposed to happen. Given that lack of guidance and accountability, is it any wonder that so many of those impromptu engagements end in tears? It’s much wiser to write a proper, comprehensive statement of work (SOW) for the POC – just like you would for a professional services engagement.
At a minimum, the SOW should unmistakably document the POC’s:
- Goals. Be specific, and cite easily understood concepts like use cases, data or transaction volumes, and availability/service level agreements. Checklists are great for this.
- Schedule. Time is of the essence in a POC: unlike consultants who eagerly seek ways to boost billable hours, the most talented SEs must be efficiency experts.
- Responsibilities. A POC is usually a team effort; make sure that everyone’s role is plainly spelled out.
- Next steps. Since you’re not doing this POC just for fun, there’s no harm in stating that a purchase of your product or service will take place upon successful completion of the POC. And if the client won’t sign off on a SOW that references the expected sale, guess what that means?
I’ve worked with quite a few technology companies to help optimize their technical sales processes. If you’d like to learn more, you can email me here.
Proof of concept best practice #1: No POC without a valid sales opportunity
October 18, 2013 § 3 Comments
Recently, I shared some of my observations about guidelines for successfully carrying out proofs-of-concept (POC). In this installment, I want to point out how important it is for the POC to occur – always, without exception – in the context of an active sale.
I’ve lost track of the number of times I heard about a huge deal that was about to come in, if only we diverted all sales engineering talent to work for 72 hours straight (usually through a weekend, with bonus points for a holiday) to crank out a last-minute POC. In nearly every case, I discovered that my company was being used as “POC fodder” (i.e. leverage against another vendor that was much further along in the sales cycle), or there was something else strange about the opportunity.
Unfortunately, sometimes even the most levelheaded salespeople get excited and fantasize that there’s a deal when the customer is just kicking tires, comparison-shopping, or finding an excuse to continually evaluate technology without making a decision. I won’t name names, but I personally witnessed one firm – a major credit bureau – spend 8+ years evaluating Web service infrastructure offerings without ever buying anything. They went to conferences all around the world and ran their vendors ragged on custom demos, POCs, and other free work without ever spending a dime on software.
To prevent these time-wasting wild goose chases, remember that no POC should ever be done without an active sales opportunity underway. Look for an RFP or other documentation that describes a well-planned purchasing process. If the prospect starts getting cagey, changing the subject, or otherwise trying to avoid the question, there’s no deal there.
In fact, you actually strengthen your position by – politely – walking away from abnormal POCs. Prospects are notorious for trying to squeeze free research out of vendors, particularly hungry startups that are desperately trying to win a deal at a large customer.
If you’re interested in POCs and all things related to sales engineering, check out my posts on the habits of the most effective sales engineers.
rdschneider 