Yesterday morning over breakfast, I was reading the excellent article, Mastering Assumption Testing in Product Management, and I was struck more forcefully by something that had been bouncing around in my head on-and-off for the past three years.
(I had previously linked to the above article on the basis of skimming it before saving it to read later. Now I’ve read it, I’d double down on my suggestion it’s important reading no matter what your field of expertise.)
As you might have guessed by the title of this post, I’m going to suggest that pre-sales engineering and product management have a lot in common. A lot. I don’t say this just because I made the transition from pre-sales to product management, I say this because I made the transition from pre-sales to product management while being someone who constantly fights imposter-syndrome and has found the only weapon to avoid crippling doubt is to constantly self-analyse. I.e,. I’ve spent a lot of time analysing my journey over the past three years.
I’ll go so far as to say that pre-sales engineering and product management are so related to each other that they’re basically two sides of the same coin. This solidified for me when reading the above article for the simple reason: everything it was talking about was from the perspective of product management, and everything it was talking about could have been flipped around and been a story about how pre-sales engineering analyses and develops rapport with customers.
Let me explain why.
What are the goals of the pre-sales engineer?
Know the product
The pre-sales engineer doesn’t need to know the product to the same level as say, the product engineering architect, but having good, deep knowledge is fundamental for ensuring if and how the product is going to be a fit for the customer they’re talking to. They don’t have to be an expert in everything, but they need a broad general expertise coupled with deep technical expertise in one or more facets of the product. (Ideally, having a broad general expertise in the conceptual need filled by the product is also important.)
The broad general expertise should enable answering any basic questions about the product. That deep technical expertise means there should be at least one or more areas of the product where the pre-sales engineer can dive deep and demonstrably establish trust as someone who knows what they’re talking about.
Know the customer’s technical needs
Now, the pre-sales engineer needs to take that technical product expertise and map it to the technical needs of the customer. Unless your product is a unicorn, there are likely at least five or more other products out there from other companies that can theoretically do the same thing as your product. In some places better. In some places as good. In some places not so good.
Emotion and personal preference aside (and these are challenging sales considerations), there are two key attributes that allow you to position your product compared to competitor products: the technical needs of the customer, and the business needs of the customer.
So if you’re going to position why your product should be selected over vendor W’s product, you need to understand technically why the product is a good fit for the customer. Not just from the perspective of “our product does A, B and C”, but “you’re doing X, and feature A will help you because of _____, ______ and _____”, and so on.
Know the customer’s business needs
Beyond the technical needs of a customer are its business needs. Now, it’s tempting to assume that the business needs really refer to the financial needs – how to understand what the customer is willing to pay. And there’s no doubt that financial needs are part of the business needs of a customer. But they’re not the only aspects. While not an exhaustive list by any means, other examples of the business needs of a customer include:
- Who are the competitors of the customer?
- What are the market pressures the customer is facing?
- How has the customer been performing compared to previous years and market expectations?
In addition to any financial considerations that can help address the above (which is where the account manager will really shine), understanding the customer technical needs and the product’s capabilities can allow the pre-sales engineer to build a compelling story on how the product will help them with all those areas.
Persuasively demonstrate the need of the product with data and insights
So once the pre-sales engineer knows all the above, they have to put it all together. Perhaps a formal proposal will be written by a bid team, or the account manager, but at some point a pre-sales engineer is going to have to piece together all those details and demonstrate to the customer why their technical and business needs are going to be best solved by the product (or solution, obviously) that they’re dealing.
And demonstrate here is a loaded term. I don’t mean that this has to be done in the context of a product demonstration. I mean walking the walk and talking the talk, the pre-sales engineer has to embody the belief and proof for the customer that the product is right for them.
Persuasively demonstrate to growth needs of the product back to the product manager
And finally, the pre-sales engineer is the first line of interface between the average customer and the product manager. The customer is going to use the product and see gaps or areas they’d like changed. Likewise, from working with multiple customers (or at least, multiple people within the same customer), the pre-sales engineer will have their own views about how the product can be adapted to better suit the needs of their customer or customers.
The pre-sales engineer then should understand the language of the business they work for enough to communicate those needs back to the product management team. And not just repeat details verbatim (though that can certainly help establish nuance), but to persuade the product manager of the need based on the data and feedback the company needs to take customer needs and convert them into product goals.
The pre-sales engineer needs to be a filter – an interpreter.
What are the goals of the product manager?
Know the product
Some product managers are responsible for entire products, and others are responsible for features in one or more products. It actually doesn’t really matter which we’re referring to here because – no surprises – the product manager needs to understand both.
At the whole-of-product layer, the product manager needs to have that broad understanding of the product. They should be able to describe where it fits in the market and what it does comparatively to other products in the market and therefore understand how it is applicable to target customers of the business.
At the feature level, the product manager needs to get more deeply involved in the product; they need that deeper awareness of the feature or features they deal with and be able to demonstrate a level of understanding approaching the subject matter experts in the business.
Know customer technical needs
At this point we shift from customer as a singular to customer as a multiple. The product manager needs to be across the technical needs of as many customers as possible. Some of that data will come from talking to customers directly, other data will come from talking to people in the field, other data from market analysts and so on. But regardless of where the data comes from, a product manager should have a good idea of the sorts of the technical needs their customers need to solve.
Know customer business needs
The product manager certainly needs to know business needs – but here the customer expands even more broadly than before. When it came to customer technical needs, it’s about understanding technically what customers need to do across as many customers as possible.
When it comes to understanding business needs, the notion of customer expands even further – not just to the customers of the business, but the customers within the business. In other words: how can the product fulfil the business needs of customers while also fulfilling the needs of the business as well? Even better, what can be done to deliver a product that synergistically meets those different business needs?
Persuasively demonstrate the growth needs of the product with data and insights
Knitting those details together – knowledge of the product, knowledge of how customers technically need the product, and knowledge of how both the business and the customers of the business can benefit from the product, the product manager then has to demonstrate the growth needs of the product that will bring benefit. To justify that growth, there needs to be data and insights (from customers, the market, and the business itself) to enable confidence that the intended growth is the right growth.
Persuasively demonstrate the applicability of the product to the field
And to wrap it up, that communication from the pre-sales engineer to the product manager isn’t just one-way. Likewise, the product manager needs to be an interface from business back into the field. Of course, that’s more than just pre-sales, but the interface to pre-sales is important since it’s the pre-sales engineering teams that’ll absorb the functional and non-functional use-cases of the product(s) and then start the whole process again with their customers.
So, what’s the difference?
It might be argued that the difference between pre-sales engineering and product management is the micro- to macroscopic level. The pre-sales engineer approaches their work from the point of view of one or more specific customers they’re working with (or aligned to, depending on how pre-sales departments work in your organisation); they take a comparatively bottom-up approach where they’re looking at the product (or products) already available to customers and mapping out how those products can help the businesses they’re working with.
A product manager effectively has to do all of the same things, but from the other direction: they’re looking at the big-picture view of how a product or a feature will enable as many customers as possible to do what they need to, then helping to drive the build and delivery of that to the field.
What are the lessons?
Let’s start with the obvious lesson – a lot of pre-sales engineers I know work on the basis that the logical career progression when you’ve had enough of pre-sales is to move into account management. And certainly for some people, that is a great career progression. But not for everyone. Likewise, the other seemingly logical career progression of moving into management isn’t for everyone, either. So I want to humbly suggest if you’re feeling a little unsure of where to take your career once you reach a certain point in pre-sales, don’t discount the idea of product management – you may very well surprise yourself with what you can bring to the table.
The other major lesson is the need for close synergy and alignment between pre-sales and product management. Both act as interfaces for the business from different endpoints and scope, and there’s a great deal of value to be made from those relationships. That synergy shouldn’t be too difficult to achieve because the roles have so very much in common with one another. It’s not just a bidirectional synergy between product management and pre-sales though; it’s going to enhance the customer experience, and it’s going to enhance the business experience, too. In other words, it’s not just about the benefits to the people (though the benefits to be had there alone make it worthwhile), it’s also about the benefits to whom those people represent. When that relationship is built out properly it’s not a win/win, it’s a win/win/win/win.
Pre-sales and product management: the overlap and the benefits of that overlap are substantial.