Pick Up The Phone!

“So then I sent the rep an email…”
“I’m waiting for support to respond to my status update request”

Whenever I hear a phrase similar to these in one of my consulting engagements, I know I’m close to finding a problem, or at least uncovering a major symptomatic issue. Let me explain ..

After four months of travel running enablement and training workshops, May has been kinder and gentler and I have been working on a couple of “take-home” consulting opportunities. Both involve some badly broken internal sales processes at a couple of mid-sized companies. These processes were impacting both the effectiveness of presales engineers and ultimately the win-rate of sales. You know when a process is so badly broken that the injured parties readily admit that they spent more time trying to fix the blame as opposed to fix the process, which is why a third-party comes in to obtain resolution.

In both cases, email was to blame, and the people who relied upon it as their primary communications mechanism. Instance #1 involves a company with incredibly poor Sales Discovery habits and instance #2 a company where Sales Engineering spends 35% of their time bailing out Customer Support. Repeatedly, an email was

1. Left unanswered
2. Sent solely as a CYA (Cover Your A$$)
3. Incomplete and poorly written
4. Partially answered

My response in both the situations was to say “pick up the phone!”. An email is linear (in the good old days we’d call it half-duplex) as only one party can communicate at a time. An email can’t contain (much) emotion – I don’t feel there is much room for smiley-faces in business communications unless you really know the other person. A phone call allows you to get all your questions answered (you’re in sales – you know how to ask questions and get them answered!). Plus a phone call leaves no audit record other than that the call was actually made. You can say things in a call you cannot in an email.

So if you are frustrated in some internal process (or even in a customer communication) see if email is in the communication chain. If it is – ask yourself what would happen if you picked up the phone rather than send another email?

Maybe things would magically get better.

In my two engagements, the discovery rate doubled and presentation standards have improved dramatically in just three weeks for one customer, and the other customer reports that post-sales time has decreased from 35% to a still-high 22% and is trending downwards.

Pick Up The $^#@ Phone!

Age And The Sales Engineer

General statistics about the SE population have always fascinated me - particularly when they relate to age, gender, income and all those other "Human Resource" type metrics.

I've long maintained that gender diversity in the worldwide SE gene pool is atrocious and that we all need to do whatever we can to encourage more women into the profession. But that's a topic for another blog entry. This one is about age.

Age is neither a positive or a negative when it relates to being a superstar SE. With age comes experience and (hopefully) wisdom and a lot of knowledge gained from watching your own and other people's mistakes - and successes. With age also comes a lot of bad habits, some reluctance to change and a touch of cynicism. With youth comes the willingness to challenge the way things are now, potential incorporation of new thoughts and technologies into "the way we get things done around here" and unbridled enthusiasm.

The optimum SE team (whether its 6 or 6,000 members) has a mixture of youth and experience - and I know I am equating age and experience and that's not always the case. It's also the case that the average age of the SE team frequently matches the average age of the entire company (to within a year) - so it's interesting to note this data from Payscale showing age related to technology company.

I'll leave it as an exercise for the reader to draw your own conclusions about the data.

 

The 3 Big Lies About RFPs

Answering RFPs is one of the relatively ugly costs of doing business. There are many myths circulating about RFPs, and in particular the best way to win them. Many of them are wrong. Completely wrong and out of date! Since the burden of responding to RFPs usually falls to the SE Community (who call them Really Fast Paperwork), it’s time to look at some of these myths in more detail, and debunk them once and for all. The Big Three RFP lies are:

a) 9/10 RFPs are biased towards one vendor;

b) If you don’t write it you won’t win it

c) You have to answer (and win) every request.

Believing these three alleged facts will cost you money, an ever-expanding amount of time and resources, and decrease the morale of any SE team whose job it is to respond to an RFP. You may not agree with my point of view, but it will make you take a fresh look at how you answer.

1. 9/10 RFPs are biased. Usually the losing sides make a statement like “it was clearly rigged for our competitor”. Here is my analogy: I train a youth football (soccer) team. We are one of the best teams, we play in a very competitive league and we win most of the matches we play. Sometimes we do lose. When we lose, the parents blame the referee for making a bad decision or favouring the other team. Yet sometimes we make mistakes and play badly (the children are 11 – it happens!), sometimes we lose to an inferior team that just does everything right and beats us, and sometimes we are simply beaten by a better team. In the eyes of the parents – it is always someone else’s fault – never their own children.

That is exactly the same view that sales and presales teams take when they lose an RFP. Over the past year I have spoken with more than fifty IT and business executives about the RFP process. Their responses match my own experience as a former CIO – “John, we never ever bias an RFP. We can’t afford the consequences if we are caught. There are so many other more subtle ways of influencing a decision if that’s what we wanted to do.”

