Just as client/server computing brought controversy when it aimed to replace all monolithic, mainframe-based computing, the same thing is happening now with Software as a Service (SaaS). It is threatening to undo product management as we know it. Or is it?

For the end user, SaaS is a simple concept - he or she logs on to the application through an Internet browser. The user doesn't know or care where that application is being served from, only that it should work quickly and reliably.

As far as implementation costs, it's a no-brainer that as a result of not having to procure and manage hardware servers, most any SaaS application will look better on a return on investment (ROI) spreadsheet. Most businesses appreciate that the cost of SaaS systems can be accrued as a monthly operating expense that can be cancelled if things get really bad.

The pundits argue that SaaS applications lack integration with critical back-end systems, and that they compromise security and performance. Of course, it depends on the specific application and implementation, but in general, these arguments are getting harder to defend. In reality, the SaaS train is already speeding ahead, and if you don't get on it, you will get run over.

IT's role is clearly affected by the SaaS wave, but so is product management's. In a 2008 survey by Softletter, SaaS expert Rick Chapman noted, "&New feature development is still taking place at a frantic rate in SaaS: 49 percent report two or more major releases a year, a pace that is not possible with on-premise, client/server products."

This implies that companies with SaaS offerings must be much more adept at taking in, prioritizing, and defining product requirements. One might argue that fundamentally, product management must change to allow for dynamic and fluid processes that continually seek and sort through new product ideas. Genuine SaaS applications have a hyper-agile mentality, perpetually morphing as their community of customers, engineers, support staff, and others collaborate openly to deliver the software.

However, this isn't quite in line with our sociological makeup. Ultimately, there needs to be a designated responsible party when there are differing opinions about product plans. Product managers are supposed to be the ones responsible for making data-backed business decisions as to what features ultimately get built and when.

Product managers aren't the voice of the customer; rather, they are the ombudsman for the entire stakeholder community, allowing all members of that community to have a voice that is collected and considered in the software town meeting we call the product requirements process.

In a SaaS environment, the notion of a release isn't always clear. New functionality can essentially be rolled into the "production" server at any given time and "tested" in real time by active users.

It remains the product manager's responsibility to cull all of these ideas and to ensure there is business validation for the priorities in the development plan, no matter how short or iterative the development cycle may be.

Product managers must present the business case for each invested company resource. Without this, biased and improperly weighted squeaky wheels will inevitably get too much time and attention. Curiosity kills cats; opportunity cost kills companies. Therefore, SaaS is not the end of product management. In fact, unlike other, more slowly-moving types of applications, SaaS systems need even better product management.

Alyssa Dver is the chief executive of Mint Green Marketing, a consulting company specializing in product management, marketing, and corporate social responsibility. Her book, Software Product Management Essentials, has sold more than 30,000 copies worldwide. Contact Alyssa at alyssadver@mintgreenmktg.com.