4 ms·

1) Most of HN is young and has never worked on the business side of an org where they had to do things like lose a customer because the feature they wanted is t

1) Most of HN is young and has never worked on the business side of an org where they had to do things like lose a customer because the feature they wanted is taking too long to finish or repeatedly push back multiple expensive dependent non-engineering projects because engineering keeps hitting development roadblocks. 2) A lot of developers really hate committing to any kind of estimate because they're really just not that good at estimating for a variety of reasons and getting stuck in a commitment that turns out to be unrealistic really sucks. 3) In my experience a good portion of orgs really are bad at business-engineering interactions and end up in adversarial relationships like you're talking about where engineering is seen as "those guys that refuse to commit to any deadline and suck at communicating status I can plan around" and the business owners are "those guys who don't understand what they're asking for and are constantly trying to micromanage to get blood from a stone". Also in my experience, neither side is entirely innocent in these situations.

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.
pif 6y ago
> push back multiple expensive dependent non-engineering projects If those projects have to be pushed back, the only explanation is that they were started too early.
- mdorazio 6y ago
  That's nice in theory only. In the real world, dependent projects often have long lead times, which often means foregone revenue for the business because of holdups.
pif 6y ago
> A lot of developers really hate committing to any kind of estimate In development (as opposed to production) I personally fight against any commitment if it comprises the "what" as well as the "when". You fix the date of the next release and provide me with a prioritized list of bug fixes and features to work on? Nice, let me start to work! You think that a specific new feature could improve our sales and you let me drop anything else and call you back as soon as I have any news? Wonderful, I'm already analysing the issue in my head! Anything else, and I'll let you know that your dreams are not likely to come true.
- sooheon 6y ago
  The iron triangle[1] is a well known model. If the "business" side insists on "engineering" breaking it, they are not serving their function. [1]: https://en.wikipedia.org/wiki/Project_management_triangle https://en.wikipedia.org/wiki/Project_management_triangle

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.

pif 6y ago

> push back multiple expensive dependent non-engineering projects If those projects have to be pushed back, the only explanation is that they were started too early.

mdorazio 6y ago
That's nice in theory only. In the real world, dependent projects often have long lead times, which often means foregone revenue for the business because of holdups.

pif 6y ago

> A lot of developers really hate committing to any kind of estimate In development (as opposed to production) I personally fight against any commitment if it comprises the "what" as well as the "when". You fix the date of the next release and provide me with a prioritized list of bug fixes and features to work on? Nice, let me start to work! You think that a specific new feature could improve our sales and you let me drop anything else and call you back as soon as I have any news? Wonderful, I'm already analysing the issue in my head! Anything else, and I'll let you know that your dreams are not likely to come true.

sooheon 6y ago
The iron triangle[1] is a well known model. If the "business" side insists on "engineering" breaking it, they are not serving their function. [1]: https://en.wikipedia.org/wiki/Project_management_triangle https://en.wikipedia.org/wiki/Project_management_triangle