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!
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.
February 9, 2015 Comments Off on Don’t insult your audience at a technical conference by presenting a sales pitch
I’ve been going to technology conferences for a long time, and have seen – and delivered – tons of presentations over the years. I have particularly high expectations at events with the following characteristics: 1) I had to pay for my attendance, and 2) the breakout sessions are billed as technical in nature.
In the past few years, I’ve observed a disturbing trend of conference speakers providing what is essentially a jazzed-up sales presentation to a technical audience. Often times, a vendor (such as a technology provider or consultancy) will trot out a person with a technical title, and then saddle them with a sales pitch. I feel bad for the poor presenter, because they’re going to be in for a rough time.
The best-run conferences will actively discourage this, to the point of rejecting a presentation that’s too sales-y. But unfortunately, most organizers aren’t so diligent. In fact, the vast majority of presentations don’t get evaluated: conferences can find it difficult merely to round up a full roster of speakers, much less thoroughly review what they propose to talk about.
Here are some examples of detrimental speaker behavior:
- Spending 3/4 of the time talking about their brilliant CEO, prestigious investors, dedicated partners, and loyal customers
- Detailing their sales process
- Reading, verbatim, from industry reviews, customer case studies, and other marketing material
- Endless details about market growth and customer acquisition
- Describing their product or solution in glowing language: everything was, is, and will be perfect
This is a very imprudent approach, for lots of reasons. First, the audience at an event like this will be sophisticated, and often cynical. It’s unwise to try and fool them. The rise of social media means that the attendees won’t hesitate to publicly slam the company, speaker, market, and conference organizer if they feel that their time was wasted. These angry protestations often occur while the speaker is in front of the room – a great example of real-time negative feedback. And finally, no one likes to feel like they got fleeced, especially when you consider what it costs to attend a conference these days.
The good news here is that by staying truthful and focused on technical topics, you’ll end up with a better set of sales prospects than if you simply hammer them over the head with marketing messaging. Chances are, your technical solution – even if held together with duct tape – is still interesting to the audience.
Coming up soon, I’ll be writing a series of blog posts about what should be covered at a technology conference. For now, here are some brief guidelines:
- Keep the fluff to a minimum: no more than 20% of the allotted presentation time
- Be honest about the product or service that you delivered to the market
- Describe lessons learned – both good and bad
- Use lots of pictures to illustrate how it worked
- And above all: don’t read slides to the audience!
If you’d like to see more posts related to technical sales and sales engineering, click here.
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.
November 12, 2013 § 2 Comments
In the introductory post for this series, I present a list of POC suggestions that I’ve learned – too often the hard way. Next up, I describe why it’s so important to have client-side sponsorship.
I’ve already written about why a POC should only happen when there’s an active sales opportunity. Assuming that there’s indeed a live deal, there are still many ways for things to go off the rails. First, every substantial technology sale I’ve ever been involved in was impacted by client-side politics. After all, any significant new systems, processes, or technologies will affect large numbers of people. Some will be strengthened by the purchase, and others will be weakened. These machinations are often invisible to the sales team, but trust me: there are definite winners and losers, your client’s employees know this, and this impacts how every one of them will behave regarding your POC.
This means that there’s a very good chance that some individuals will be rooting for your POC to fail. Resistance may be passive, such as taking a leisurely three days to respond to your emails and calls, or giving you wrong or incomplete information. You might also encounter active opposition, even to the point of deliberate sabotage of your POC.
Given that every POC is a potential minefield, you need at least two trusted guides to help you get through safely. These sponsors should represent both the technical and business side of your prospect. It’s a huge red flag if your client won’t assign anyone, or if they assign people who don’t seem to have the respect of their colleagues.
Good advocates will help remove barriers to your success. They know the landscape far better than you do, and they can head off the active damage to your POC – often without you even knowing that they were acting as your guardian angel. In particular, a technical benefactor will quickly get you access to the resources you need – which is helpful, since time is of the essence on a POC. And a business champion will be intimately involved in drafting up the rules and goals of the POC.
As a sales engineer, you need to speak up – to your sales rep – if you determine that your sponsors are weak, disinterested, or not giving you the resources you need, because guess who will get blamed if the POC fails?
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.
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.
July 31, 2013 § 5 Comments
If you’re selling a sophisticated or costly technical solution, it’s highly likely that your prospect will demand a proof-of-concept (POC) before committing to a purchase. Failing to successfully complete this vital task means that you won’t make the sale. Yet over the course of many years, I’ve seen a surprising number of botched POCs. Sadly, most of these fiascos had less to do with product or service shortcomings, and more to do with the process and people who were involved in the POC.
To help you deliver better POCs, I’ll be writing a series of blog posts that showcase some best practices. For now, remember these five essential guidelines when you agree to perform a POC:
- The POC must always occur in the context of a sale. Otherwise, it’s just a costly and time-consuming demo.
- The POC must have a client-side business and technical sponsor. Otherwise, nothing will come of your hard work.
- The POC must have a clearly defined set of goals. Otherwise, the client will keep moving the goalposts.
- The POC must have an agreed-upon timeline. Otherwise, the POC will stretch to infinity.
- The POC must have internal support from the company that’s trying to make the sale. Otherwise, you won’t get the assistance you’re likely to need.