6 ms·

>Maybe I'm being naive, but this seems a tad obvious, and not all that useful. IMO I've often seen extreeme scenarios and then a reactionary 180 swing to the o

>Maybe I'm being naive, but this seems a tad obvious, and not all that useful. IMO I've often seen extreeme scenarios and then a reactionary 180 swing to the other extreeme, it's usefull to recognise that both approaches are extreemes. It might be obvious to you but I constantly see devs that fail to recognise sales focus has value - like we need to ship feature X by Y to get client Z otherwise the opportunity is gone. I'd say 2/3 devs I've worked with will immediatly push back with concerns such as long term maintainability, scalability, etc. None of those would be a blocker for the sale or the initial customer, and once you land the customer you'll have the budget to go back and fix it - but yeah still a deathmatch to get those through sprint planning. And queue jaded devs here claming "they do it because they know once it's commited it will never get fixed", honestly whenever I come up with actual problems and solutions I can't remember being turned down (deffered a couple of times, still got to do it eventually) - I've worked for 2 startups, and 4 enterprise teams. So if you're not getting space to do this kind of improvements and care about code quality - maybe consider changing your workplace.

goalieca 5y ago
> and once you land the customer you'll have the budget to go back and fix it There’s always one more sale in the pipeline and you can end up with 15 year old products that are entirely the result of feature chasing. I think it is absolutely necessary for development to develop a better understanding of customers and their requirements. Is it possible for us to predict some of the features from customers 1..2.. or maybe 5 years down the line in a way that the architecture and design can easily accommodate? I think it is somewhat possible and there are many examples of flexible products that do just that.
- nostrebored 5y ago
  The key here is that product is a buffer between sales and engineering. Sales teams should be a constant source of feedback for product teams who can spot the synergies you're talking about. SDMs should be a constant buffer between engineers and product. This works wonders at an enterprise or mid market company. I don't envy smaller companies that need to drive alignment between stakeholders that have to straddle all of these lines. A good portion of my job is helping small businesses find that alignment and being able to present the big picture to all of these teams. Somehow being external seems to help.
  - jrochkind1 5y ago
    SDM?
    - vetinari 5y ago
      From the context, "Sales Development Manager".
    - g00gler 5y ago
      I was thinking software development manager
      - nostrebored 5y ago
        Software Development Managers, yes
- abakker 5y ago
  As a user of software, I have to add that it is nicer to have the features, and I don’t find myself worrying about what hacks went into making it. Most of the time. I know there are exceptions, but, usually I’d rather a company be customer focused and deliver a product I want, rather than worry too much about the methodology they use to deliver it.
  - anaerobicover 5y ago
    Sure, there's absolutely no reason for customers to know or case, but that's beside the point. It's going to be the developer's job to modify or fix things in the future. You're happy with the footbridge they built, but when sales comes back and says "okay new customer, now we need to be able to drive fully loaded Humvees across" you aren't the one tearing out the wooden posts and pouring concrete.
  - goalieca 5y ago
    How much enterprise software have you used over the years that has terrible quality? Vision and execution matter a lot in user experience and doubly so for security.
- LootCrateDev 5y ago
  Treating developers like loot crates is the surest way to turn your company into a shitshow. Feature chasing needs to have very coarse data attached to it: - how many overpromised features attracted revenue? - how many delivered overpromises features didn't win the potential customer? That last one is about 80% for my career.
  - Centigonal 5y ago
    What do you mean when you say, "treating developers like loot crates?" I understand your point that developer effort is valuable and should be directed toward features that have impact on the business and customers, but I don't see how that relates to the loot crate analogy. Is this about objectifying people? Is it about gambling related mechanics? I'm honestly very confused.
    - LootCrateDev 5y ago
      Sales: Potential client wants feature Y. Can we code it? Coder: Anything can be coded. Can sales bundle a contract where a SaaS covers that feature for us while we code it? Just to test drive the clients actual needs? Sales: no Coder: okay. Do you have data to show that's the actual need? Sales: I have an email of them saying that's their need. Coder: okay, no data. What are the odds of the customer onboarding once the feature is done? Sales: 100% Coder: okay, no reasonable thought process behind conversion odds. Do you have a memorandum of intent from the potential customer? Sales: no Coder: okay, so you have no capacity to wrangle a contract that bundles a third party for feature Y with our product, you have no data or insight about why this person wants this feature, and you say we have a 100% chance of converting to a customer despite not having a memorandum of intent. Sale: ...... but can we get feature Y tho? At this point, sales is myopic and thirsty and will use social pressure to force the dev to do something stupid. The company agrees because they see devs as loot crates: a concept where an interaction has a very low chance of very high rewards.
  - lumost 5y ago
    I'd also add that chasing clients tends to be a loosing game in the long term. The devs know this, but sales only sees an individual commission. In enterprise you get a lot of the following coming off the sales team. "We had a 5 minute phone call with someone doing a vendor comparison and saw that we didn't have features Y, and Z that X has. We got them to say they'd consider us if we delivered Y and gave them a 50% discount." The customer already decided on X, X isn't a direct competitor - if you build Y you'll just be a crappy version of X. Not to mention building Y means pushing out features that your target customers keep asking for. As a PM I got pulled into dozens of these calls as the sales team was desperate to hit quota. Not a single time did I see a feature that was worth building. The few times I saw a deal swing on these offers we had effectively guaranteed client specific dev work that other venders were turning down due to the risk of losing money.
