I was some form of quota-carrying B2B (business to business) sales engineer for about 12 years, and have worked closely with these field engineers ever since moving into product management. There are many paths to success in the field, and I appreciate the clarity of a compensation plan: you’re either making sales or not. So, let’s look at how the SE helps to make those sales happen!
The SE can do a wider or narrower range of tasks in different companies, but the center where everyone’s definitions overlap is demonstrations of the product. The SE shows the product working. The demo is a meeting that needs to end with the customer feeling that the product would work for their use cases, and that it would be at least as good or hopefully better than what they currently have. As in any human endeavor, there’s a spectrum of creativity in how an SE does this, changing approaches based on who they’re talking to and how their day is going. Whatever you want to try might be okay, as long as it works for making sales and doesn’t break any rules. That said, it’s always interesting to look at commonalities and differences in the SE organizations that I’ve observed.
Extreme position number one is the scripted demo from a tightly prepared environment. Every step is planned to catch a prospect’s attention with a compelling story. Follow the script, and you’ll do okay. An SE that has been trained to demo in this way can be easily spotted by asking them a question: they’re going to table it. “That’s a great question, let’s circle back to it after I complete this material.” As always, there is a reason and that reason is immaturity. It might be that the SE is green, and will be lost if they leave the script path. It might also be that the product is green, and it’s highly likely to break if they leave the script path. Tabling the question helps the SE stay on target.
The other extreme position is the maverick demo: an SE who uses their own instance and can demonstrate anything the product does to anyone who asks. Of course they’ll answer questions instead of tabling them… in fact they may not even remember a script to follow. Their failure mode is going down interesting rat holes, which their account manager might need to fetch them out of. Obviously this is a mature SE, but be careful about assuming that the product is also mature; they might just be adept at talking past its issues.
There are some interesting hot spots between those extremes, and as a company grows and improves its product market fit, its sales engineers may struggle to move from one hot spot to another. A good midpoint to consider is the multi-script demo environment. This is still a prepared system, but it has moved the scripted story from a simple fairy tale to a choose-your-own-adventure. If it’s done well, most start and end screens will have some kind of a hook where the SE can pick up the thread for another story or get back on track for the story they were telling. This lets a script-following SE “fake it til they make it” as a fully off-book SE.
While I prefer off-book, it’s a set of skills that is really built and honed by performing tasks that aren’t as directly attached to the initial sale as the demo. In other words, you get to be a good off-book SE by using the product, and that’s typically because you’re helping to figure out things that aren’t in the script. Maybe that’s purely because you’re interested, or maybe it’s because you’re also doing some support, or maybe both. There’s an argument to make for scripted SEs as being better for the goal. They’re more purely focused on the deal and spending more of their hours performing sales-oriented tasks. This can be attractive when the company’s financial model separates SEs (under COGS, or cost of goods sold) from other field engineers such as TAMs, CSMs, et cetera.
Monkeynoodle.Org 