Category Archives: process

Using “Win Themes” to Improve Your Sales Management and Increase Win Rates

At most sales review meetings what do you hear sales management asking the reps?  Questions like these:

  • What stage is this opportunity in?
  • What value do you have it at in the pipeline?
  • Is there upside to that value?
  • What forecast category is it in?
  • In what quarter will it close?
  • What competitors are in the deal?
  • What products will they be buying?
  • Do they have budget for the purchase?
  • How do we meet their primary requirements for a solution?
  • How have we demonstrated that we can meet those requirements?
  • What are the impacts of not solving those problems?
  • How did they attempt to solve those problems before?
  • Who is impacted by the consequences of those impacts?
  • Who is the primary decision maker?
  • What is the decision-making process?
  • Who else is involved in the decision and in what roles?
  • Who have you developed relationships with in the account?
  • What risk is there of a goal-post move?

And on and on.

Some of these questions are about systems and process.  Some are about forecasting.  Ideally, most are about the problem the customer is trying to solve, the impacts of not solving it, how they tried to solve it before, the ideal solution to the problem, and the benefits of solving it.  But in our collective hurry to be process-oriented, methodology-driven, systems-compliant, and solutions-oriented, all too often something critical gets lost:

Why are we going to win?

What?  Oh shoot.  Yep, forgot to ask that one.  And, of course, that’s the most important one.  As I sometimes need to remind sales managers, while the process is great, let’s not forget the purpose of the process is to win.

(I’ve even met a few sales managers so wedded to process and discipline that I’ve wondered if they’d rather crash while flying in perfect formation than win flying out of it.)

Process is great.  I love process.  But let’s not forget the point.  How can we do that?  With win themes — two to three simple, short, plain-English reasons why you are going to win the deal.  Here’s an example.  We are going to win because:

  • Joe the CFO saw first-hand how Adaptive didn’t scale in his last job and is committed to purchasing a system he can grow with.
  • Our partner, CFO Experts, has worked with Joe in the past, has a great relationship with him, and firmly believes that Host is the best fit with the requirements.

Build win themes into your systems and process.  Don’t add win themes to the bottom of your Salesforce opportunity screen; put them right up top so the first conversation about any deal — before you dive into the rabbit hole — is “why are we going to win?”   Two to three win themes should provide a proposed answer and a healthy platform for strategic discussion.

(And, as my friend Kate pointed out, in case it didn’t come up in the win theme conversation, don’t forget to ask “why might we lose?”)

Just Effing Demo

I remember one time reading a win/loss report that went something like this.

“We were interested in buying Host and it made our short list.  When we invited you in for a demo with our team and the CFO, things went wrong.  After 20 minutes, your sales team was still talking about the product so the CFO left the meeting and didn’t want to evaluate your solution anymore.”

Huh?  What!  We spend a few hundred dollars to get a lead, maybe a few thousand to get it converted to a sales opportunity, we give it to our sales team and then they ‘show up and throw up’ on a prospect, talking for so long that the key decision maker leaves?

Yes, salespeople love to talk, but this can’t happen.  I remember another time a prospect called me.

“Look, I’ve been using EPM systems for 25 years.  I’ve used Hyperion, Essbase, TM1, and BPC.  I’ve been in FP&A my entire career.  I have an MBA from Columbia.  I am fully capable of determining my own needs and don’t want to play Twenty Questions with some 20-something SDR and then play it again with some sales consultant before I can get a live demo of your software.  Can we make that happen or not?”

Ouch.  In this case, our well defined and valued sales process (which required “qualification” and then “discovery”) was getting in the way of what the eminently qualified prospect wanted.

In today’s world, prospects both have and want more control over the sales process than ever before.  Yes, we might want to understand your requirements so we can put proper emphasis on different parts of the demonstration, but when a prospect — who clearly knows both what they’re doing and what they want — asks us for a demo, what should we do?  One thing:

Just effing demo  —  and then ask about requirements along the way

Look, I’m not trying to undo all the wisdom of learning how to do deep discovery and give customized demos, espoused by world-class sales trainers like Barry Rhein or in books like Just F*ing Demo (from whose title I derived the title of this post [1]).  These are all great ideas.  They should be your standard procedure.

But you need to remember to be flexible.  I always say don’t be a slave to metrics.  Don’t be a slave to process, either.

Here’s what I’ve learned from these situations:

