Las Múltiples Caras de un Ingeniero de Preventa. Parte 3

(continuamos con la tercera parte de este serial sobre Preventas. Ahora le toca el turno a describir la categoría de producto)

2.1 Product Category

The first step is, obviously, having sound technical skills, both from a development and from a systems standpoint. Whatever product one might be selling, it will surely have one or more dependencies with the operating system, hardware, virtual machines, or whatever. Being able to struggle with AIX, Solaris or HP-UX, or create some code around the middleware product is sometimes nice to have, sometimes critical to handle.

The second step is to master the product portfolio the company is selling. As discussed above, this ability does not mean to just understand it or do the basic things, but to act as the best possible customer we might have. This means being able to install, configure and deploy the product under several circumstances (it also means being able to explain everything in a clear way, but let's defer this discussion to another category). Mrs. SE needs to be in control when a customer asks some tricky question, some "what if?" by either solving it or by using its inner knowledge base to find out the solution in the best, in the most efficient way possible.

Figure 2. Product Skills

In big product companies, where Sales Engineers are specialized in one or two tools, it is expected that they have at least a "sales-level" knowledge of the complete product portfolio, so they can detect opportunities when working with customers.

But, as you could expect, knowing about the product is not enough. A middleware product interacts with a variety of tools and standards and other products in an enterprise ecosystem. Knowing which tools there are for each related product category and being able to explain the best way all of them can interact to solve the problem of the customer is surely one of the main paths to success from a technical standpoint. A Sales Engineer has sometimes been defined as an Enterprise Architect with a sales approach, and this is one of the areas where both roles relate in the broadest way. It is very difficult to find a true enterprise architect with high communication skills and the willingness to go out and sell. But if you find it, don't ever let him go (does she want too much money, maybe even more than what you currently earn in the company? If you understand spanish, please read this other post from my blog - I have; even if you don't, just click on the first link of the post).

One additional area that I consider very important, though usually difficult to accomplish, is the ability to master not only our products and our ecosystem's products, but also our competitors'. It's tough because (1) we don't usually get access to all of those products, so the effort here is usually quite biased; (2) if it's already a challenge to master our own product...; (3) Mrs. SE might like it better than ours, and leave ;) Competitive Intelligence is itself a very complex area, but this has always worked for me:
  • Have a clear Competitive Landscape (where do my competitors fit in my own component architecture?). Start there. This landscape might have been created by your team, by Product Management or by Marketing. This forces you to understand your products, how they fit in different use cases, and how other tools can do what you do in other ways. This is an enlightening task, because it shows you, no matter how mature your product category is, that there are always a few workarounds in terms of using other products from other categories. While a deeper landscape belong more to the environment category, explained below, from a product perspective it is also required to have detailed information about how each product solves specific issues.
  • Start small. If it were for your Sales colleagues, you would need detailed comparative analysis and battlecards from day 1. But that's not the case. So start the simplest way possible: breadth approach. Find all public information from all of your possible competitors as you find them. Create "mini-reports" which are basically copy-and-paste parts of the things you found, plus some initial conclusions and comments.
  • Be critical. Everyone in the jungle might be a competitor... but should I worry about them all? Be critical, take the risk. Keep watch of small companies which might mean something in a few months, but don't spend all your resources tracking them down. Is IBM release a new tool? That's important, but... will it be move fast or slow? Those are decissions to take.

Now the question is, how to achieve this? I guess that, if I knew this 100%, I would be selling courses and consulting to many other companies, but this is my take, and this is how we're doing it.
  • Hire people with a very good technical background. This is the minimum. Real-world companies have *no time* to train people on basics such as Java, good software engineering, good testing background, and the like. How you do this is something for another article (or book), but in the meantime, I recommend reading Joel Spolsky's Smart and Get Things Done.
  • Have a predefined formal training kit. Formal does not mean "one teacher for three weeks". It might simply mean a wiki page with a set of mandatory and optional documents to read, demos to install, and so on. But the most important thing, mixing self-training with one-on-one meetings with other members of the team, plus frequent evaluations (again, not a test, but checkings to see that everything goes well enough). Another thing we do here is to have weekly or biweekly meetings to discuss different aspects of the product, ecosystem, and so on. These meetings should be clearly focused towards "learning what there is". There can be other sessions for product enhancements and the like. Don't mix both, you could spend the whole session discussing about better ways to do X, instead of learning how you can do it now!!!
  • Let communication lines open. Let the team know that teamwork and communication is key. Nobody should feel weird for asking a question, requesting a meeting with a colleague, ... And be the first one to be honest about the team's expectations. If you "sell" openness, be open yourself.

The next post of this series will describe the Environment category, very related to this one.


Popular Posts