In my experience there is a balance between providing regular updates to users and making the application high quality. So first, let's look at the extremes:
Releasing too often: When you release too often, the QA team is always behind the eight ball. Even though they may be creating/running automated test scripts, they need time to get that work done. When a large enough portion of the testing has to be manual, there will always be bugs that slip through. Short story--the probability that a high profile bug getting through to the customer goes way up.
Not releasing often enough: Two problems happen at this point--customers get fed up with the tool, and everyone gets lazy. When you have a long time between releases, developers want to do more, testers get less vigilant, and the chance of schedule slips go up. This is all due to the perceived extra time that everyone has. Customers who get impatient start calling for a new solution--one that will solve their problems today and not 6 months from now.
Finding the balance: There is a point where your team's productivity reaches a peak sustainable rate. You'll have to experiment to find what that is. IMO, 1 month is not enough time to implement any substantial feature and ensure it is working properly. My team works very well in 2-3 month intervals, although it is at peak efficiency with 3 months. You have enough time to do redesigns when necessary, and implement major new features. The test team doesn't feel like they have the luxury of time, but have enough to keep up and remain vigilant. Customers also can deal with 3 month release cycles--particularly if the quality of the release is high.
Finding the peak for your team will require measuring quality in some meaningful way. The only meaningful metric that really matters is:
How many bugs were found by your customers?
I don't care how many bugs were found and resolved in house, that's just a sign that everyone is doing their job. The more the better. I care most about how many bugs, and the severity of the bugs that the users discover. That is the most reliable direct measure of your software release quality I know of.
A related metric that is equally telling, but in a different way is:
How many new feature requests from the customers?
Feature requests are an indication that people really are using the system, and are thinking about how to make their jobs easier. The requests can be as simple as changing "happy" to "glad" in the help files, or as complicated as new ways to visualize data. It's important to distinguish a request for a new feature from a poorly designed user interface (that would be a bug found by the user). The number of feature requests is not necessarily an indication of missing the mark, it is more an indication of user interest. Also know that your customers are learning how the tool improves their jobs at the same rate you are learning about your customers. The customer can only visualize and recommend incremental improvements. It's up to you to determine if there is an underlying theme to the requests and find if there is a different approach that may address all the concerns.
