Las Múltiples Caras de un Ingeniero de Preventa. Parte 1
(En las siguientes semanas voy a ir publicando por partes un artículo que he estado escribiendo como "autoayuda" para entender mejor la responsabilidad de un ingeniero de preventa en una empresa de producto.
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:
- "So absolutely, Mr. CEO-of-a-huge-enterprise", ", said Mrs. SE, "You were asking me about the best value our product can bring to your company. And for me, it's clearly our capability for implementing Java Reflection in a Spring framework and invoke it through Javascript and Erlang, without having using JNI!!!!". And, she added, "ain't that awesome, fantastic and -don't ever forget this- disruptively innovative???".
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.
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).
THE MULTIPLE FACES OF A SALES ENGINEER
One of the challenges in middleware sales and, I guess, in most complex sales either in software or in any other product category, is that, let's be honest, most sales execs do not have much idea on what the product they're selling actually does, let alone how the nuts and bolts of how it works at all. And, in the fourth day, God created the Sales Engineer, and He saw it was a good thing. 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:
- "So absolutely, Mr. CEO-of-a-huge-enterprise", ", said Mrs. SE, "You were asking me about the best value our product can bring to your company. And for me, it's clearly our capability for implementing Java Reflection in a Spring framework and invoke it through Javascript and Erlang, without having using JNI!!!!". And, she added, "ain't that awesome, fantastic and -don't ever forget this- disruptively innovative???".
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.
Comments