Versión en español aquí.
Hello people! Here again sitting in front of my computer doing one of the things I try to improve: writing.
Those
who know me know that I work in the world of IT pre-sales (presales,
sales engineer, etc.) which is something that I really like to do and
share. These
days I have been involved with interesting selection processes and one
of the things that caught my attention is the titles that the roles
currently have on the market.
In the selection processes I have found interesting roles, although some with bombastic titles, I imagine with the intention of
attracting the attention of the applicants. I am not going to dwell on
that, since I am not a specialist in recruitment, selection, head hunter
or anything similar.
I
would just like to get a little closer about
what, from my point of view, the roles (some) of pre-sales imply... from
the traditional one to the recent demands.
By the way, I'm taking some ideas from this post I made a while ago, in case you want to check it out (in spanish):
https://www.urgiles.info/2018/07/las-habilites-de-un-ingeniero-preventa.html
The Product Manager
The product manager's main responsibility is to know the commercial aspects of their product: licensing or subscription models, pricing, SKU, limitations, range of discounts (by volume, by amounts), EOS (end of sale), date, availability (stock), guarantees, evolution or roadmap, competition, as well as being the link to the outside (manufacturer), and to the inside (internal and external customers).
The above with the objective of being relevant, precise and effective in the positioning of your product. Nothing worse than failing a bid or losing business (or winning the business but losing money) because there was some erroneous consideration.
I will try to illustrate the above with my first big mistake in the world of pre-sales: we were about to close a large switch business for a very large multinational and they sent me a promotion: for every 3 switches, they gave me 4! That was a 25% discount in practice.
I did my calculations and applied the 4x3 relationship to the model I had already built. The order was for 40 switches so I only needed to buy 30, since the remaining 10 arrived with the promotion. Simple, right?
I happily communicated the good news to the sales team and they sent the new proposal to the client's purchasing area, yes, with a certain deadline... and we won the business.
Where was the mistake?
The 4x3 promotion eliminated the other discounts given by the manufacturer. That is, it was not a discount + promotion, it was one or the other. As you can understand, we gave a price that no one else could give, and that way we won the business... but we didn't make money, since that "detail" left a margin of less than 1%.
On
another occasion (this time it wasn't me) we had a particular problem
with certain equipment not working properly in certain specific
locations, and generating random errors without a clear pattern.
The problem: these devices were certified to operate up to a certain altitude above sea level (masl) and those geographical locations exceeded said altitude. Yes, the product manager must know or consult at all times the specifications documents (specs) of his/her product/s, including the masl they support.
The Pre-Sales Engineer
In my imagination, the pre-sales engineer is that hybrid that has a lot of technical knowledge but at the same time knows commercial issues. He is the one who has a technical background and has developed soft skills to listen, question (kindly) and propose. By definition it generates trust. He knows what he knows and what he doesn't.
You must have the ability to “read” your interlocutor, to listen, to ask pertinent questions; He knows how to speak and remain silent. You usually have a constant fight in your mind to avoid the urgency of responding technically (product view) and wait for the right moment to show value to the customer (business view).
Your strengths should be in greater technical depth and a broader focus because you must understand various technologies (including the competition) and find the most beneficial integration with the products or solutions that the client probably already has. It must show a medium and long-term vision, it must transmit security, trust and value.
Another anecdote: in a company where I worked as a pre-sales engineer a few years ago I had colleagues who were responsible for other lines of business (structured cabling, printing solutions, etc.) and one of our challenges was to be “sexy” for the customer. commercial team.
I needed salespeople to talk about our solutions in their interactions with customers.
How to do it? I did some things, but I want to highlight at this moment the confidence that I sought to convey to my teammates. They knew that they were going to have a well-structured proposal that would allow them to generate or increase their reputation with the client. And that, dear readers, is very valuable in long-term relationships. As they once told me: “The last thing I want is to sell a problem.”
In this role, interaction with the sales team is the norm. Depending on each organization, they even form teams (Core Team, Account Team, etc.) that are labeled in various ways, a very common one is “Trusted Advisor”.
In this interaction, everything usually happens: from the place where what the seller says is “holy word” to where the engineer has high influence in deciding whether or not to continue with a business. There is a lot of literature regarding this relationship… I can only say that the better you manage the relationship, the better the results will be. Ultimately, success or failure will affect both of you.
Finally, a pre-sales engineer must be able to explain complex topics with clear clarity.
Is it a very ambitious goal? Maybe.
But there is a trick to this: searching for or pursuing that goal will make the pre-sales engineer more knowledgeable and will prepare him/herself for the inevitable and sometimes rude support.
The Solutions Architect
This role and its variations are booming in IT publishing today. A quick search online gives me an idea of what is considered an engineer and architect in the construction world: the engineer has a more structural approach, while the architect has a more visual approach. Excuse the briefness.
For me, the main difference between a Presales Engineer and a Solutions Architect is that the latter has the characteristics of the former but with a broader focus and greater experience. Know less about the product and more about the business. He focuses less on his company and thinks more about the customer. He thinks about building from industry frameworks, and is frequently updated with “Best Practices” from manufacturers.
It has the ability to go up and down in the level of detail. His experience and seniority allow him to handle objections at the corporate level, even managing financial objections. Terms like TCO, ROI are no strangers to you.
Within the organization, he is considered a valuable voice in the evaluation of new solutions or products, or even proposes evaluating new technologies. His curious and critical nature forces him to constantly update himself and learn about industry trends, which could be relevant to his clients.
Although I surely fall short of the definition, since in each area (security, infrastructure, networking, business, etc.) there may be particular requirements or characteristics for an architect, I hope I have summarized the main characteristics that I see in an architect.
And which role is better?
I
think that question is not relevant. Continuing with the construction
example, it is like asking if it is better to be an architect, engineer
or interior decorator. If I must answer, my answer would be: The best
role is the one in which you are the best (or very good at what you do).
Let's see how interesting that got: we are talking about pre-sales and we have mentioned words like “Manager”, “Engineer” and now “Architect”. Are we perhaps building something?
Really if. IT professionals are responsible in their different roles and levels for ensuring that their organizations are functioning well (stable, available and secure).
As I heard from a CEO of a very large banking entity in Latin America:
“We are a technology company that provides financial services.”
Thank you for reading. And you, what do you think?