- lelanthran 5y ago
  > There’s always one more sale in the pipeline and you can end up with 15 year old products that are entirely the result of feature chasing. That sounds like a different way of saying "you can end up with 15 years off revenue".
knowyourleadcom 5y ago
“we need to ship feature X by Y to get client Z otherwise the opportunity is gone.” When you say client it becomes consulting that happens to have a software project at that point. If your market needs feature x Like a mobile app because a competitor is going to crush you without it then it makes sense. Reacting to a market every now and then is understandable. However I think the horrible sales driven companies react to individual customers and that destroys your chances of any cohesive plan as each sales person hijacks your devs...which means at that point they are selling your devs time for their individual gain hurting company’s ability to make a large impact on the market. Shouldn’t happen but that’s sales driven.
- reader_mode 5y ago
  I don't know - I've worked for a startup (in the size/age sense, not in the unicorn scaling sense) where they focused on one market segment (small customers) then got the opportunity to onboard a huge franchise. This required a huge change but would basically make their buisiness stable for X years and allow them to grow into a different market. But they had specific dates that needed to be met because existing provider contract was expiring, etc. etc. So the product wasn't built for their scale, it took a bunch of invasive changes, dirty hacks, and accepting client specific workflow initially. You can look at that and say "we're lockign ourselves into their workflow" and "we're making client specific features" - but this client literally 3x their revenue year one and increased it a couple times more for extra features developed. And once you have one big client and solve their problems - you can try to generalise and sell to their competition as well.
  - LootCrateDev 5y ago
    Devs aren't loot crates.
    - simlevesque 5y ago
      Could you please explain what you mean instead of repeating an empty catchphrase? And did you really create this account to say the same thing over and over ?

goalieca 5y ago

> and once you land the customer you'll have the budget to go back and fix it There’s always one more sale in the pipeline and you can end up with 15 year old products that are entirely the result of feature chasing. I think it is absolutely necessary for development to develop a better understanding of customers and their requirements. Is it possible for us to predict some of the features from customers 1..2.. or maybe 5 years down the line in a way that the architecture and design can easily accommodate? I think it is somewhat possible and there are many examples of flexible products that do just that.

nostrebored 5y ago
The key here is that product is a buffer between sales and engineering. Sales teams should be a constant source of feedback for product teams who can spot the synergies you're talking about. SDMs should be a constant buffer between engineers and product. This works wonders at an enterprise or mid market company. I don't envy smaller companies that need to drive alignment between stakeholders that have to straddle all of these lines. A good portion of my job is helping small businesses find that alignment and being able to present the big picture to all of these teams. Somehow being external seems to help.
- jrochkind1 5y ago
  SDM?
  - vetinari 5y ago
    From the context, "Sales Development Manager".
  - g00gler 5y ago
    I was thinking software development manager
    - nostrebored 5y ago
      Software Development Managers, yes
abakker 5y ago
As a user of software, I have to add that it is nicer to have the features, and I don’t find myself worrying about what hacks went into making it. Most of the time. I know there are exceptions, but, usually I’d rather a company be customer focused and deliver a product I want, rather than worry too much about the methodology they use to deliver it.
- anaerobicover 5y ago
  Sure, there's absolutely no reason for customers to know or case, but that's beside the point. It's going to be the developer's job to modify or fix things in the future. You're happy with the footbridge they built, but when sales comes back and says "okay new customer, now we need to be able to drive fully loaded Humvees across" you aren't the one tearing out the wooden posts and pouring concrete.
