Sales Engineering for Software Startups – 3 Signs your Technical Sellers Need Help

As a former sales engineer turned technology consultant, I have a few comments I’d like to make about Sales Engineers and why I find most of them just don’t “cut the mustard”.

I’m a former sales engineer, I’ve held the performance crown, I’ve strategically sold highly complex technical solutions into big enterprise and big healthcare. I’m also in a position now where I watch dozens of sales engineers ply their trade bringing technology to the bank where I work. I think I’m in a pretty good position to comment on this – so here goes.

Now that I’ve got your attention, I’m assuming you’re a software business owner, or a sales VP so read on to see how these 3 small areas can affect your top line.

So you already have a highly seasoned enterprise sales team and on the pre-sales engineering side you think you’ve found the special blend of technical, sales and consultant that most software companies need. Yet you ask yourself why you aren’t selling product into the high value market your product belongs in? Why is your strategic sales pipeline weak? (tons of small deals, no strategic or large deals) Why does it feel like nobody can differentiate your product from the other vendors when the technical proof of concepts and bake-offs are over?

Before you start blaming your sales guys, or the raw presentation capabilities of your sales engineers consider these surefire signs that your sales engineers (technical sales) might be the problem.

1) Not selling value – It’s not about features. If you are selling  your product based soley on features and doing things like creating “feature comparison matrices” to beat competitors, you are already doing it wrong. Doing a “show up and throw up” demo of 100 different features in your product is also the wrong approach. If your sales engineer loads up 50 different screens, or command line windows as part of a standard product demonstration… they are selling features. If your sales engineer has a standard demo over 30 minutes, they are probably boring the potential client to death as well. Yes – this applies to technical products of all complexity. For all of my previous sales engineering positions there were occasions to do 3.5-4 hour demonstrations for enterprise clients, but these were non standard and only drilled into the into the areas the clients were interested in, typically these were also not the first demos, but the executive demonstrations with 20-40 people observing.  Your first demo should be no more than 30 minutes of demo and possibly up to 30 minutes of questions to prepare you for a secondary engagement. A good sales engineer should be able to talk about a product non-stop for 6 hours, but that doesn’t mean he should – which leads us to the next topic.

2) Talking too much – What? I thought we valued the “gift of the gab” in pre-sales engineers. Again… being able to talk your head off, doesn’t mean you should. As a technical sales person you need to “look for the angles”, and this is best done by listening more than talking. If the client is going to ask you a question – shut up, don’t try to prove that you know more than them. Remember – being right, and doing the right thing are 2 different things. On top of the commercial considerations that the sales person is dealing with, you should be asking yourself as the sales engineer “why is this person asking for this technology/feature/capability? Is this a technical problem, or is this a political problem?”. Some of the worst sales engineers I have ever witnessed are more concerned about getting through their boilerplate presentation and ignore the questions of the participants. This is a boneheaded move, mainly because by not fielding questions you can’t answer the questions I posed above, and you waste an opportunity to identify supporters, detractors, and to identify the prominence of each member of the prospective client team.

3)  Bad Tools and Workflows – Sales engineering is one of the most complex jobs as you cycle from field development, to sales, to support, and to implementation as a “trusted advisor”. This means, your tools should be ship shape at all times to make everything you do reproduceable, scalable, and consistent in quality. It is extremely important that the demo workflow you are using is optimized for maximum impact, and that it is supported by the right technology, as well as the right marketing materials to help you follow up. As an example, if the sales engineer doesn’t have a stable demo environment, doesn’t have a reproduceable demo workflow, and doesn’t have a way to reliably bring that demo to the prospective clients…. you are dead in the water. Even worse, if you don’t have the right highly polished sales materials that speak to technicall buyers to use as follow up tools, or the right sales automation tools to ensure that those deliverables reach the target audience at the right time….. what was the definition of insanity?

If you want to supercharge your technical sales process, and help build a strong sales funnel you need to address these 3 main areas when it comes to sales engineering. If you’ve tried before via standard sales management techniques and failed, maybe you need a technical sales consultant to sit in on your presentations, possibly work with your marketing to help you design new collateral, and even better create a whole new way of technically selling your software product higher into the value chain.

I hope you’ve found this post useful, and look forward to the discussion!


One thought on “Sales Engineering for Software Startups – 3 Signs your Technical Sellers Need Help

  1. Great post Ken. I could not agree more than when it comes to pitching technology, or anything for that matter, is is about pitching VALUE not features.

Leave a Reply to Kareem Cancel reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>