The First Law of Business Value Discovery

Twenty-five years ago, a bunch of Sales Engineers sat in a bar (this sounds like a joke..) and came up with a number of rules and principles to guide them through the Business Discovery Process. Over the years I’ve added to and refined that list and it now forms part of our Business Value Discovery (BVD) workshops. Of course – the most important of all these rules is the First Law – and that’s the one I want to take you through.

It’s not anything like “ask open-ended questions” or “challenge the customer” or “link your technology to the business” as they deal with the how of BVD, instead it focuses, just as you should, on the customer outcome, or the what and why. The long version is:

“Every technology purchase is driven by a single business number. Either that number is too small and someone want to make it larger, or it’s too large and someone wants to make it smaller.”

The key to being a world-class Sales Engineer is uncovering

(a)    What is that number?

(b)   Who cares about the number?

(c)    Does it need to be made larger or smaller?

(d)   What’s the economic value to the customer of that change?

(e)   Is it important to change that number NOW?

Think about some of these situations. A number may be too large and needs to be reduced.

1.       Cost Of Goods Sold

2.       Response Time

3.       Online Shopping Cart Abandonment Rate

4.       Backup Time

5.       Personnel

Or a number may be too small and need to be increased.

1.       Market Share

2.       Success Rate

3.       Upsell Ratio

4.       Gross Profit

5.       Employees With A Specific Skill Set

Here’s the call to action. Think about the last dozen sales transactions you have been involved with – either as a sales rep, presales engineer or services person. What was your customer’s number? How early in the sales process did you uncover it? Is there any common theme across your customer base?

Understanding and then satisfying the First Law Of Business Value Discovery allows you to focus on outcomes and results instead of features and functions. First things first!!

 

(Note to true engineers: Yes - I know I conflated law, rule and principle)

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.

The Solution Selling Empire Strikes Back

I had a quick trip out to Las Vegas this week for a fun ½ day whiteboard class with a new client, and decided to use the air time to clear out some of my backlog of business books. It was either that or dive into Book 5 of “Game Of Thrones”.

So I picked “The Collaborative Sale” and here is my review and my thoughts – in a longer version than the website or the August newsletter – and written from the Sales Engineering viewpoint.

Classic “Solution Selling” has come under fire and criticism since the publication of The Challenger Sale and the July 2012 Harvard Business Review article titled “The End Of Solution Sales”. The Collaborative Sale by Eades and Sullivan is basically a somewhat artificial and heavy 210 page defense of Solution Selling. Updated and modernized, it pushes the concept of collaborating with your customer to end up with the correct “solution”. You do this, as a seller, by adopting one of three personas – the Micro Marketer, the Visualizer and the Value Driver.

My issues (or pains) with this book is that:

#1 – It is extremely salesrep focused, to the point of placing the rep at the top of the pyramid and everyone else subservient to him/her. I may be biased based upon my target audience of Sales Engineers, but this book seemed worse than most in assuming that no-one else really matters and that the rep solely sets strategy. We all know that doesn’t (or at least shouldn’t) happen and that on many occasions the old-hand SE has to introduce the new rep to the politics and history of the account and then continually course correct.

#2 – The basic strategy of artificially adopting and shifting persona seems like you are not being true to yourself or the customer. It’s hard to become the “Trusted Partner” if you aren’t being honest with the customer – they’ll see through it. The personas need to become learned and natural behavior rather than forced tasks and interactions.

#3 It is fixated upon Buyer 2.0 and that’s already last year’s model. Much of the statements about Buyer 1.0 and implicitly Seller 1.0 are straw men designed to make a case, rather than be rooted in reality. The market, the competition and the buyer are constantly adapting, and you need to do that as well.

#4 The coaching strategy is based upon weaknesses and gaps rather than building strengths. Any manager who approaches account reviews with their reps in terms of “what did you do wrong” isn’t going to get too far. Imagine if your manager started with “let me tell you the 10 things you did wrong in that demo”.

#5 I feel (and this is just a feeling and is never explicitly stated) that the importance of Discovery in the Collaborative Sale is diminished on the basis that the customer is already 50-60% of the way through a deal and you are always in catch-up mode. My take is that Discovery is becoming even more important rather than less for the SE community. Sales should take it that way as well.

 As an SE I don’t feel there is much to gain from this book versus good old The New Solution Selling (which I do recommend) unless your company is actually adopting this process. There are changes in promoting customer alignment rather than control and the sections on technology you can use to create a self-brand are interesting, but that’s about it.

I do know that SPI (the folks who own Solution Selling) run great classes with role plays and practical examples that have to be far more on target than this book which focuses on the what, but never on the “how do I do that?”.

This isn’t a book for the SE library. The Challenger Sale is more applicable and on point than the Collaborative Sale.

Why Businesses Buy Technology

I talk about “The Three Wise Men” a lot in my workshops. They are the guiding principle why businesses make technology decisions – being:

1.       Increase Revenue

2.       Reduce Costs

3.       Mitigate (Decrease) Risk

So it was heartening to read the “connect” article in the September issue of CIO Magazine, which showcased the advice of CIO’s to their peers. In particular, the advice of Rick Roy – the SVP and CIO of CUNA Mutual Group. I quote his advice in full.

“We use three macro-level business metrics to prioritize IT investment decisions and set strategy: revenue growth, cost reduction and risk management and compliance. For line of business spending, it’s rare for someone to introduce a major initiative without a strong connection to one of those. But at the enterprise level it’s more challenging. How does that Windows 7 upgrade really help the business? Whoever presents that case has to make the connection.

Risk mitigation and compliance are the hardest to quantify. We must distinguish between the need-to-have and the nice-to-have. We can’t just say we need to invest in something because the risk is high. What does that mean? Will we lose money? How much? Will we lose customers? How many? We take advantage of our in-house actuarial and risk-modeling expertise to quantify risk.

We look at IT spending in business terms, reporting our costs as an expense ratio. It changes the conversation from “IT costs too much” to a conversation about priorities. It requires more rigor, but it benefits IT to have a clear focus on our top priorities”

Beautiful – well said Rick!! A lesson in there for every single Sales Engineer and every single sales representative.

June MTS Content Posted

The June Mastering Technical Sales Newsletter will be published on June 8th. This month's lead article is "How Many Sales Engineers Does It Take To Sell A Solution?" Part I. In this first part I look at the typical history of a vendor (software/hardware/services) as it grows from a start-up in a multi-channel, multi-solution company. It's a "How Did We Get To This Point?" lesson.

The July conclusion will examine the potential solutions to reducing the size and complexity of both the sales and pre-sales organization.

The personal skills article this month is about "Pricing and the Sales Engineer". Although SE's shouldn't talk very much about pricing (if at all), there is plenty they should understand.