Nailing the Technical Demo

For anyone (especially our loyal readers and listeners!) that has ever been involved in a software sales cycle, the delicate and nuanced nature of this professional has surely not gone unnoticed.

The need to be consultative, but firm. Flexible, but focused. And – most of all – both business and tech savvy.

Never is this skills dichotomy more true than in a technical sales environment. It’s one thing to know how to sell, and another to make sure you know exactly what your product does and how it helps your customers.

For Matt Cassel, an Account Executive at San Francisco’s Chartio, flexibility begins with understanding what type of buyer he is speaking with. For example, Chartio sells embedded business intelligence software that is applicable to both business and technical users.

As a result, he has to be comfortable describing Chartio’s value to those in both marketing and IT departments.

“For a demo or high-level overview of Chatio, I actually like to give people two paths. If they are a technical buyer, I ask them if they would like to start with connecting data sources, and then get into chart building and dashboarding. That is an afterthought sometimes. Technical people are so focused on getting a product to connect to their data sources, they don’t even think of the finished product,” says Cassel, on a recent edition of The Predictable Revenue Podcast.

“If they are more of a business person, I start with dashboarding, maybe get into chart building. I don’t really touch the data sources. But, I always ask them what they want to see and learn what aligns most with what they want to get out the call.”

Simply put: for technical buyers, front load the technical stuff. For business buyers, show them what their data looks like.

Getting Specific

It’s from that high-level perch that Cassel can begin to get into the specific requirements – critical details in technical sales – that his customers need. So, throughout the initial demo, Cassel says he works to extract precise needs and requirements to ensure Chartio is a good fit for the people he is speaking to.

The trouble, however, when you’re selling a technical product is there are so many applications that it can be used for. And, it can be hard to pin down exactly what the person you’re speaking with wants to use the product for because they might not yet know.

For example, they may be generally interested in a company-wide analytics. But, that doesn’t answer the specifics of what each team in the company would need for their tailored analytics. On the other hand, if customer asks to see specific reporting option for marketing, then Cassel can drill down on that.

Another excellent angle of extracting key information for Chartio is asking about specific data sources, then showing how to connect to it. This shows the software in action and helps avoid a rudderless feature-heavy demo (simply running through every feature of your software will not help you stand out from the crowd).

“Demoing in the product tends to work because when you are dealing with data, it can be very messy,” says Cassel.

“And, it is a certain kind of messiness that you are not going to qualify out until someone is actually testing it against their live data.”

Another benefit of gleaning in-depth info from technical buyers is that that data will allow Cassel to determine if Chartio can help them at all. Disqualifying prospects is a powerful option for all companies, but in the realm of technical selling, understanding who you can’t help is critical.

For instance, forcing a technical sale will only create headaches for customer success and products teams with out-of-scope feature requests.

“If it a use case that we can’t help with, we qualify them out,” says Cassel.

“We’re in a competitive space, so there are options. So, if Chartio is not the right fit we’re happy to tell them we can’t help them and point them in the right direction.”

Helping the Sales Engineer

A defining feature of the technical sales cycle is the presence of the sales engineer. Different companies may choose to include a sales engineer at different points of the sales process – some earlier, some later, depending on what the customer needs.

At Chartio the sale engineer joins the sales process during the technical working session (the meeting after the initial demo). During the technical working session, the role of the sales engineer is to answer any technical questions the Account Executive isn’t able to. That could mean answering detailed integration questions or discussing specific metrics from the customer’s database.

But, there are pitfalls to the elevated technical nature of these calls as well. For instance, a customer with numerous detailed questions, or questions that require lengthy answers or demonstrations, can derail the call for any participants that aren’t as technically proficient.

When that’s the case – or, pre-emptively, when that’s considered a threat – it’s up to the Account Executive to keep the call moving forward.

“The salesperson should know when not to speak, but navigate the conversation tastefully for the sales engineer can help,” says Cassel.

“For example, it’s easy on these calls to go down technical rabbit holes. But, there may be a lot of people on the call that could get confused from that sort of discussion. So, the AE can be a lot of help in navigating that, and maybe offering to set up a time where that deep technical discussion can be had with the parties that need to know.”

Common Mistakes

The flip-side to keeping a technical call focused, of course, is not paying close enough attention and leaving the sales engineer to stickhandle the entire technical working session.

For Account Executives, it really isn’t just kicking off the meeting then,. Coming back at the end of the call to help determine next steps,” says Cassel.

“The salesperson should know when not to speak, but navigate the conversation tastefully for the sales engineer can help.”

It’s also important for salespeople to remember to share social proof when necessary. As the sales engineer continuously weaves technical support, it is incumbent on the AE to remind everyone on the call of the business case the software solves.

That might include sharing the success of other relevant clients, or determining if follow up calls need to be scheduled.

“In general, AEs interrupt unnecessarily. If you are interrupting without adding value, or stop paying close attention, that doesn’t help,” adds Cassel.

“Make sure everyone’s time is being used appropriately. AEs are the defenders of their sales engineer’s time. But remember, to drive the sales process, it is the salesperson’s job.”

For more on Matt Cassel’s technical sales experience and best practices, check out his recent edition of The Predictable Revenue Podcast.