A slightly more accurate version of the myth is that “9/10 customers are already biased towards a particular solution”. RFPs are rarely biased, people are. I do not believe the number is as high as 90%, I think it is more like 50% based on my data so far. Where that impacts the RFP is actually in the scoring process. Read on:

“This is what we do if we absolutely have  to change a score. Every factor has to be scored on a scale of 1 (low) to 5 (high) and then weighted. Making the determination of a 1,a 2 or a 5 is fairly clean cut. The difference between a strong 3 and a weak 4 is unclear and a matter of opinion. Upgrading a few 3’s to 4’s for your favorite can make all the difference in the selection process for getting to a short list. No one will ever know!”

2. If You Don’t Write It, You Won’t Win It. Seriously? How many RFPs have you written for your customers in the past year? It just doesn’t happen anymore.  You can certainly nudge and push an RFP by suggesting during discovery meetings that some feature/function should be made a requirement, and although I still suggest that every SE team has a standard list of questions to supply to a friendly coach in a pre-RFP stage those questions are rarely used.

   Think about the creation of an RFP and the history of the RFP process. The basic internal purpose of an RFP is to gather some momentum and collaboration inside the customer to get a project started. It is as much political and psychological intent as it is purchasing intent. It is often the first chance that business analysts have to document requirements they have gathered from the business and the technical users. Once the document is created it is then a common set of requirements that everyone can judge vendors by – to apply a sense of fairness. It is the way to get legal, finance, purchasing and everyone else on the same page.

Now go back 20-30 years. When an IT department wanted to purchase some technology to solve some user’s business problem and needed to issue an RFP – what happened? It was a long drawn-out process. Analysts were tasked with investigating the market and determining who even had something close to the requirements. They had to rely on vendor literature, analyst reports from Gartner, Aberdeen, Giga and the like, plus personal experience. When the RFP was issued, the customer did not know that much about the technology and the solutions. Contrast that with today’s version. The customer is far more educated, thanks to Google and vendor’s websites. They scour user group boards, Facebook and Twitter to research the popularity of a solution before the (electronic) RFP even hits your salesperson’s inbox.

The only way you can “write” an RFP in 2015 is to virtually write it through the internet, social media and good-old fashioned personal contact. You are still persuading, influencing, placing and educating (think PIPE!) the customer – but in a far more indirect and subtle way. When you discover text in an RFP apparently ripped directly from your competitor’s website – it’s usually because of a lazy analyst, not brilliant competition.

Personal example – I actively encourage people to write positive reviews of my book. I do this to make sure that when someone searches “sales engineering books” MTS comes up #1 in the list because of great Amazon rankings – and also to counter the negative review a competitor placed online.

3. You Have To Answer Every RFP. Says who? Usually Sales! I routinely ask presales leaders what percentage of RFPs they know they will never win – but answer anyway. The answer is a staggering 25-33%, which is an amazing waste of resource. In Winning The RFP Game I lay out a number of steps a SE team can take to increase both their win rate and their internal efficiency.

In business, one of the fastest ways to go out of business is to say “yes” to everyone. As an individual, you learn to control your time and prioritize your efforts towards those activities that have the greatest payback (subject to managerial preference). When you personally say “yes” to everyone you rapidly run out of time, perform poorly and are heavily stressed. A sales and presales team – working together – cannot afford to say “yes” to every RFP.

Now let’s talk about winning. This is a strange statement to make in a sales situation – but you don’t always have to win the RFP. It depends on the type of RFP. When the RFP is issued to determine who will source a project – go for a win. Yet more than 50% of RFPs are issued as a gating process – which means they are used to reduce a large field of vendors (often 8-12) down to a short list of 2 or 3 who will go to the next stage of demo/present/propose. If all you need to do is to clear the gate that’s a different process. Know the difference.

 

In Summary

Just because you lose an RFP doesn’t mean it was biased. Sometimes you just lose – far more often than you think. That is because the 1990’s viewpoint of “you gotta write the RFP to win it” no longer exists except in the minds of salespeople and sales trainers. It is now a far more subtle form of influence. So when you do receive an RFP, make sure it is really worth answering and perform due diligence and discovery on the document before you open up the laptop to respond. Fewer, yet more targeted RFP responses will lead to more revenue, not less.

The Technical Win : A Worthless Metric?

I have always disliked the concept that Sales Engineers are responsible for winning the technical sale

and gaining the Technical Win. During my pre-MTS career as a presales leader anyone in my organization who spent a lot of time talking about The Technical Win (TW) was generally met with a withering glare and a statement like “Where in your compensation plan does it say that you get paid on the Technical Win?”. It’s an intermediate point in the sales process – at best.