Avoid triple-qualifying prospects with an SDR, then a rep, then an SC. Make SDR qualification quick and light.  Combine rep and SC qualification/discovery whenever possible. Don’t make the prospect jump through hoops just to get things started.

Intelligently adapt your process. If the prospect says they’re an expert, wants to judge for themselves, and just wants a quick look at your standard demo, don’t try to force a deep discovery call so you can customize – even if that’s your standard process.  Recognize that you’re in a non-standard situation, and just show up and do what they want.

Set expectations appropriately. There is a difference between a “Product Overview” and “Demonstration.”  If you think the right meeting is 30 minutes of slides to frame things and then a 30-minute demo, tell the prospect that, get their feedback, and if everyone agrees, then write “Product Overview” (not “Demonstration”) on the agenda.

Don’t make them wait. If you say the presentation is a one-hour demo, you should be demoing software within the first 5-7 minutes.  While brief personnel introductions are fine, anything else you do up-front should tee-up the demo.  This is not the time to talk about your corporate values, venture investors, or where the founder went to school.  Do that later, if indeed at all.

# # #

[1] A great book, by the way.  My favorite quote:  “in short, I stopped trying to deliver the perfect demo for my product and starting trying to deliver the perfect demo for my audience.”

Managing Change: The Sailboat Tack Principle

Change is hard in business.  A few things routinely get messed up:

  • Pulling the trigger.  Think:  “wait, are we still discussing this change or did we just decide to do it.”  I can’t tell you the number of times I’ve heard that quote in meetings.  I think continuous partial attention is part of the problem.  Sometimes, it’s just straight-up confusion as the enthusiasm for a new idea ebbs and flows in a group conversation.  It can be hard to tell if we’ve decided to change or if everyone’s just excited about the idea.
  • Next-level engagement.  Think:  “wait, I know we all like this idea on the exec staff, but this decision affects a lot of people at the next level.  I need some time to bounce this off my leadership team and get their input before we go ready/fire/aim on this.”
  • Communications.  Think:  “wait, this change is a big deal and I know we just spent every minute of the three-hour meeting deciding to do it, but we need to find another hour to discuss key messaging (5W+2H) for both the internal and external audience.”
  • Anticipatory execution.  Think:  “While we had not yet finally approved the proposal for the new logo, it was doing very well in feedback and I just loathed the idea of making 5000 bags with the old logo on them, so I used the new one even though it wasn’t approved yet.”

When you screw up change a lot of bad things happen.

  • Employees get confused about the company’s strategy.  “First they said, we were doing X, and then the execs did an about-face.  I don’t understand.”
  • The external market, including your customers, get confused about what you are doing.  This is even worse.
  • You can end up with 5,000 bags that have neither your old logo nor your new logo on them.
  • You can make your management team look like the Keystone Cops in one of many ways through screwing up sequencing:  like dropping off boxes before the big move is announced, or employees finding out they’ve been laid off because their keycards stop working.

In order to avoid confusion about change and the mistakes that come with it, I’ve adopted a principle I call the “sailboat tack principle” which I use whenever we are contemplating major change.  (We can define major as any change that if poorly executed will make the management team look like clowns to employees, customers, or other stakeholders.)

If you’ve ever gone sailing you may have noticed there is a strict protocol involved in a tack.  When the skipper wants to execute a tack, he or she runs the following protocol.

Skipper:  “Ready about”

Each crew member:  “Ready”

Last crew member:  “Ready”

Skipper:  “Helm’s a lee.”

That is, the skipper does not actually begin the maneuver  until every involved crew member has indicated they are ready.  This prevents partial execution, people getting hit in the head with booms, and people getting knocked off the boat.  It also implicitly makes clear when we are discussing a possible course change (e.g., “I think we should set course that direction”) from when we are actually doing it (e.g., “Ready about”).

For those with CS degrees, the sailboat tack principle is a two-phase commit protocol, used commonly in distributed transaction processing systems.

I like the sailboat tack protocol because the extra discipline causes a few things to happen automatically.

  • People know implicitly when we’re just talking about course changes.  (Because no one is saying “OK, so do we want tack here?”)
  • People know explicitly when we are actually making the decision whether to execute change.
  • The result of that extra warning — “hey, we are about to do this” triggers numerous very healthy “wait a minute” reactions.  Wait a minute:  I need to ask my team, I need to make a communications plan, I need to examine the compensation impact, I need to think about what order we roll this out in, etc.