This is your other job

As a sales engineer, your primary job is to help your sales team achieve their goals. Usually, this means helping the team to hit a revenue target but –depending on the size of your company– it could also entail enabling partners to learn your product or ensuring that customers experience the results they expect.The first word in your job title is “sales” so the goals of the sales team are your goals as well, regardless of where you sit on the org chart.

All of that being said, as a sales engineer you have another job, one that often doesn’t get discussed…

Because you sit at the point of contact between your product and prospective customers, a key function of any good sales engineer is to drive customer and market feedback into the product development process. In short, you know where the gaps are, you know what customers truly care about and you are uniquely positioned to provide feedback that makes your product better.

Whose job is it?

You already have a lot on your plate, so you might be wondering… Isn’t gathering customer feedback the role of the product management team? Yes, it definitely is and product management is exactly where you should direct your feedback. But the product management team cannot get the same level of access to the same kind of customers as you. Let’s dive into this a bit…

When product managers go looking for input regarding what they should add to their products, they usually turn first to your existing customers. That’s smart because existing customers often have requirements similar to prospective customer, plus in a subscription based business you must always strive to keep your existing customers happy with new feature or risk them leaving when their contract ends.

All of that being said, only talking to existing customers creates a giant blind spot, one that sales engineers are best positioned to fix.

Only getting feedback from current customer is a form of selection bias, which creates a false impression of the larger market and the needs of people and organizations who are not your customers. The product teams needs to understand the requirements of potential customers who do not buy your product; this is information that –by definition– cannot be found among your current customer base. Without this data, the product team is at risk of creating a narrow product that only meets the needs of early adopters.

Unlike the product manager you, the sales engineer, have access to two type of prospects who hold the key to your company growing it’s market and appealing to new types of customers. They are…

1. Prospective customers who you disqualified after discovery. These customers failed to meet the definition of a qualified opportunity for technical reasons. For example, they might require that your service runs on Microsoft Azure but today it is only available on AWS.
   
   As a sales engineer one of your jobs is to technically qualify opportunities. This usually means talking to prospective customers and reading RFPs. Along the way you will find some opportunities where your current product is not a good fit. Perhaps your product lacks support for an up and coming database technology or maybe you’ve had inquiries from government agencies but you’ve learned that –by law– they require accessibility features not present in your product. These are they types of requirements that your product management team can easily miss.
   
   (I’ve blogged about the SE’s role in disqualifying opportunities… read more here.)
   
   
2. Prospective customer who disqualified you at some point during the sales cycle. These can be more challenging to document because prospects do not always share why they didn’t pick your product and the reasons might be political, not technical. Nonetheless, when you do lose a deal –and it happens it everyone– the best thing you can do to salvage the time and energy you’ve invested is to gather all the information you can to (a) improve your sales process and (b) improve your product.
   

Feedback, with a price tag

It’s your job as a sales engineer to capture the technical and functional requirements you could not fulfill and channel them into the product management process. When possible, you should also try to quantify the opportunity size or revenue potential of the business you are missing.

For example… “We disqualified three opportunities last quarter because we do not support Android. The average size of each opportunity was roughly $200,000.” That’s the sort of feedback your product team needs.

The process for submitting this feedback will vary from company to company. At a startup it will be direct and informal. At a large company there may a few layers of organizational cruft between sales engineers and product management but there also should be a formal process for submitting product feedback.

When I join a new company, one of the questions I’ve learned to ask is “What’s the best method for channeling feedback into the product team?” If you are an SE manager, this is a good topic to review with your team and to discuss with new hires… for all of the reasons mentioned above their input into the product development process is highly valuable.