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.

Don’t insult your audience at a technical conference by presenting a sales pitch

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.

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 #2: The POC must have a client-side business and technical sponsor

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.

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.

Five fundamental proof-of-concept guidelines

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:

  1. The POC must always occur in the context of a sale. Otherwise, it’s just a costly and time-consuming demo.
  2. The POC must have a client-side business and technical sponsor. Otherwise, nothing will come of your hard work.
  3. The POC must have a clearly defined set of goals. Otherwise, the client will keep moving the goalposts.
  4. The POC must have an agreed-upon timeline. Otherwise, the POC will stretch to infinity.
  5. 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.

Another instance of a successful ROI calculator

December 17, 2012 Comments Off on Another instance of a successful ROI calculator

A while back I wrote about an ROI calculator that we created for Sybase at Think88. That calculator was meant to assist customers in determining the economic benefits of putting Sybase’s new compression capabilities to work in their data centers.

At WiseClouds, we help many customers design, develop, and test highly intricate distributed systems. One of the most important tools that we use is soapUI Pro. In fact, we believe in that product so much that we created a training course to help customers learn how to derive the most value from it.

During our engagements we always encourage customers to make the switch from the free version of soapUI to the professional version. After seeing the benefits of this upgrade in dozens of environments, we’ve come up with a concrete set of numbers that highlight these efficiencies from three viewpoints:

  1. Labor savings
  2. Time-to-market
  3. Software defect reduction perspective

We then used this information as the foundation of an ROI calculator to help showcase these advantages and thus justify the upgrade to soapUI Pro.

Where Am I?

You are currently browsing the marketing category at rdschneider.

%d bloggers like this: