> If you're delivering something good for clients...

That's the crux of it, isn't it? How do you know that what you're delivering is any good?

Depending on the customer and the work, I might not — or, to be more precise, I might only know some aspects of the product's quality based on what the customer tells me. Or I might only directly know whether certain aspects of what I'm doing are good. Arguably that's actually always the case, but if you're doing consumer-oriented mass-market stuff, then it's quite possible that "what the producer knows" overwhelms what the "customer" knows. But not all software is something you can dogfood or A/B test, and software developers are _very_ quick to assume that they know better than customers, especially if the customer is in some way locked-in.

For some software products, the runtime and output can be measured for quality.

Right, but what the article tries to point to is places where they don't see whether it's good or not after the feature is shipped.

If you know it is going to be a nightmare to support, it will consume tons of resources (cpu/storage), and nobody wants to pay for it (or not pay enough to cover its costs), it is not good.

As has been mentioned many times on this site, it is very easy to sell $2 for $1 all day long.

> nobody wants to pay for it (or not pay enough to cover its costs), it is not good.

And how do you know this in advance?

You ask them.

‘Will you pay an additional $x/mo for this feature?’

You can estimate your AWS costs for what the feature would cost for that user.

You can estimate dev and implementation time.

It doesn’t even have to be 100% accurate, but if the numbers come nowhere close to making sense, don’t pursue this further.

Now, there may be a future time where some fundamental cost changes, and it is worth considering again.

It sounds nice, but it doesn't work very well.

Users lie. Not even maliciously.

Clients will say they'd pay for it, then when you deliver it they'll say they realized that your competitor provides that and everything else that is really important to them in the standard fee. The competitor is actually no better, and would require the same amount of development to get to parity in other areas, but they win by claiming that everything will be rainbows.

Clients will say they'd pay for X, but once you deliver it they'll suddenly realize that it won't actually work for them until you also implement Y, but they won't pay any more for X+Y than they would for X alone.

Clients will say they'd pay for X, but once you deliver it they'll have shifted direction or something has changed and they don't need it anymore.

Clients will say they'd pay for X, but once you deliver it and they start using it they'll discover that it's not at all what they actually needed.

it's more that they're measuring the wrong thing. wash rinse repeat here just leads to implosion due to neglecting the big picture, death by 1000 cuts, etc.