(Before reading this article, I strongly suggest downloading and reading the complete July 31st, 2008 issue of Softletter that describes in detail the developments at SaaS ERP provider Plex (the company was called Plexus in 2008) that sparked this series of articles. After transitioning from a client/server to a SaaS business model, Plex discarded its entire product manager/product marketing manager framework. The article is available as a free PDF from the Downloads section of the site; access to this section does require you subscribe to the site. You can do so here.)

As mentioned in the previuos articles and in some of the back and forth between me and those who commented on this series of articles, product management in the software industry has always had an uneasy relationship with the rest of the company (and upper management) because of the lack of an “organic” connection to the bottom line. Product managers aren’t responsible for sales in any truly measurable sense and developing measurable benchmarks for the position has always been a challenge.

As proof of this, I bring you some quotes fresh from the online pages of Pragmatic Marketing's website wherein the question of how to measure the activities of product managers was answered thusly:

• "Number/frequency of face-to-face visits with the market”
• “Creation of Buyer and User Personas” 
• “Drafts of Problem Statements"

This compelling list ends with:

• "Statistically valid market evidence that describes those Problem Statements by their pervasiveness and urgency”

None of which are the sort of metrics that warms the cockles of the typical CEO’s flinty heart.

In SaaS companies, as the concept of the community of users grows, most of the functions traditionally associated with product managers discussed in my previous articles disappear or become irrelevant.  First, as the example of Plex (and others) demonstrates, the need for feature requests management should be handled directly by the SaaS application, with prioritization driven primarily by the community of users. Software tools to help automate this process will be an important part of the development of SaaS user communities and requirements management software from companies such Accept 360 and FeaturePlan have been in the market for years. And a new generation of community-focused products for the SaaS industry, exemplified by companies such as Quantum Whisper (www.quantumwhisper.com) will be appearing in the market over the next two years, further driving community creation and growth.

Second is the disappearance of MRDs, PRDs, and other related documents. These documents have always been closely tied to the traditional 12 to 18 month software release cycle, but as the data in The 2009 Softletter SaaS Report demonstrates, this cycle is disappearing in SaaS. In a environment of continuous build, test, and release, no one has time to create or read lengthy MRDs, PRDs (and the pace of SaaS development tends to make these documents obsolete before they can be finished). Instead, ongoing dialog between your company and your community of users recorded and integrated into the SaaS community system will substitute for these documents and provide an ongoing narrative of product change, adaptation, and evolution.

A third area of radical change is the stand-in role that product managers have played during the Agile development cycle. With a community of users, no middleman is needed to communicate directly with customers. Tools such as “personas,” which attempt to simulate customers, will be less compelling when actual customers can be contacted via a community system which encourages them to directly interact with new versions of the product under development in “sandboxed” areas of your system that capture actual clicks, record actual complaints (or kudos), and allow detailed usaage analyses.

Other trappings of Agile which have also been draped over product management will also fade away in SaaS companies. For example, some software firms attempt to make product managers “product owners.” This role means something fairly specific in most Agile methodologies.  An Agile product owner functions mainly as a project manager to the development team and functions, in the words of some, as “wringable neck” during the development cycle. The product owner is supposed to be able to dictate release schedules and requirements implementation to the development team, a power many product managers have often dreamed of wielding.