Has the Technical Win become redundant in the modern world of Solution Selling? Ask any group of Sales Engineers to define their job, and the phrase “we’re responsible for winning the technical sale” is mentioned. Many SE organizations measure and publish their Technical Win Rate for RFPs, Proof of Concepts and Trial/Evaluations. This month I will examine the Technical Win (TW) and determine if it is real, if you should care, and what the metric tells you.

 A VP of Sales Engineering at a large software company told me his POC Technical Win rate was 82%, yet the Business Win rate (generating revenue) was only 59%. I asked if his team was directly compensated for a Technical Win. They are not. My point exactly. But you can learn something from the statistics.

The Technical Win

The strict definition of a TW is when you are informed, in writing, that your solution has been accepted and judged superior to that of your competition. For example, you may have scored a 13/14 on a POC evaluation compared to an 11/14 by your competitor.

Most SE organizations have a far looser definition, which may only require you to complete a POC or trial by meeting the success criteria. Acceptance may also come in verbal fashion. Recording of the TW may be as simple as checking a box on a screen in salesforce with no proof. An exasperated Regional VP of Sales based in Hong Kong once told me that in his opinion the TW was the equivalent of not losing – which is very different from winning.

 By contrast, the Business Win is definitive and measurable – as it will result in the generation in revenue flowing from the customer to your company, and eventually, one hopes, into your personal bank account. You are paid to generate business that will cause a purchase order to be issued.

Should You Care About The Technical Win?

Another way of looking at the TW is that it says to everyone that the SE organization did its job and the sales force did not. This is hardly the best way to promote teaming between sales and pre-sales. I have always believed that pre-sales is also responsible for the Business Win, just as sales has some responsibility for the Technical Win.

Given the incredible focus that most organizations currently have on Selling Solutions instead of Selling Products it is hard to rationalize the justification of a Technical Win in that environment. Selling value means that you continually need to link your achievements in a proof, trial or evaluation to not only the technical criteria, but also to the business and financial criteria. Put simply, how does your solution increase revenue; decrease costs or mitigate business risk better than the other guy’s stuff? Technology and Business are inextricably linked.

It is an unpleasant fact (small startups aside) that the TW rate will always be higher than the BW rate. Companies can decide to do nothing, lose or move funding, make an acquisition, change market strategy, fire your internal champion or base their decision upon boardroom or golf course politics. The BW rate can underperform the TW rate by 20 or 30 percentage points.

The most important aspect of the TW versus the BW is why the difference occurs for each specific deal. Should an SE team successfully complete an onsite evaluation, but then generate no revenue because there was no executive sponsor, no budget or no agreement to consider a purchase – then that is a sales execution problem. However, that leaves the SE organization open to charges of execution errors every time they engage in a perfectly teed-up evaluation and lose. It is a two edged sword.

 How To Use The Technical Win Rate

1.      Measure a TW against a tight definition – with proof required from the participating SE team. Which means define your rules for a TW and then stick to them. No cheating or grey areas.

2.      Make TW an internal SE metric, which is never provided to sales unless accompanied by a fully prepared pre-sales executive. Given a statistically valid quantity, breakdown the numbers by geography, vertical, solution area and competitor and monitor the trends for a rolling period equivalent to your average sales cycle.

3.      When presented to sales, position the TW-BW difference as an opportunity to (a) close more deals; (b) highlight competitive or regional trends and (c) operate more efficiently.

4.      Investigate the reverse win. That’s when the SE team loses the TW but your company gains the BW. There are often patterns, especially around executive access or partner utilization, that can yield positive results the next time around.

Summary

When the SE organization is focused upon, and satisfied with, the Technical Win you are doing your company and your bank balance a disservice. It is a useful intermediate metric, and can promote a good discussion at the executive level, but should be selectively applied at a field level. If you are truly focused upon selling value, then look at a Solution Win – which is when both the business and the users accept your solution as being uniquely qualified to solve their problems.

 

Because no one is paid for a Technical Win.

Sales Engineering in Japan

Last month I spent a few days in Fukuoka, Japan and then in Tokyo. During that time I was interviewed by Keiichi Takagi on behalf of ITPro - the biggest online tech magazine in Japan.

They were interested in learning not only about Mastering Technical Sales, but why there was such a market for specialized professional skills training for presales engineers. This kind of training is extremely uncommon in Japan, which is why it generated so much interest.

For my Japanese readers - the native text of the article is here http://itpro.nikkeibp.co.jp/atcl/interview/14/262522/092600039/?ST=selfup&P=1

