[catgary]

> Someone who is good at sales should not have to reject clients because something is difficult.

What does that even mean, honestly? Because I would argue that a salesperson who doesn’t accurately represent the product or service they’re selling is a conman, and I think there is a fair bit of established law on the subject.

[A4ET8a8uTh0_v2]

Ideally, skillsets should align. If a person sells well, but the company can't deliver on that sale, something clearly is amiss. It could be that the salesguy overpromised, executives saw what they wanted to see, or that the delivering team failed.

FWIW, reading the article on that app, it did not sound particular awe-inspiring ( though kinda useful ) so it does not sound like level of technical challenge was the issue here.

[catgary]

But what does “sell well” mean, because once again, making sales is significantly easier when you’re unburdened by the truth. Are you saying it’s not the salesman’s fault that his product is crap so he needs to lie to make sales?

[A4ET8a8uTh0_v2]

You do have a point. I think most of us would agree that if salesman tries to claim that the app teleports you, breaks laws of thermodynamics or can compress files to negative 1, there is a problem that may need to be addressed by court.

On the other hand, I think most reasonable people would agree that a lot of problems facing most businesses are exactly that dramatic. They might not be easy and the customer may not even know exactly what they want, which adds a level of spice into the mix, but are not in the impossible category.

I reiterate my previous position that the salesman should know what his team can actually do. Then again, so should the customer. Some yonks ago, we had a team present their product to our executives. Because of the nature of the product, a lot of it could ( had to ) be customized. The executives saw pretty charts of a potential future product, but somehow failed to understand the effort needed to get to that point since those pretty charts relied on a whole bunch of little things happening in the background. And I think we would agree that data visualization can be fun, challenging and interesting, but it is not exactly rocket science.

Almost inevitably, after a lot of delays and aggravation, the product rolled out with quarter of the promised features and no charts ( well, no reports, charts were technically there ). Whose fault is that? Was it salesmen, because they promised what genuinely could be?

Sadly, there is a lot of blame to go around, and while I saw some train wrecks in my career, I think my biggest pet peeve now is clear lack of preparation. The sheer amount of projects that had either no requirements or ridiculously broad requirements is enough to make me wonder how anything gets done.

Hell, two projects ago, I was forced to work with a vendor with no agreed requirements in place ( and it wasn't some data recording app like in the article, but enterprise level idiocy ). And when things inevitably went sideways, because where can they possibly go if there is no plan for something this big, I got to spend every god damn day in daily 'war room' going over minute details effectively doing the scoping that should have been waaaaaaay back when.