[motorest]

> "Our customers prefer the product works over getting a new feature, so let's ensure that at any cost"

Do they, though? If a competitor launches a feature that all your customers want and start to switch to benefit from it, what are you going to do? Show burn-down charts of your bug backlog?

[worksonmymach]

> If a competitor launches a feature that all your customers want and start to switch to benefit from it, what are you going to do?

I would say this is not that common in SaaS. In that features are important but PMF is key. A feature that drags people over is really a new product. I can't think of an example of the bolt-on killer feature. And by the time you are big enough to run multiple distinct products youd better have good uptime. If you are a startup of course you need features but again finding PMF so you ain't worried about competitors. As a startup you are choosing boring tech and maybe a PaaS to help you do less productioning.

Notice the popularity of k8s, splunk, CI/CD, testing, multi region and so on? Yeah there is big money in being available.

[motorest]

> A feature that drags people over is really a new product.

But isn't that a post-facto observation? I mean, any project can work on a complex feature that's a flop, but sometimes a simple feature can go a long way and just tilt the scale. That's not a new product.

[whstl]

False dichotomy. The point of the quote is to worry about not breaking the product. It's still possible to deliver features while keeping it working.

[motorest]

> False dichotomy.

Not really. This is the fact of real world software development: your resources are limited, and either you invest them creating value for customers so that they choose your product over your competitor's or they choose your competitor's instead.

If you spend your resources on technical debt and clearing bug backlogs even of obscure nonblocking bugs, you're just spending your resources to offer your users more of the same. If you instead use your resources to deliver new features that might have a nonblocking bug here or there, you're improving your position over the competitor's.

Time to market matters. A lot. There is no such thing as time to empty backlog.

[jack_h]

> If you instead use your resources to deliver new features that might have a nonblocking bug here or there, you're improving your position over the competitor's.

In the short term. Features can attract new customers but software that is frustrating to use due to a lot of low level bugs will repel existing customers towards competitors over the long term. If you've simultaneously decided tech debt isn't worth addressing then your competitor can easily overtake you. Furthermore adding feature after feature eventually leads to a kitchen sink product where potential customers are put off by the learning curve. This is really just a variation on the quantitative fallacy that ignores qualitative aspects.