2 ms·

> "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 tha

> "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 2y ago
> 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 2y ago
  > 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 2y ago
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 2y ago
  > 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 2y ago
    > 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.

worksonmymach 2y ago

> 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 2y ago
> 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 2y ago

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 2y ago
> 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 2y ago
  > 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.