Sorry, But Demo Is Not A Sales Cycle Stage

I think two demo practices are nearly universal these days and I’m not a big fan of either:

I discussed using demo as the primary website CTA in a previous post.  In this post, I’ll cover my objections to using demo as a sales cycle stage.  I know that both of these viewpoints are controversial, so please classify them in the thought-provocation department [2].

What are Sales Cycle Stages?
Companies use stages to decompose the sales process into a series of steps.  For example:

  1. Prospecting
  2. Contacting
  3. Qualifying
  4. Presenting
  5. Objection handling
  6. Closing

Sometimes those steps are phases that you exist within, other times they are milestones that you pass [3].  Companies use stages to track the progress of deals, the aging of deals to ensure they don’t get stuck, and typically weight the pipeline by stage as a way of triangulating the forecast.

Seller-Out or Buyer-In?
When you first learn about sales cycle stages they are typically presented, as they are above, from the seller’s point of view.  Over time, most people realize this is wrong, particularly when they’ve moved to the increasingly popular framing that selling is not a process unto itself, but more the facilitation of a customer’s buying process.

In this paradigm you try (and it’s not always easy) to define stages from the buyer’s viewpoint instead of the seller’s.  For example, using milestone-based stages, this might look like:

  1. Need established.  Buyer a has problem for which they are seeking a solution, typically as verified by an SDR.  [4]
  2. BANT verified.  Buyer has not only a need, but budget, authority to spend it, and a timeframe for purchasing a solution — all as verified by a seller.  [5]
  3. Deep dive completed.  Buyer has performed a deep dive with the seller to fully explain the problem and answer questions about it.  [6]
  4. Solution fit confirmed.  Buyer believes that the seller’s product can basically solve their problem.  [7]
  5. Vendor of choice.   Buyer believes that the seller’s product is the best choice of solution to the problem.
  6. Redline.  Buyer’s legal team has reviewed the contract and submitted a turn of redline markup.
  7. Contracted.  Buyer has completed the contract and other required paperwork.  Also known as closed/won.

Notice that the first word of every stage definition is “buyer” in order to keep us focused on the buyer, not the seller.  There are three other great features of the above style of system:

  • Every stage is verifiable.  In many staging systems, it’s hard to know what stage you’re in [8] and nearly impossible for a sales manager to verify it.
  • Sellers can be pushed for evidence in deal reviews and pipeline scrubs.  Example.  Manager: “You classified this as stage 4, why?”  Seller:  “Because, they said they think we can basically solve their problem.”  Manager:  “Who said that and when?”  Seller:  “Paula the VP said it at the end of the meeting last week.”
  • Management verification can be done by asking the buyer a single question.  Manager:  “So, your seller Joe says you’ve done a deep dive together on the problem you’re looking solve?”  If yes, stage 3.  Manager:  “So, your seller Jane tells me you think we can basically solve your problem?”  If yes, stage 4.

My Problems with Using Demo as a Stage 
Given that I like buyer-in, verifiable staging systems, it’s probably no longer a surprise that I don’t like demo as stage, but here’s the full list of reasons why:

  • Demo is seller-out.  I learned to hate seller-out stages back in the day when “proposal” was also a stage.  You can send a proposal to anyone at any time — what does that actually tell you about the progress of a deal?  Nothing.  The same holds true for demo.
  • Demo is not buyer-in.  It doesn’t tell us anything about where the buyer is in their buying process.  Just that they got a demo.  By the way, which kind of demo did they get?  Did we do a custom demonstration mapped to a precise problem they are desperate to solve or did they just passively watch a 30-minute generic demo?
  • Buyers may want demos at very different phases of their buying cycle.  Gadget people want a demo of everything.  Others may want a demo before making their long list.  Some may want a demo before making their short list.  Others may only want demos of two finalists.  Many will want multiple demos to different people along the way.  Remind me how demo tells you where are you in the sales cycle again?
  • Buyers should be able to get demos when and how they want them.  Could you imagine saying, “you can’t have that white paper until we’ve completed step 3 of our process?”  That’s effectively what you’re doing when you make demo a stage.  Think:  “I’m sorry, demo is our stage 4 and we haven’t completed stage 3 yet; can we get back to what I’m focused on, please?”  In a world where buyers want ever more control over the buying process, that dog don’t hunt.
  • You risk building an expensive custom demo into your sales process.  Once demo is a declared a stage, sellers start focusing on the demo as the big event.  Well, we need to gather requirements for the demo.  Oh, we’ll be showing you how that works as part of the demo.  Yes, we’re working on customizing the demo for your industry and solution.  What if the customer didn’t want or need some big customized demo to buy your software?  What if believing you could basically solve their problem and thinking you were the market leader (i.e., safe choice) were enough?  You risk imposing the demo on the buyer (“well everybody does it”) in the name of process rather than remaining focused on their buyer and their solution.
  • Conceptually, demo is part of confirming solution fit.  The usual reason for a demo is to help the buyer establish if the product can (basically) solve their problem [9].  What we should be focused on is whether they think we can solve their problem [10], and not whether they got the demo.
  • Be careful what you wish for.  If you wish for a lot of demos, you’ll end up doing a lot of demos.  The question is will they lead to sales?  I’d rather focus on convincing a lot of people that we can basically solve their problem or that we’re the best solution to their problem — or that we can basically solve their problem and we’re the clear market leader — than on giving a lot of demos.
  • Demo defaults to the reference point.  Once people start using demo as a stage, it quickly becomes the default mid-funnel checkpoint and two metrics rise to the top of management reporting:  demos/week and demo-to-close rate. If you think demo is effectively meaningless as a stage, this is obviously problematic.  It’s like saying how many schmumbles did we do this week?  50.  How many did we do last week?  30.  Awesome, schmumbles are up this week!!  What’s a schmumble?  I don’t know.

