Engineers are in a better position to understand what the customer wants and needs. Salespeople are there to sell their product, and fundamentally don't need to understand what the customer wants, or needs.
Give a good salesperson a handwavy outline of something to sell, and they will sell it. They don't need technical accuracy for success. Yes, this is bad for customers, and makes life harder, and results in ridiculous, counterproductive, infuriating situations for IT staff, engineers, and other people who have to deal with the technical realities of every day business.
A salesperson can just mash psychological buttons in manager's brains, and they'll make the sale. The consumer, in enterprise level markets, is hardly ever the team or individual in charge of operating the technology. The consumer is the manager, or managerial team, looking to check boxes and shuffle numbers and spend $X on Y department, for which they get rewarded for a wide array of arbitrary outcomes, almost none of which have anything to do with the practical impact of the product in question on the people who end up most affected by the purchase.
If an engineer with a solid understanding of the product being sold is in charge, he's in the best place to rein in the sales and marketing teams, and to direct development based on customer reality. This probably results in lower profits, overall, but a better product, and a better reputation in the long run.
> Engineers are in a better position to understand what the customer wants and needs. Salespeople are there to sell their product, and fundamentally don't need to understand what the customer wants, or needs.
Why do you say that? My gut reaction is that the opposite is true. Salespeople must understand their customers' wants and needs in order to effectively sell! Engineers are generally a step or two removed from the customers. This may be an unpopular take on HN but I'd wager the people who spend time directly with the customers have a better chance at understanding what they want. Taken a step further, customer support probably has the best understanding of their markets' needs!
I'd go as far as to say that the role doesn't matter, it's the attitude of the individual.
I've worked with a few developers AND sales people that didn't give a hoot about what their customers thought. In the case of Sales, they only cared about making their targets. In the case of the devs that didn't care, they spent 99% of their time doing silly (in my opinion) arguments about frameworks, design patterns, and whitespace and formatting rules in CI. Not that things like design patterns are inherently silly. But if they don't result in a better customer experience (via more stable and maintainable software, for example), then it's a waste of time.
I'm a developer by trade but have ALWAYS had an attitude of "it only matters if it's useful to the user" – and have butted heads sometimes with developers on which features to prioritize.
> Taken a step further, customer support probably has the best understanding of their markets' needs!
People working in customer support, from my experience, sort of see the anti-survivorship bias working in action. Not many people call up to say how well something works. I would agree with you though on good Salespeople (ones that do try to understand what customers need and all that, not necessarily ones that sell the most) knowing what the customer wants/needs.
> People working in customer support, from my experience, sort of see the anti-survivorship bias working in action.
I used to see this all the time at an old job where my team worked on open source client libraries for using the main product that our company sold. A decent number people seemed to think that an increasing number of tickets being filed against one of the libraries was a sign that users weren't happy with it, but it always seemed obvious to me that you couldn't easily conclude that; you might have 99 happy users with no issues for every 1 unhappy user who filed a ticket, or you might have literally only unhappy users and nobody without issues. On the other hand, getting literally zero tickets might mean that you have plenty of happy users, or it might mean you have basically no users at all.
I'd often talk to younger engineers who were interning on the team or recently joined full-time about how this dynamic informed how I approached my job; usually, we'd only hear from users who had issues, so the "goal" in some ways to was to make the software so good that you'd never hear from them. If you did hear from a user, that was a valuable opportunity where you might learn something you could do in the future to make things better the first time.
> so the "goal" in some ways to was to make the software so good that you'd never hear from them.
Yes. There are people who talk about product experiences that delight or whatever. Nah, the ultimate experience is one that's so flawless, so frictionless that it's completely forgettable. The user doesn't want to remember anything. They have a problem a/o need, the goal is to make it disappear w/out a trace.
In my experience it's more like customer-facing people, sales and support, get to know the customers needs and pain points, while good technical people knows the limitations and possibilities of the systems involved. By working together the sum can be greater than the parts.
As a dev I strive to talk to sales and support for this reason. It's not seldom I can do a small change that drastically improves the user experience for one or more clients, be it existing or potential.
Too many developers only focus on the specifications, and don’t try to understand the specifications by trying to understand the user. Instead they complain that product owners, product managers, designers, or analysts fail to give the proper specifications. I don’t see many developers really trying to understand their users. But this may be different per domain…
> the people who spend time directly with the customers
Unless engineers spend time directly with customers, something is broken in the organization to begin with. If salespeople and customers dream up solutions and then hand the task to produce this solution over to engineers, then that business is frankly doomed.
Your gut reaction is something salespeople play off of. I've been in the sales position before, handling the people in charge of making the purchasing decision, selling them bells and whistles they absolutely didn't need, but giving them the emotional satisfaction of a "successful" transaction, leaving with a sense of victory, that translated into a strong relationship and many years of repeat sales, with incremental upselling over time.
Good sales, ethical sales, aren't parasitic. A vast majority of sales in todays markets, especially in enterprise markets, are parasitic. The salespeople are interchangeable. The ones that make the most money are the ones most willing to be parasitic. The sales script is targeted and tailored to the intended audience, which in most large companies, is several degrees of separation from the eventual user of the product. You don't need to know what the end user needs. You need to know what the person in charge of buying wants, and that's ultimately emotional validation, hope, a sense of "innovating", a feeling of victory in pricing negotiations, being respected and treated well, and so forth. You can run them through the wringer with sales engineers and migrations after the contract is signed, and even if the end user and the product engineers recognize that your product is the wrong tool for the job, that won't matter if the buying manager is emotionally satisfied with the transaction. People will bend over backwards to justify what they know is "right."
A salesperson CEO will make more money, but will make the world a shittier place, because they're the cotton candy of management. They'll burn credibility and reputation in exchange for profit, kick the can down the road for someone else to clean up the mess later.
Sure, in a healthy, respectable, ethical, functional company, you'd be right, and the CEO would also be the best salesperson for the product, because they'd know it, and the customers, inside and out, and be able to explain and demonstrate exactly what was necessary and why, and justify all the costs and benefits.
This is a world that has Goodharted the measure of success - profit - and empowered people in the execution of shitty behavior. The market rewards higher profits and punishes "failures," often completely out of sync with quality and merit.
We don't live in a good world - companies that behave like you describe would be wonderful. We live in a thoroughly enshittified world, and a whole lot of people "earning" a whole lot of money are in between you and any meaningful change.
From Apple and Microsoft on down, companies want endless, infinitely increasing returns year over year, and they will do anything that isn't explicitly illegal to get it. They'll also do illegal things if the cost of getting caught is less than the profit earned. Alignment with end user needs, benefit to the consumer - these are far down the list of things meaningful to the systems and people making decisions on how money is spent. The job of a salesperson is to understand that system, and exploit it for the benefit of their company.
Not sure if I agree with an engineer inherently being better here.
The ideal case is having leadership who uses the product, or at least is willing to walk in the shoes of an end-user. Plenty of engineers do not do this either.
Anecdotally, having worked at multiple small-medium companies with a variety of leadership backgrounds, the worst have been sales background. Engineering backgrounds have ranged from OK to great.
- I knew nothing about what the healthcare industry needed in the three SaaS companies I worked for including software for health care workers dealing with special needs kids
- the various “enterprises” mostly in the edtech or state and local government space in consulting.
No, the person running the company has expertise running companies. Customer understanding lies with designers, analysts, product owners, product management, but also sales: what is the pain we’re addressing, how can ensure the customers really understands the consequences of not addressing the pain, how can we ensure the customer sees our product is the best to address their pain.
> Engineers are in a better position to understand what the customer wants and needs. Salespeople are there to sell their product, and fundamentally don't need to understand what the customer wants, or needs.
There's no reason to believe an engineer would understand the customer needs more than a salesperson. I know a lot of engineers who would do literally anything to avoid dealing with a real customer. At the companies I've worked for, engineers don't even talk to customers if there isn't a specific, technical issue they need to be there for. Meanwhile, salespeople actually talk to customers, probably more than anyone except support.
> Engineers are in a better position to understand what the customer wants and needs. Salespeople are there to sell their product, and fundamentally don't need to understand what the customer wants, or needs.
I think you have that backwards. Sales people absolutely need to understand what they customer wants and needs, or they won't buy it. Engineers just know what they want to build because it's what they want.
But really, Product Managers are the ones who are in the best position to figure it out. They get input from sales, customer service, and engineering, and produce competitive research, and then prioritize from there.
> Engineers are in a better position to understand what the customer wants and needs.
I assume you are an engineer? I am too, not judging :-).
Everybody tends to think that they are in a better position to know how the product should look like, I think it's a normal bias.
Not that salespeople are better. I hate the direction Sonos chose. Just saying that engineers are not always the best at understanding what customers want and need (if you asked me, I would say that everybody needs Yubikeys, and yet people actively fight to keep their right to reuse the same weak password everywhere :-) ).
In all disciplines you find more not so brilliant people than truly brilliant people. I am a software engineer, but it happens that I cannot understand how our UX professionals have designed our product's UI. Or if I understand it I find it awkward. Now you could say that's because I am so much below average, that I am a hopeless case... But we get customer reports that they are more confused than I am. So having UX people is not silver bullet.
I think the solid understanding of the product and its users is the important part, not whether you’re an engineer or not. That understanding (or lack thereof) can and does transcend role.
Give a good salesperson a handwavy outline of something to sell, and they will sell it. They don't need technical accuracy for success. Yes, this is bad for customers, and makes life harder, and results in ridiculous, counterproductive, infuriating situations for IT staff, engineers, and other people who have to deal with the technical realities of every day business.
A salesperson can just mash psychological buttons in manager's brains, and they'll make the sale. The consumer, in enterprise level markets, is hardly ever the team or individual in charge of operating the technology. The consumer is the manager, or managerial team, looking to check boxes and shuffle numbers and spend $X on Y department, for which they get rewarded for a wide array of arbitrary outcomes, almost none of which have anything to do with the practical impact of the product in question on the people who end up most affected by the purchase.
If an engineer with a solid understanding of the product being sold is in charge, he's in the best place to rein in the sales and marketing teams, and to direct development based on customer reality. This probably results in lower profits, overall, but a better product, and a better reputation in the long run.