The reality is unless the product manager is also a programmer, the feasibility of having a non-progammer dictate much of anything to a group of coders is about zero. Which is why I find the growing number of references and courses on “Agile product management” rather funny; it’s somewhat analogous to recommending or selling surf boards to elephants. (BTW, in this month's issue of SaaS University Journal, we'll be writing on this topic further; if you subscribe to the site, you'll receive the issue. Yes, subscribing is free.)

Finally, launch planning is another area of operations that will undergo radical change in SaaS companies. In on-demand, your first product “launch” tends to be your last. Once introduced, SaaS products, driven by the interaction between your company and your community, evolve, as the data in our 2009 SaaS Report demonstrates, in a continuous way. If the role of the PMM survives in a SaaS company, it will be a very different type of job. Marketing programs will focus more on providing access to trusted experts, bulding “micro promotions” closely tuned your communities internal business clock, providing services of ongoing value. The big marketing build up so common in software is becoming increasingly absent in SaaS.

The Era of Product Management Accountability (and Responsibility)

The question thus arises: Is there any need for product and product marketing managers in a SaaS company?  The answer, to be blunt, is no. I believe that within 18 months, traditional software product management will be as relevant to SaaS companies as floppy disks. If you’re a SaaS company considering spending significant amounts of money on product manager training, publications, research, reports, current "Agile" product management relevations, etc, we suggest you reevaluate your plans and spend stingily or not at all until these offerings fit on-demand realities. Also remember that while client/server applications can’t create the same level of business intelligence inherent in SaaS applications, many aspects of SaaS community creation can be embedded into the application; of course, both the vendor and the customer must buy into the concept, a task that is far less difficult in a SaaS milieu.

However, I do believes a new functioning role will arise in the software industry to replace what is now called “the product manager.” I'm not going to predict if the PM title will survive the coming upheaval; perhaps an appellation such as “community manager” (CM) may describe the job better. Regardless, tomorrow’s PM or CM will possess a very different skill set, one that incorporates true accountability, responsibility, and bottom line metrics into their job. In SaaS, CMs will be responsible for:

Community satisfaction.  Once a SaaS product has been introduced, it will be vital for its customer base to grow quickly into a interactive, self-managing community; obviously, helping create this dynamic will be the job of the CM. Measurable metrics will include the size of the community, % of growth, % of community involvement by customers, and level of satisfaction with the CM by the community. Product managers are supposed to crave constant customer contact; in SaaS, it will be the central facet of their day-to-day work. Very, very soon, observations such as this from The Cranky Product Manager:

"Because the Cranky Product Manager needs to be the Voice of the Customer and the Voice of the Market.  How is she to do that without actually VISITING some customers and prospects?  And VISITING means that she actually needs to leave the office, hop on airplanes, and fly far, far away."

Will sound as relevant in SaaS as DOS 3.0 and WordStar.

Community learning and self support.  It's is not always possible for a software company to recoup technical support costs via sales of professional services and in all cases, driving these costs down carries straight to the bottom line. Achieving this via the process of creating a self-supporting community will an ongoing metric by which CMs will be measured.

Community monetization. A SaaS community is a rich potential source of additional and incremental revenue for the company. These may include:

• Sales of specialized reports to interested members of the community.

• Sales of aggregated data (where appropriate) on best practices and business trends relevant to the industry(ies) serviced by your customers

• Sales of upgrades as well as cross/upsells from promotions recommended and, in some cases, implemented by the CM or perhaps a "community marketing manager." (It may prove desirable to separate these two roles lest the CM come to be regarded as a sales shill rather than a community advocate.)

• Fees from new capabilities requested by community members who are willing to pay to achieve new levels of functionality on an accelerated basis.

• Revenue shares with companies who are building new services on top of the SaaS vendor’s API/platform (assuming your system offers this type of access/functionality).

Community intelligence. A good SaaS community system will allow a CM to collect, analyze, and report on community usage of a SaaS system at a very deep level. Every login and click (and non click) can be stored, aggregated, and measured; SaaS companies can measure user/product interaction in ways not possible before. Thus, if the development group (or the CM) feel that, for instance, Feature X should be added to the system instead of the Feature Y requested by the community, it will possible to measure acceptance, (and assign responsibility) for the success or failure of new feature additions and subtractions. As I noted in my comments on the previous articles, in the aggregate, your community of users represents a constantly changing and evolving marketplace, and marketplaces are highly predictive and very smart.  I've read many, many statements over the years about how customers don't really know what they want in software products.  Observations such as this one:

We are working with some of the biggest banks in the world to understand their requirements and exactly how their business works. I used to be responsible for security for over 3,500 developers and let me tell you PM girl that I know what a mess it would be if you let the masses build what they want! 

Do you think you're smarter than your marketplace? Your "mass?" It's your product; you can build what you want. But now you'll be held accountable for your best guesses. Hope you're the deep thinker you think you are. I'm betting that in many, if not most, cases, your community will be smarter than you.

The impact of this ability to precisely measure community and user acceptance of new capabilities via the measurements created by the combination of community input and BI derived directly from the application provides a strategic advantage unique to SaaS firms. Since the early 80s, endless agita, angst, and anguish has surrounded the issue of providing customers with the functionality they truly want in their software. The press and "voice of the customer" advocates have shed endless floods of crocodile tears bemoaning feature "bloat" while ignoring the reality that every software company experiences--nothing drives sales  and revenue more than introducing new capabilities into your products.  But SaaS companies are in a position to quickly and precisely meet their user needs in ways and time frames never before possible.

But with great power comes great responsibility. In the past, software companies have been very good at pointing internal fingers when new releases don’t do well. Sales blames product management for providing unsellable products (normally, they’re too afraid of development to blame them). Product management blames development for refusing to listen to their MRDs and implement the requirements list. Development blames product management for providing lousy user input and unrealistic and vague requirements and sales for being a group of suits who couldn't sell candy to children. Upper management blames all of them. 

But soon, all the excuses will be going away. In a properly constructed SaaS system, accountability and measurability will be pushed out to every job and function in your company by your community of users. And for what is now called product management (and may still be in the future), I think the changes are very positive. CM/PM will now directly impact the bottom line and gain the corporate respect always generated by this power. CMs/PMs will work in jobs with real metrics tied to results that increase sales and decrease costs in measurable ways. With the ability to make money will come the ability to spend money, the ultimate "strategic" power.

And you won't have to listen to that old sneer "All responsibility, no accountability, no authority" anymore.  And you won't be able to use it as an excuse ever again.