[rahimnathwani]

  Product should have nothing to do with refactors on the systems.

Let's assume the reasons to refactor are:

1. Reduce unnecessary complexity, and

2. Reduce the gap between the code architecture and our current understanding of the domain.

Sure, you could refactor and preserve 100% of existing system behaviour, but:

- why not take the opportunity to discover the remove features that are annoying to maintain, but that the ops folks can live without (with some process change)?

- for #2, product folks can be helpful

[from-nibly]

I meant refactor extremely broadly. As in the stuff that doesnt make customers happy, it makes engineering more effective at their jobs so they can deliver faster.

That includes refactoring, pruning, training, scaling, vendoring, etc.

[rahimnathwani]

Yes, but with this approach you risk spending effort refactoring code that could instead be deleted.

[antonvs]

Product folk hardly ever want to remove features.

[mihirchronicles]

There is a lot of fear in sunsetting features. This could be due to friction in how long it takes to develop. For example, consumer technology does a better job than regulated industries such as finance or healthcare.