For everyone else - here is the interview in English/American.

Q: What is the Mastering Technical Sales? How is it difference from others?

Mastering Technical Sales is unique because the role of the Sales Engineer is unique. If you think about the complex technology sale, there is usually an account manager who has the relationship with the customer and discovers a sales opportunity. The salesperson then has to bring someone technical with them to present, demonstrate and generally explain how the product or service actually works and how it will fit into the customer’s environment. That person is known as a Sales Engineer.

There are thousands of companies and thousands of books which claim to train and to optimize the salesforce. They all focus on the quota-carrying salespeople. We focus exclusively on the Sales Engineers who make up between 20 and 35% of a typical high-technology sales organization. It is an growing market and the SEs we work with are always very appreciative of the services we provide.

 

Q: What is the reason you wrote MTS in 2002?

A: It really started back in 1999. As a Sales Engineering leader I was frustrated because there was no specific professional skills training for my SE (Sales Engineer) team – all we had was sales training. I was sitting in a large windowless room in Atlanta, Georgia with my team of 40 SE’s and about 100 salespeople. We had a week of sales process training. It was boring as only about 25% of the content was useful to my staff and I felt we could learn it three faster than the salespeople!

 

I sat in my chair and said “why are we doing this? Someone should write a book about being a Sales Engineer!”. One of my young engineers looked back at me and replied “if you are so smart, who don’t you write one?”  That gave me the idea and I started to write the book the next day.

Q: Then, what is the reason for having revised the book in 2009 and again in 2014? What is the difference between a decade ago and now?

A: Much has changed about the basic SE job, the technology we use and the technology we sell.

First - fifteen years ago, is you know all the technical details of your product and could explain or demo them to technical people – that made you a great SE! Now that is a basic requirement of the role. SE’s are expected to have far more business expertise and to be able to link their technology back to the business benefits. There is now as much attention paid to the “sales” as to the “engineer”.

Second – with the introduction of virtualization, the usage of webcasts and cloud-based solutions I feel the technical side of the job has become a little easier. Virtualization allows an SE organization to create and to package up demo systems which can be easily reused and distributed. Webcasts allow a sales team to be far more responsive to their customers and to handle a multi-national customer base. Many companies now have large teams of “inside SE’s” whose primary role is to discover, qualify and demo over the phone/web. And then the cloud has allowed companies like salesforce to sell SaaS based solutions. Now almost every company has some form of cloud-based system which supports public, private or hybrid cloud hosting.

Finally that cloud base makes things like Proofs Of Concepts and general installations much easier to control for the SE. You can set up a demo system for a customer in a couple of hours, compared to the days or weeks it used to take when you had to go visit the customer on premise with a bunch of CDs, tapes and manuals!

Q: I'm going to ask you to look at the future. Will the role of SE change?

A: The role of the SE is already changing very quickly within the mid to large sized vendor. Smaller single product companies still focus on their technology and the technical advantages that brings to first movers who adopt their “solution”. The larger companies are asking their SE’s to become far more business oriented because that is what their clients want. A few years ago we helped run a survey of almost 1,900 senior level IT executives across the globe. They were asked “what are the skills you value most in a vendors presales team?” The #1 answer was “someone who understand my business”, followed by “#2 - someone I can trust”, ‘#3 - someone who can design innovative solutions with my staff” and “#4 - someone who can clearly and effectively communicate with me”. The #5 answer was “someone with deep technical skills”.

The demand now is for SE’s who can put together the technical skills with the business oriented skills and be able to speak technically to the IT audience and in value terms of revenue, cost and risk to the business and IT leaders. That is a hard profile to develop and even harder to hire in the general market.

 

Q: How about your business? How will you develop MTS for the future?

 

A: Business right now is wonderful. Professional skill development for Sales Engineers is a very underserved market – not just here in Japan, but everywhere in the world. My personal mission is to improve the profession of the presales engineer and to actually start a professional organization for all 250,000 of us in the trade.

We will continue to supply the basic skills every SE needs – through Discovery, Effective Demonstrations and Presentations, Webcasts, White Boarding, Handling Questions, The Executive Connection. I don’t think that will ever change.

We have spent a lot of time over the past 18 months working on some advanced material around “The Trusted Advisor Sales Engineer” – in fact that is the title of my next book. Since customers feel that SE’s contribute more value in the sales process than the Account Manager, we are focusing on the skills a SE needs to become that Trusted Advisor, to the point where we can now measure a “trust score” between an SE and her client.

