…ratchet up your release cycles to monthly, then you can call it a ‘release’ or a ‘beta.’ Either way customers get their hands on the new functionality. If they don’t like what they get you’ll hear about it.
The good news about SaaS is that, by eliminating concerns about customer migration and installation costs, you can truly embrace the frequent releases recommended by most agile methodologies. The bad news is that four to six week release cycles don’t leave much time for customer feedback, and so most of it comes after the update has been pushed, when sales and customers start pushing back on some of the changes (or asking for more).
One way around this is inherent in the agile model itself. By breaking down new functionality into small chunks for release, you can take customer feedback as each chunk is delivered. You may be wrong with every release, but you won’t be as dramatically wrong as if you waited six months before getting customer feedback, and you’ll be able to quickly find and correct the areas where you were wrong with each new functional push.
In the meantime, you can take your overall plan for the functionality that you hope to have completely delivered over three to four releases, whether in the form of a design prototype or even a set of slides, in front of your key customers and get their feedback, and prioritize any changes into upcoming releases.