4 ms·

> lose a customer because the feature they wanted is taking too long to finish That's sales guy talking. From my point of view, he is not a customer! A custom

by pif 6y ago

> lose a customer because the feature they wanted is taking too long to finish That's sales guy talking. From my point of view, he is not a customer! A customer is someone who buys the product we currently have ready to sell, or someone who pays for customization.

mdorazio 6y ago
1) Have you ever worked on the business side? And no, business =/= sales. 2) Except I have seen multiple times when customers paid for customization, then jumped ship (and demanded a refund) because that same customization took too long.
- sooheon 6y ago
  You shouldn't take money for what you can't deliver. If enough customers ask for a customization, add that to your pipeline and you'll have some good news to share when it's ready.
- knightofmars 6y ago
  Customization for a customer is an area that needs extreme care. It's very easy to accept that "one little change" to get ink on that sales contract. And at times is a reasonable thing to do. But it can lead to a number of very bad situations. Scenario A, promise too many customizations at the same time you're going to have a bad time trying to deliver on them all. This is frustrating for everyone and is often the result of poor leadership. Pushing sales and revenue targets on one side while ignoring the very real resource constraints on the other. Scenario B, customizations that are customer specific, meaning a customization that isn't likely to be used by other customers due to a quirk in that single customer's workflow to get them to sign. This leads to feature bloat and increases the maintenance burden of the product over time. There is a reason that product owners need to be able to say, "No" and be good at managing expectations. Otherwise they end up with an unmanageable backlog, broken promises, and sometimes will scapegoat the engineering team. That isn't too say over promising doesn't happen on the engineering side of the equation. But the product owner is the individual ultimately responsible for all feature work promised.

by pif 6y ago

mdorazio 6y ago

1) Have you ever worked on the business side? And no, business =/= sales. 2) Except I have seen multiple times when customers paid for customization, then jumped ship (and demanded a refund) because that same customization took too long.

sooheon 6y ago
You shouldn't take money for what you can't deliver. If enough customers ask for a customization, add that to your pipeline and you'll have some good news to share when it's ready.
knightofmars 6y ago
Customization for a customer is an area that needs extreme care. It's very easy to accept that "one little change" to get ink on that sales contract. And at times is a reasonable thing to do. But it can lead to a number of very bad situations. Scenario A, promise too many customizations at the same time you're going to have a bad time trying to deliver on them all. This is frustrating for everyone and is often the result of poor leadership. Pushing sales and revenue targets on one side while ignoring the very real resource constraints on the other. Scenario B, customizations that are customer specific, meaning a customization that isn't likely to be used by other customers due to a quirk in that single customer's workflow to get them to sign. This leads to feature bloat and increases the maintenance burden of the product over time. There is a reason that product owners need to be able to say, "No" and be good at managing expectations. Otherwise they end up with an unmanageable backlog, broken promises, and sometimes will scapegoat the engineering team. That isn't too say over promising doesn't happen on the engineering side of the equation. But the product owner is the individual ultimately responsible for all feature work promised.