We are also expanding the reach of MTS. We started in the US, expanded into Europe, and now thanks to our partnership with Up2Speed in Singapore we have a large Asian presence. We can now deliver most of our material in Mandarin, Korean and Japanese (plus Australian!). As an example, last month we ran a couple of white boarding classes here in Tokyo for a client. I saw a video of the session. I cannot speak Japanese, but it was apparent that everyone was enjoying themselves in the class and were learning new skills.

 

Q: How you see Japanese IT companies? Please give us your advice, how SE can contribute in order that a Japanese company survive in global competition.

A: I’m still learning about the Japanese market and culture. This is only my second trip to your country so I still have a lot to learn. I think you can probably teach me more than I can teach you!

That philosophy applies to Japanese SE teams as well – there is a lot they can learn from other parts of the global SE organization, and there is a lot the global SE teams can learn from Japan. As they say in the USA – you need to “share your toys”. Over the years I have seen some great ideas and tools developed within Japan – like custom demonstrations, great competitive ideas and partner enablement. I’m also learning as I conduct more research about the Trusted Advisor” that it is a well-developed concept here in Japan, perhaps more than in any other part of the world.

I think everyone needs to be more willing to share, and that is one of the advantages of being an SE – in that we tend to share far more than salespeople or development teams ever will.

Q: John, any final thoughts for us?

A:  Yes. I have two for you. First I just have to say how excited we are about the Japanese market and the opportunity to work with the entire Japanese SE community. Turing the role of the SE from a job to a profession is important to me. Secondly, (and this isn’t a very Japanese thing to do), is to encourage every SE out there to understand that they are a very valuable part of the sales process and that they “own the account” as much as the salesperson does. Don’t just sit by the phone or wait for your inbox to light up with a task and be reactive to what the salesperson wants – make your own contacts and network within the customer!

Good luck and good selling!

Pick Up The Phone!!

“So then I sent the rep an email…”

“I’m waiting for support to respond to my status update request”

Whenever I hear a phrase similar to these in one of my consulting engagements, I know I’m close to finding a problem, or at least uncovering a major symptomatic issue. Let me explain ..

After four months of travel in 2012 running enablement and training workshops, May has been kinder and gentler and I have been working on a couple of “take-home” consulting opportunities. Both involve some badly broken internal processes at a couple of mid-sized companies. These processes were affecting both the effectiveness of presales and ultimately the win-rate of sales. You know when a process is so badly broken that the injured parties readily admit that they spent more time trying to fix the blame as opposed to fix the process, which is why a third-party comes in to obtain resolution!

In both cases, email was to blame, and the people who relied upon it as their primary communications mechanism. (I am going to write a longer article about this topic but I need to get it off my chest now). Instance #1 involves a company with incredibly poor Discovery habits and instance #2 a company where presales spends 35% of their time bailing out customer support. Repeatedly, an email was

A)     left unanswered

B)      sent solely as a CYA (Cover Your A$$)

C)      incomplete and poorly written

D)     partially answered

My response in both the situations was to say “pick up the phone!”.  An email is linear (in the good old days we’d call it half-duplex) as only one party can communicate at a time. An email can’t contain (much) emotion – I don’t feel there is much room for smiley-faces in business communications unless you really know the other person. A phone call allows you to get all your questions answered (you’re in presales – you know how to ask questions and get them answered!). Plus a phone call leaves no audit record other than that the call was actually made. So you can say things in a call you cannot put in an email.

So if you are frustrated in some internal process (or even in a customer communication) see if email is in the communication chain. If it is – ask yourself what would happen if you picked up the phone rather than send another email?

Maybe things would magically get better.

In my two engagements, the discovery rate doubled and presentation standards have improved dramatically in just three weeks for one customer, and the other customer reports that post-sales time has decreased from 35% to a still-high 22% and is trending downwards.

What vs Why?

Why use What?

We are all taught that the best questions in the discovery process are open-ended questions which can kick-start a conversation. They are way better than closed-ended questions which elicit a "yes" or a "no". Closed questions have their place at the start and end of conversations, but open-ended questions are the way to go.

Almost every sales methodology teaches the utility of "Who, What, Where, When, Why and How?" So is one of them better than another? Today we'll look at Why vs What. Now maybe it is my classic British education, but I find What to be a far more open and smoother conversational pivot than Why? Using Why always seemed to be more confrontational and questioning than using a What? Take a second to think about it and examine these two variations.

1. Why do you think that?

2. What do you think about that?

I prefer option #1, as do most people in my unofficial poll. In fact, to borrow a line from Scott Eblin, the only bad what question is "What in the hell were you thinking?"

So the lesson here, especially if you are one of those people who mentally prepare their questions beforehand, is to prefer the What over the Why when you are trying to build a relationship in the initial phases of the sales cycle.