> The result is that our product breaks more often than we’d like. The core functionality may remain largely intact but the periphery is often buggy, something we expect will improve only as our engineering headcount catches up to our product scope.
I really resonate with this problem. It was fun to read. We've been tried different methods to balance customers and long-term projects too.
Some more ideas that can be useful:
* Make quality projects an explicit monthly goal.
For example, when we noticed our the edges in our surface area got too buggy, we started a 'Make X great' goal for the month. This way you don't only have to react to users reporting bugs, but can be proactive
* Reduce Scope
Sometimes it can help to reduce scope; for example, before adding a new 'nice to have feature', focus on making the core experience really great. We also considered pausing larger enterprise contracts, mainly because it would take away from the core experience.
---
All this to say, I like your approach; I would also consider a few others (make quality projects a goal, and cut scope)