marketing | rdschneider

Bad Sales Engineer Behavior #7: Unreliability

February 28, 2019 Comments Off on Bad Sales Engineer Behavior #7: Unreliability

At last, we’ve arrived at the final entry on the list of seven Sales Engineer (SE) behaviors that will cripple your career: unreliability. By definition, lots of things can go wrong in sales opportunities. As an SE, one of your key responsibilities is to do your part to bring a degree of predictability to what is frequently a chaotic process. The best way you can go about this is to simply show up and do your job to the best of your abilities. But in the years that I’ve been doing this, I’ve seen quite a few undesirable traits that I’ll lump into the ‘unreliability’ category. Here are just a few examples:

Arriving late – or not at all – for sales calls & meetings. Want to raise your sales rep’s blood pressure? Here’s an easy way – just show up later than anticipated for a sales call. Even better: don’t even bother coming, and certainly don’t call or email to alert them and explain why.
Being unprepared for demos. When carrying out a technical demonstration, ‘winging it’ is a sure recipe for failure. After all, there are so many moving parts and potential points of failure, such as buggy technology, version mismatches, ignoring customer requirements, and so on.
Not following through with technical responses. It’s a rare technical meeting that doesn’t end up with some research for the SE to go carry out. But in many cases, the SE gets caught up in other activities and never gets around to answering the questions. This is understandable, given that SEs confront lots of other responsibilities. Additionally, “out of sight, out of mind” can be a factor here. Don’t forget, however, that the customer doesn’t share your workload, and may be eagerly awaiting your answers.

If any of these deficiencies hit too close to home, it’s easy to correct them: just focus on improving your follow-through, and people will soon forget your old, unreliable ways. You’ll also probably find work more enjoyable too, since you’ve eliminated a major stressor.

Five great starting points to transition into a Sales Engineering career

November 30, 2018 Comments Off on Five great starting points to transition into a Sales Engineering career

For years, I’ve been describing the numerous advantages – and minimal drawbacks – of a career as a sales engineer:

I’ve written about traits that one should possess to increase the likelihood of success
I’ve discussed follow-on career paths
I’ve even told you about bad behaviors that will curtail (or abruptly end) your sales engineering career

What I haven’t yet talked about are some of the jobs that lend themselves to transitioning into a sales engineering role, so that’s what this series is going to be all about. Here, in no particular order, are five of the most logical starting points to becoming a sales engineer:

Technical support. You’re charged with answering customer questions and/or resolving product issues
Marketing. You design, own, and/or promote the product or service
Customer success. You ensure that clients have a positive experience when deploying the product or service
Product implementation. You’re responsible for moving the product or service from concept into production for the customer
Development. You build and/or maintain the product or service

I’ll be writing about each of these roles in more detail. If you’re interested in being notified of future editions, subscribe to the blog or follow me on Twitter: @RD_Schneider. You can read other sales engineering-related posts here.

Sales engineer career path #2: Marketing

March 31, 2018 Comments Off on Sales engineer career path #2: Marketing

While many Sales Engineers (SEs) gladly elect to spend their entire careers in this interesting, challenging, and potentially lucrative job, others choose to explore different roles. I’m writing a whole series about prospective post-SE career paths, and it’s now time to examine what a move to marketing might look like.

Marketing in a technology company offers numerous potential responsibilities, and a sales engineering background provides a great foundation to be an effective marketer. Of course, there are always positives and negatives to any career change, so here are a few of the most notable examples:

Advantages

Executive potential. It can be difficult to directly advance from sales engineering into an executive (VP or higher) position. In contrast, in marketing there’s a clear career path from an individual contributor to an executive.
Defining product strategy. Marketers often have more input into the company’s strategic vision and positioning than individual sales engineers.
Travel. Marketers generally spend less time on the road than sales teams, and when they are asked to travel, it’s often to trade shows held in places where people want to go.

Drawbacks

Compensation. While this isn’t a hard-and-fast rule everywhere, SEs tend to have higher overall incomes than their marketing counterparts. Why? Although the marketing base salary may be higher, SEs have the potential upside of commission.
Competitive knowledge. Sales teams in the field will look to their marketing counterparts to have an up-to-date and accurate understanding of what competitors may be doing. This requires never-ending research since the market landscape is always shifting.
Customer interaction. Well-run technology companies encourage their marketers to work with customers. However, a sales engineer will always have more detailed exchanges with clients – it’s the nature of the job.

If you’re interested in being notified of future editions, subscribe to the blog or follow me on Twitter: @RD_Schneider. You can read other sales engineering-related posts here.

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.

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.

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Where Am I?