These are some excerpts from the article "How to write a good PRD" by Martin Cagan from Silicon Valley Product Group:

"One of the common pitfalls, especially with follow-on releases of products, is that after several releases of continuously growing your product and adding new features, the engineering team wants to re-architect the product because of issues with maintainability, scalability, security, performance – any number of valid issues. They argue, typically very persuasively, that they can’t build any more new features because it is all “on a house of cards,” or “it was never designed to support what we’re now doing” and they must now take the time to get their house in order.

Assuming they are not simply exaggerating, then the product is very likely in serious trouble. Few products survive such a re-architecture, mainly because customers don’t see the value in these changes – they just think that nothing is happening and their needs are not being addressed for extended periods of time. And all too often these re-architecture efforts turn out to take far longer than anticipated. You can tell customers what you’re doing, but they don’t care – this dirty laundry is an internal problem – not something they want to care about.

The key is to avoid getting into this situation in the first place.

Some percentage (think along the lines of 10-20% of resources, but this can vary depending on the circumstances) in every release needs to go to the engineering team for them to continuously perform the systems work required to keep the foundation solid. If any of their changes will result in something customer-visible, then you as product manager should be involved, otherwise consider this like paying taxes. Just pull the percentage right off the top for each release, and tell the engineering team that these resources are theirs to use each release for addressing their architectural issues."

Extremely wise words. I actually left an employer once for not taking this advice, and thereby, not empowering the engineers before it was too late. After 12 months of giving them this advice, I came to the conclusion that they don't take feedback. Only after I and several other senior engineers started putting a spike on the turn-over rate of the company they started buying into a long period of re-factoring and re-architecture. I wish them well and hope that their investors are thinking long term - because in the short term, most of the revenue will be paid out in heavy tax lump sums: Software mutation tax.