5 ms·

I would recommend against selling ahead of the Dev team. Sales is not research, and if you have effective sales people you will find that they can and will unin

I would recommend against selling ahead of the Dev team. Sales is not research, and if you have effective sales people you will find that they can and will unintentionally sell vapor that cannot be delivered. Customers don’t generally buy features and specs, they buy hopes and feelings. It’s not the sales team’s fault, but it’s easy to successfully sell hopes and feelings and then still not know what the dev team is supposed to be building.

magicalhippo 5y ago
> [If] you have effective sales people you will find that they can and will unintentionally sell vapor that cannot be delivered. This can happen even if the sales people does not mean to sell vapor. At least in my experience, they seldom have the domain or program knowledge to pick up on nuances in the client's question, leading them to think they correctly answer "yes our program supports that" while in fact the program does not support exactly that. As a dev I'm not often involved in sales meetings, but every time I have been in a sales meeting I've averted some form of vapor. The sad part is that most of the times the client is fine with us not having the exact functionality they ask for, but understandably get upset when they only find out about this post-sale.
- acwan93 5y ago
  Is this why some orgs have "sales engineers?" People who can pick up the nuances of a client's question whether a company can actually do feature X?
  - karmakaze 5y ago
    I got in 'trouble' a few times by giving alpha copies of a product in development to the sales engineers and when the customer saw particular new features wanted them and not any version without it. The trouble was caused when these events happened around release dates which back in the day of golden-mastered shrink-wrap software was a big deal to get right. Unfortunately as soon as the golden-master was declared, I and other devs had the capacity and creativity to do something truly remarkable that wasn't on the roadmap for the past 2 quarters.
Closi 5y ago
On the flipside, sales teams are probably the closest people in the business to what customers think they want. Engineering teams often have a disparaging view of the sales teams, but usually the sales team is just selling what is needed to get the sale. Sometimes this is 'misplaced', but in my experience of enterprise software it's more often the case that a client has a genuine requirement and the engineering team thinks 'feature x' is close enough, but the client disagrees (and the client will obviously be right about what their requirement is, and if feature x is close enough is just a matter of opinion).
- magicalhippo 5y ago
  > the client will obviously be right about what their requirement is I guess you mean that as "the client thinks they're obviously right", as in my experience they're surprisingly often wrong about what their requirements truly are. Sometimes spectacularly so. Most of the time this is because the decision is being taken too high up in the organization, so they don't actually know what their employees actually do or need. If not that, then it's not uncommon to see X-Y problems creep into requirements.
  - Closi 5y ago
    I mean that the customer/client will be right about what they want the requirement to be. Requirements are ultimately customer/user requirements/wants, not universal truths.

magicalhippo 5y ago

> [If] you have effective sales people you will find that they can and will unintentionally sell vapor that cannot be delivered. This can happen even if the sales people does not mean to sell vapor. At least in my experience, they seldom have the domain or program knowledge to pick up on nuances in the client's question, leading them to think they correctly answer "yes our program supports that" while in fact the program does not support exactly that. As a dev I'm not often involved in sales meetings, but every time I have been in a sales meeting I've averted some form of vapor. The sad part is that most of the times the client is fine with us not having the exact functionality they ask for, but understandably get upset when they only find out about this post-sale.

acwan93 5y ago
Is this why some orgs have "sales engineers?" People who can pick up the nuances of a client's question whether a company can actually do feature X?
- karmakaze 5y ago
  I got in 'trouble' a few times by giving alpha copies of a product in development to the sales engineers and when the customer saw particular new features wanted them and not any version without it. The trouble was caused when these events happened around release dates which back in the day of golden-mastered shrink-wrap software was a big deal to get right. Unfortunately as soon as the golden-master was declared, I and other devs had the capacity and creativity to do something truly remarkable that wasn't on the roadmap for the past 2 quarters.

Closi 5y ago

On the flipside, sales teams are probably the closest people in the business to what customers think they want. Engineering teams often have a disparaging view of the sales teams, but usually the sales team is just selling what is needed to get the sale. Sometimes this is 'misplaced', but in my experience of enterprise software it's more often the case that a client has a genuine requirement and the engineering team thinks 'feature x' is close enough, but the client disagrees (and the client will obviously be right about what their requirement is, and if feature x is close enough is just a matter of opinion).

magicalhippo 5y ago
> the client will obviously be right about what their requirement is I guess you mean that as "the client thinks they're obviously right", as in my experience they're surprisingly often wrong about what their requirements truly are. Sometimes spectacularly so. Most of the time this is because the decision is being taken too high up in the organization, so they don't actually know what their employees actually do or need. If not that, then it's not uncommon to see X-Y problems creep into requirements.
- Closi 5y ago
  I mean that the customer/client will be right about what they want the requirement to be. Requirements are ultimately customer/user requirements/wants, not universal truths.