Stop doing product demos
This week, I responded to an outbound sales email from a software company focusing on customer success. The last line of the rep’s email was:
I would appreciate the opportunity to speak with you for a few minutes. When would be a good time to call?
let’s chat. I can do Wed 2:30-4pm or Thurs b/t 3-5pm Pacific
He then replied with a one-hour meeting invite, to which I replied that I could only do 30 minutes, and when we logged into the call, he was ready with his Account Executive to plow through a 60-minute product demo in 30 minutes – they even said as much – “Yeah… Usually we like to take an hour to demo our product but we’ll do our best in 30 minutes today.”
Dude. Chill the f&ck out. You don’t even know me, my company, my problem, or why I’m interested in talking with you. And most of all, your email to me asked for a “few minutes,” and instead you’re expecting me to take an hour to watch you impress yourself with how great you demo your product?
Sheesh…. They’re lucky I did their job for them.
I took over the call – “Here’s why I’m interested in talking with you…” then I gave them the background of where we are as a company and why I replied. Even then, he kept trying to plow through the demo, like he had some kind of checklist he was required to complete in every call. I had to stop him several times just to ask questions. It’s a good thing the product looks interesting to me or he’d be dead and never know it.
So what should you do instead?
Be cool. See how long you can take a sales call without talking about your product. Even better, see how many conversations you can have with a prospective customer without showing your product.
Why do this?
As an entrepreneur, you product is your baby. You’ve identified a gap in the market, and you’ve put in the time, sweat, and toil to craft your solution.
But here’s the thing – No one cares about your product, they care only about their problem.
Until you’ve shown that you truly comprehend the prospect’s problem, you can’t earn the trust and attention of the customer to show your product. Show your product before you’ve earned that trust, and your customer will be polite, nod her head, and wonder when you will get to “the good stuff” or the part of you product that solves their specific problem.
Every customer and every situation is different. Even if on the surface the customer’s problem appears to be the one that your product solves, there is an entire base of information around that problem – how the problem developed, the people involved, past attempts to solve the problem, how decisions are made within the company, and how the problem affects this particular customer within the organization, just to name a few.
And until you have a clear view of the problem from n angles, you can’t position your product effectively or know which parts of your product are most useful for the customer.
Your solution probably has 10, 20, 50 features and functionalities, yet the customer probably only cares about 1-2 of them – the ones that most directly address their problem.
You need to qualify your prospective customer based on several criteria, because if the prospect isn’t qualified, then there’s no point in whipping out a 60 minute demo. It’s a waste of your time and theirs.
With my work at Blend, we usually require we have at least two meetings with prospective customers before we show even a short demo.
In the first meeting, our goal is to verify a critical aspects of the situation and meeting:
1. Are we talking to the right person/people? Is this person/people the one responsible for solving a particular problem we can support? Are they decision-makers, influencers, users, or simply observers to the problem? If they aren’t decision-makers or responsible for the problem, can they get us access to the right buyers at their company?
2. Validate, for both the prospect and for us, that the problem exists – that the customer knows that the problem exists and that the customer views the problem as an explicit need. The problem must be big enough to spend time and money resources to scope out solutions, and big enough to go through the changeover pain to solve the problem.
Status quo is frequently the biggest competitor, even in cases where the need is explicit. A customer has been “living with” a problem often for years (or decades!). Their patchwork solution using general technology tools like Excel or understand or other internally developed applications might be good enough for the next quarter or through the year until the next budget cycle.
3. Require that the customer to prove interest in our solution – getting them to ask questions about our solution and how it works. Asking questions about integration and implementation with current systems. Asking questions about people and resources that would be required on their end to implement our solution. Once we see that customer are thinking past just – “show me a demo so I can get out of this meeting” – then we know we have a genuine prospect sitting in front of us.
4. Learn about the history of the problem. Is this a new problem, or one that’s been around a while? What’s been tried in the past? Have past solutions include outside partners or were they home-grown solutions? Why has this problem become more urgent recently to the point that the company is ready to take action by way of people, time, and financial resources?
Summary: Figure out your qualifying criteria for your product – a good list to start with it:
- Identify an explicit customer need, ideally enumerating it – “this is costing us $500k per month…” or “with the right technology, we think we can increase revenue by 25% per quarter…”
- Identify the buyer type with whom you are talking
- Articulate how this specific buyer would benefit from your solution
- Learn the history of the problem
If you can answer these four questions, then you’ll know whether or not to bother with showing your product.