Category Archives: process

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.