- goalieca 5y ago
  How much enterprise software have you used over the years that has terrible quality? Vision and execution matter a lot in user experience and doubly so for security.
LootCrateDev 5y ago
Treating developers like loot crates is the surest way to turn your company into a shitshow. Feature chasing needs to have very coarse data attached to it: - how many overpromised features attracted revenue? - how many delivered overpromises features didn't win the potential customer? That last one is about 80% for my career.
- Centigonal 5y ago
  What do you mean when you say, "treating developers like loot crates?" I understand your point that developer effort is valuable and should be directed toward features that have impact on the business and customers, but I don't see how that relates to the loot crate analogy. Is this about objectifying people? Is it about gambling related mechanics? I'm honestly very confused.
  - LootCrateDev 5y ago
    Sales: Potential client wants feature Y. Can we code it? Coder: Anything can be coded. Can sales bundle a contract where a SaaS covers that feature for us while we code it? Just to test drive the clients actual needs? Sales: no Coder: okay. Do you have data to show that's the actual need? Sales: I have an email of them saying that's their need. Coder: okay, no data. What are the odds of the customer onboarding once the feature is done? Sales: 100% Coder: okay, no reasonable thought process behind conversion odds. Do you have a memorandum of intent from the potential customer? Sales: no Coder: okay, so you have no capacity to wrangle a contract that bundles a third party for feature Y with our product, you have no data or insight about why this person wants this feature, and you say we have a 100% chance of converting to a customer despite not having a memorandum of intent. Sale: ...... but can we get feature Y tho? At this point, sales is myopic and thirsty and will use social pressure to force the dev to do something stupid. The company agrees because they see devs as loot crates: a concept where an interaction has a very low chance of very high rewards.
- lumost 5y ago
  I'd also add that chasing clients tends to be a loosing game in the long term. The devs know this, but sales only sees an individual commission. In enterprise you get a lot of the following coming off the sales team. "We had a 5 minute phone call with someone doing a vendor comparison and saw that we didn't have features Y, and Z that X has. We got them to say they'd consider us if we delivered Y and gave them a 50% discount." The customer already decided on X, X isn't a direct competitor - if you build Y you'll just be a crappy version of X. Not to mention building Y means pushing out features that your target customers keep asking for. As a PM I got pulled into dozens of these calls as the sales team was desperate to hit quota. Not a single time did I see a feature that was worth building. The few times I saw a deal swing on these offers we had effectively guaranteed client specific dev work that other venders were turning down due to the risk of losing money.
lelanthran 5y ago
> There’s always one more sale in the pipeline and you can end up with 15 year old products that are entirely the result of feature chasing. That sounds like a different way of saying "you can end up with 15 years off revenue".

knowyourleadcom 5y ago

“we need to ship feature X by Y to get client Z otherwise the opportunity is gone.” When you say client it becomes consulting that happens to have a software project at that point. If your market needs feature x Like a mobile app because a competitor is going to crush you without it then it makes sense. Reacting to a market every now and then is understandable. However I think the horrible sales driven companies react to individual customers and that destroys your chances of any cohesive plan as each sales person hijacks your devs...which means at that point they are selling your devs time for their individual gain hurting company’s ability to make a large impact on the market. Shouldn’t happen but that’s sales driven.

reader_mode 5y ago
I don't know - I've worked for a startup (in the size/age sense, not in the unicorn scaling sense) where they focused on one market segment (small customers) then got the opportunity to onboard a huge franchise. This required a huge change but would basically make their buisiness stable for X years and allow them to grow into a different market. But they had specific dates that needed to be met because existing provider contract was expiring, etc. etc. So the product wasn't built for their scale, it took a bunch of invasive changes, dirty hacks, and accepting client specific workflow initially. You can look at that and say "we're lockign ourselves into their workflow" and "we're making client specific features" - but this client literally 3x their revenue year one and increased it a couple times more for extra features developed. And once you have one big client and solve their problems - you can try to generalise and sell to their competition as well.
- LootCrateDev 5y ago
  Devs aren't loot crates.
  - simlevesque 5y ago
    Could you please explain what you mean instead of repeating an empty catchphrase? And did you really create this account to say the same thing over and over ?