All that said, I understand why people like to use demo as a stage — demos are tangible, you know when they happened, they often do happen at roughly the same place in the sales cycle, and they are indeed often required.

But making demo a sales cycle stage hard-codes demos into your sales process and, like hard-coding in programming, while it may be expedient in short-term, you may well live to regret it in the long.

# # #

Notes

[1]  Except in product-led growth (PLG) models, where it’s trial, which is indeed the point.

[2]  In both cases, I know these practices are entrenched so I’m not asking anyone to blow up their website or their sales pipeline management process.  I am, however, asking you to think twice about how you use demo both on your website and in your sales cycle, with an eye towards potentially changing your approach.

[3]  It’s shocking how many companies can’t answer the question:  are your stages phases or milestones?  That is, does “stage 4” mean you are “in” stage 4 or that you have completed stage 4.  When defined as phases, you will often find “exit criteria” that define what needs to be done to exit the stage.  Either way, it has to be crystal clear when you have exited a stage or not.

[4]  This is typically done after other preliminary qualification has occurred, such as company-size or industry to ensure the buyer is in the target market.

[5]  Also known as a sales-accepted opportunity.  This is the point, in most companies, where the opportunity officially enters the pipeline.

[6]  This may involve a single meeting, or a sequence of them, depending on the complexity of the problem and the potential solution.

[7]  Notwithstanding certain detailed issues that remain open questions, but overall, the buyer has reached the conclusion that the product can basically solve this problem.  This is not to say that it’s the best, the only, or the most cost-effective solution to the problem; merely that it can solve the problem.  Think:  a tank could likely solve my stump-removal problem, but then again so could The Dominator.

[8]  Among other ways, this can happen in a phase-based system where there are lots of exit criteria per stage.  I’ve literally seen systems where you could win the deal before clearing all six of the stage 3 exit criteria!

[9]  Putting aside purely educational demos which I think are best handled by marketing.

[10]  Which can be accomplished through other means as well — e.g., case studies, reference calls.  Believing that someone like me solved a problem very similar to one like mine is often a far more powerful way of confirming solution fit.  As is merely demonstrating deep expertise in the problem to solved by, e.g., completing a few of the customer’s sentences when they’re describing it.

