Las Múltiples Caras de un Ingeniero de Preventa. Parte 1
Obviamente, no pretendo "sentar cátedra", sino organizar lo que experimento y preveo como facetas de este rol clave en ventas técnicas complejas.
¡Ah! Y está en inglés :( Pero espero que no sea un problema para nadie, y si es así que me lo diga e intento resumirlo en algún comentario).
A Sales Engineer is seen in some places as the "Robin" in the "Batman & Robin" couple (guess who Batman is): a junior sales coming from the technical barracks, who wants to become a Sales Exec in the future, and who sees SE as an intermediate step towards the final goal: the brand-new Ferrari.
But the truth, as always, is much more complex. As the role of an SE.
Selling middleware is a tough issue. When the product representative visits a prospect, she must be aware of several things, being the most basic ones: am I talking to IT folks, who will probably hate having to install, deploy and maintain yet another piece of software to their already busy agenda? Am I talking to a business user who will only listen to solutions (as Theodore Levitt said "People don’t want to buy a quarter-inch drill. They want a quarter-inch hole!"). I will not go into details, that's subject for another story. But the point of this is that, regardless of the audience, selling middleware means going deep into technology.
This is where one would think the role of an SE is. And it actually is one of the most important ones. A Sales Engineer must be able to walk the different leaders of the company, from CEOs to junior tech guys through the value of the product. That means knowing a lot about it (OK, maybe not as much as a Product Engineer would, but almost). But, just from this small example you can see the difficulty of this:
Of course, this is an exaggeration, but I've seen and done things close to this (which would call for an SE anti-pattern, which should be probably copyrighted by Robert Riefhstal).
The reality is that Mrs. SE is smarter than this, being able to manage different communication levels depending on who she is talking to. "Value propositions" and "ROI" to the CEO, "Java and Spring" to the junior tech, and all the intermediate slang for the intermediate people. She and the Sales exec get to meet with THE enterprise architect, the guy or girl who might act as gatekeeper of the account. And then, of course, the enterprise architect starts asking about things such as how your product integrates with this or that other product, whether the product follows this or that strategic methodology, or asks specific details about who your competitors are. And you find that, most of the times, the Sales Exec will look at Mrs. SE expecting her to answer right away. The best of times, the Sales Exec will start answering the question, but the Enterprise Architect will ask more and more, and then (deja vu is coming), the Sales Exec will look at Mrs. SE expecting her to answer right away.
As you can see, a Sales Engineer must master many different technical situations. But I could go on with a myriad of examples where SEs are expected to do much more than this. In some companies, it is understood that a Sales Exec opens the sales process, but the Sales Engineer finishes it. The discussion is where the Sales Engineer starts owning the process.
In the remainder of this article, I will discuss a categorization of the roles a Sales Engineer has in an organization that wants to succesfully sell complex products. I will focus on middleware software, though I believe many of what I say here will have the same impact and meaning in other product categories, even outside of the software world.