11 responses to “Sorry, But Demo Is Not A Sales Cycle Stage

  1. I know the focus on this article is demos, however I found the buyer-in framing of sales stages very interesting. Most sales stages I’ve seen are seller-out; while some have some buyer milestones (solution-fit confirmed) but these too are expressed in terms of seller-out and not buyer-in.

    I think there’s blog post about buyer-in stages waiting to be written, Dave.

  2. Thousands of Websites Offer “Book a Demo” – Should Another Option Be “Book a Conversation”?

    Think about it…

    Wouldn’t it be great to start the interaction with your customers with a conversation – or a substantial Discovery discussion – before offering a live demo?

    – Consider the time saved for both customers and vendors by focusing on the identified issues
    – Consider the shortened sales and buying cycles, enabled by improved clarity
    – And consider the reduction of wasted demos delivered by valuable presales folks (often over and over and over and…!)

    Most websites have a “Request Demo” button featured prominently on the home page – very often highlighted in a contrasting color and eye-catching shape. The intent, of course, is to entice the customer to engage. The intent is fine, but it mis-sets expectations:

    – The lead is often passed to a BDR or similar, whose job is to contact the lead, “quality” and set a follow-on appointment for a demo. What is the value to the customer in this first interaction? Generally zero…
    – Next, a demo is scheduled, often with a presales professional, who at this point understands very little about the customer’s needs, desires, or situation. A live, but largely “canned” demo often takes place, sometimes with the presales person trying to do small amounts of Discovery on the fly.

    Result? Mis-aligned demos where the customer often doesn’t see what they want – and another “Harbor Tour” delivered by a valuable and limited presales resource. Uncompelling and mutually frustrating.

    And then what happens? If the customer is still interested (or convinced by sales), another demo is lined up – often with a request by the vendor for an opportunity to (finally) have a Discovery conversation.

    This pathway basically wastes 1-2 interactions for both parties – compared to this alternative…

    What if the customer is comfortable investing a few minutes to outline their situation before moving to a demo? Research suggests that many customers would prefer this…! (See Developing Your Sales Team: The Essential Sales Playbook for Founders and Entrepreneurial CEOs by Steve Kraner, page 72, Kindle version.)

    So… Let’s run the experiment!

    Add a button on your home page that offers a conversational alternative to “Book a Demo”. Do some testing (e.g., have only the “Demo” button, have only the “Conversation” button, offer both) – then compare results!

    Here are a few other possibilities for alternative buttons, with the “Button” text followed by a sub-title:

    “Book a Conversation” Let’s discuss what you have in mind

    “Help Me Diagnose My Problem or Situation” Before leaping to a solution, let’s make sure we both understand all of the important factors

    “Help Me with My Exploration and Buying Process” If you are new to purchasing this kind of software, we’re happy to help – we’ve helped other customers many times before

    “Assist Me with My Buying Process – My ‘Buyer’s Journey’” If you are new to purchasing this kind of software, we’re happy to help – we’ve helped other customers many times before

    “I’d Like to Explore the Options” There may be things you haven’t yet been exposed to that could be important for you

    “Here’s My Thinking So Far” Let’s start with an overview of your problem and your current vision of a solution – and then we can explore from there

    Thoughts, folks?

  3. In the meantime, have a look at Brett Queener’s series Kay if you want to read up on buyer-in sales stages / sales forecasting. https://medium.com/@brettqueener/enterprise-sales-process-forecasting-done-right-part-1-bfa549729a5b

  4. Dave – this is wonderfully aligned to my thinking.

    Software buying has been sales-led for decades, and now product-led. Even the latter is a misnomer for something that’s supposed to be for the buyer.

    The future is Customer-Led buying. One where the software buyer gets to choose how they want to engage and when they want to.

    All customers want is to be able to have a hands-on evaluation experience without needing to talking to anyone. Where you can go directly into multiple products with data and workflows built out so that you can truly test and experience before you buy.

    It’s why we are building TestBox. We allow decision-makers to directly compare software products side-by-side in a live simulated environment. With guided walkthroughs, pre-configured use cases designed by real users, and collaboration tools built in.

    Anyway – not here to spruik – just here to say I absolutely agree and am excited you are seeing a similar future.

  5. Very interesting article. What is your thoughts on what an SDR’s responsibility should be? In our world, the SDR is responsible for booking demos with qualified prospects (defined as agreed upon ICP accounts with the right titles/persons). It then becomes the sales person’s job to qualify. While we have technically put the demo into the sales pipeline, it’s more for expedience in tracking than counting pipeline revenue generated.

    • While there is no one-size-fits-all answer, in general, I’m arguing to try and avoid defining the SDRs job as booking demos because often, in the companies I’ve worked with, the ensuing call with the seller is kind of a mess (“spinning plates” as described in the post). Here’s what I’d do: listen to a dozen of those calls via Gong, decide if you think they work. If yes, fine. If no, if the seller is struggling, if the demo quality is poor, or any other problem then I’d start a weekly live demo, have SDRs send people who want demos there, and then hand people to sellers who want to speak to sellers (not who just want to see demos). The other thing I’d do is ask sales how they feel about the process and the demos from a use-of-their-time perspective and from buyer-experience one.

      • Ok, it feels like from your response that you believe the role of the SDR is to have more qualification responsibilities – as in only setting up meetings with sales who have passed some variation of BANT criteria. My take on that is you’re then relying on a team who is often the most junior in the company (and in their career) vs seasoned sales reps to qualify an opportunity before sending it to them – an exercise that almost always results in your concern of “double qualification” as a junior SDR will rarely be able to ask all the right questions, sift through the nuance, be taken seriously, etc. (BTW, I’m in a SaaS business where we are trying to establish a new category where the buyer rarely has existing line items in their budget for our solution, Medium to Enterprise-class customers, $30k-$500k contracts).

      • Dave K, love the content and challenge in mentality, we are going to adopt this for our process, so thanks! Question I have is Stage 2, BANT can often be discovered throughout the process and getting to all of those details before you ‘progress the buyers journey’ to something like a deep dive of the problem, I see that as a potential issue here but would love your thoughts. Some of these feel less like a sales stage progression (first 1, then 2, then 3) which is of course seller in mindset vs a check box ‘do you have this done’ mindset vs a linear progression which lends itself to pipeline maturity, weighted analysis, etc. Thoughts?

      • BANT is controversial for many reasons, some of which you mention. One favorite of solutions sellers is all you should need is PAIN (need) and AUTHORITY and an empowered executive can create the timeframe and the budget. And that’s true — if you’re selling to someone high enough in the org to do that. Looking at the process outside the real essence of stage 1 to stage 2 is this: at stage, given whatever set of rules, a BDR thinks it’s an oppty. My actual definition of stage 2 is that a quota-carrying rep agrees it’s a valid oppty (however defined). I think of the process like a safe deposit box; it takes two keys to get an oppty into the pipeline. The criteria for when those keys gets turned will vary but should be clearly defined so you can inspect it. That’s what really matters.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.