by Merrill R. (Rick) Chapman, Softletter Managing Editor

This has changed with SaaS. Take a look at the results from our 2012 SaaS survey below:

How often do you release a “major update” of your SaaS product to your customers? (A “major update” is defined as including significant new features and functionality, not just incremental improvements and bug fixes)?

Note that aggregated, 48% of SaaS companies are releasing major new versions of their product three or more times a year; 64% are releasing major upgrades twice a year. This frequency of release was never possible in desktop/retail and client server markets and has driven the rapid acceptance of Agile methods in SaaS, as we see below:

Does your company implement “Agile” methodologies in its R&D?

When we began this survey series five years ago, these numbers were almost exactly reversed.

The reason for the rapid acceptance of Agile by SaaS companies is that the underlying approach is an excellent fit to the hyper speed release cycles of cloud applications firms. Spotting an opportunity, various companies and pundits began talking about the “Agile Product Manager” (and offering courses designed to transform you into one these new, exotic beings).

The only problem is they can’t.

The Product Manager/Agile Methodology Non-Conjunction

OK, it’s now time to crack open that copy of Pragmatic’s Living in an Agile World. We’ll interrupt this article and give you time to work through it; a half hour or so should do it.

Good, you’re back. Let’s resume.

First, you’ll note that Living talks a great deal about “The Product Owner.” The idea of a product owner is an intrinsic part of Scrum, currently the most popular Agile system in use in SaaS. In Scrum, what does a product owner do? Let’s quote the book:

“The product owner is a new role, created and defined by the Scrum Alliance (www.scrumalliance.org). Product owners live full-time with development teams—elaborating users’ stories, managing sprint-level backlogs, expanding specifications, and interpreting product vision.”

Some of this sort of sounds like things a PM might do.

So, is a product manager now a product owner? Not according to “Living”:

“And a product manager is now called a Product Owner… right?

Wrong!'”

Not everyone agrees with the above (though I think the book has it right here). For an even more detailed analysis of Scrum’s product owner concept, visit Jack Milunsky’s blog at http://agilesoftwaredevelopment.com/blog/jackmilunsky/top-10-activities-product-owner and read a bit more about the topic. You’ll note that when Jack raises the question of can a product owner be a product manager, his answer is “Yes.”

So, why does Living feel that a PM can’t be a product owner? Because:

“In fact, a product owner’s responsibilities are just a small subset of product management.”

I think before going further, we need to understand more completely just what it is that a product owner does. Let’s ask Jack; after all, he’s a certified scrum master! According to him, a product owner:

• “Creates and maintains the product backlog.” (More colloquially known as the new features that aren’t done yet).
• “Assists with the elaboration of Epics, Themes and Features into user stories that are granular enough to be achieved in a single sprint.” (This is shorthand for the creation of simulated users because the lure of Cheetos and stale Mountain Dew hasn’t enticed any real users into the development cubicles and the product manager is only available to sit down with us on Thursdays from 1:15PM to 2:45PM.)
• “Conveys the Vision and Goals at the beginning of every Release and Sprint. (Hands out the Jolt Cola before beginning more coding.)
• “Participates in the daily Scrums, Sprint Planning Meetings and Sprint Reviews and Retrospectives.” (Makes sure that everyone is in their cubicles and working hard.)
• “Inspects the product progress at the end of every Sprint and has complete authority to accept or reject work done.” (Looks for bugs.)
• “Can change the course of the project at the end of every Sprint.” (Tells the PM that no, that feature isn’t making it into this release.)
• “Terminates a Sprint if it is determined that a drastic change in direction is required.” (This usually only happens when the company goes out of business and everyone is laid off.)

Whew! That’s a lot of stuff to do. It seems that what a product owner does is manage a development team (in other words, herd cats). In the 80s and 90s, people with this job were typically called software project managers and it was pretty much a full-time job. And project managers always reported to development.

But wait! That’s not ALL the product owner does. In addition to all of the above, they ALSO:

“Represents the customer, interfaces and engages the customer.” (Since the product manager is never available, screw them. I’ll do this myself).

“Prioritizes and sequences the Backlog according to business value or ROI.” (See the above comment.)

Now, it should be apparent why scrum product owners can’t be product managers. The primary function of product owners is to manage developers and for that, you need another developer. A programming team will not accept a PM as their team leader. PMs don’t understand code, they stink of too much time spent with marketing and sales, they wouldn’t know how to break out of a do..while loop if they were given a map and they’re not qualified to tell us bupkus. Development personnel and PMs may have good business and interpersonal relationships, but coders don’t take order from PMs.

But, Living has its own take on what product owner can and can’t do. According to the folks at Pragmatic:

“Product owners can’t rank backlog based on ROI (in fact, In fact, this task is impossible for anyone to do, since real business metrics and financial projections don’t exist at the feature/backlog/item level.” (BTW, this statement all by itself shows just how out of touch current theories about SaaS and product management are, as increasing numbers of SaaS companies are doing just this. But the point that Living wants to make is that the spreadsheet jockey work should be left to the PMs, not some geek in development.)

And Living doesn’t think product owners are much good at representing users to development, either:

“Creating successful benefits and feature descriptions that truly sell products, requires a detailed understanding of the technology and a detailed appreciation of the customers’ problem. This takes lots of practice, hands-on field experience, and a clear view from both sides. In our experience, internally promoted technical staff members almost never get this right.”

So where does all this Agile theorizing leave us? Right back where we started. The rest of the book simply repeats the standard mantra that’s developed around product management in software for the last thirty years. For example, when talking about the interaction of product management with Agile teams, we’re assured that “Product management is outwardly focused.” Uh, yes. And we learn that “As Pragmatic Marketing-trained product managers know, you don’t learn anything about the market while sitting at your desk” an observation that’s wrong for an increasing number of SaaS firms and steadily becoming “wronger.”

And of course, we hear again that “The point of integration for these teams, though, is a single product manager. When the executives demand ‘one throat to choke,’ it’s the product manager who is responsible for overall success of the result.”

That’s nice, but as anyone who’s worked in product management and followed the evolution of the job knows, after 30 years of theorizing, training and courses, product managers still can’t:

• Hire/fire personnel.
• Control the budgetary expenditures of “their” products.
• Measure their performance against significant quantitative business metrics.

And they’re still the first people fired when things go wrong. It seems obvious that demanding responsibility without authority is ultimately a pointless exercise, but people have been tilting at various windmills for centuries, so I don’t expect the process to stop anytime soon.

Which brings us (back) to the point of this article. And that is that Agile product development methodologies are exactly that. Development methodologies. They were designed for and by programmers, they are used by programmers, they are used to measure programming development and they do not apply to product managers. There can be no such thing as an “Agile” product manager because PMs aren’t programmers. And in many cases, the ostensible role of “user stand in” that PMs are sometimes supposed to play, are dedicated to specialists in development who carry out such tasks such as developing use cases, creating personas, and all the other “virtual person” activities that have been developed to cope with the fact that while the PM would really LIKE to stand in for the customer, it’s a busy corporate world out there and besides, the PM’s leaving with the CEO for a road junket playing the role of demo dolly in front of the press and some important analysts. Scratch the Thursday meeting for the next two weeks.

By the way, to further illustrate the point, I do urge you to read the rest of Living in an Agile Word all way to the end. You’ll note that while they talk a great deal about “Agile product managers,” they never actually describe what an “Agile product manager” does in contrast to a regular old slug of a PM. And that’s because there’s nothing extra for them to do.

Now, it’s time to leave the last 30 years behind and look to the future. Let’s take a look at some interesting, up-to-date statistics from Softletter’s latest SaaS survey. In the extensive section that deals with the impact of SaaS on product management, we asked three important questions that focus on if, and when, SaaS companies are building into the core of their systems key capabilities that render obsolete much of the current theory on software product management.

The first question is:

Does your product incorporate a “new features or capabilities” request mechanism by customers directly within the SaaS application environment?

As these numbers demonstrate, smart SaaS companies are learning to use their application platform itself as the mechanism for requirements management. (Oh, worried that customers aren’t as smart as you? No problem. Nothing stops you from adding whatever features you want! It’s your product. But in a properly architected SaaS product, you’ll be measured on their acceptance and usage very precisely. Make sure you’re as smart as you think you are.)

Our second questions is:

Does your product incorporate a customer usage tracking analytics system directly within the SaaS application environment

As you can see, SaaS companies are rapidly learning that SaaS products offer potentially unparalleled insight into what, when, and how often particular features within the application environment are used. Combined with integrated reporting, a SaaS provider can quickly build a profile on customer feature usage and acceptance of unparalleled accuracy and timeliness (and do it from the desk).

The final question is:

Does your product incorporate a community creation and management system directly within the SaaS application environment?

As the numbers show, while a significant percentage of SaaS firms are building community into their products, most SaaS companies aren’t, though the longer a company is in business the more these numbers shift to the “Yes” column (for example, firms in business 8+ years answering “Yes” was 32%).

Softletter is confident in predicting that the numbers reporting “Yes” to all three of these questions will continue to rise in the coming years (we expect all three metrics to hit the 80% “Yes” benchmark within three years).

What will the consequences of these changes mean to the world of Agile and its devotees? Well, there STILL won’t be any such thing as an Agile PM because PMs will still continue to not be programmers. But tomorrow’s SaaS PM (or perhaps community manager) will be able to help manage and streamline the provision of the one commodity craved by all Agile methodologies: timely, comprehensive user input and feedback as a product grows and evolves.

And this is where you should be placing your financial resources. Not in useless Agile product management training, but instead in building out, integrating the abilities discussed above, and learning how to leverage your application to take advantage of the unique characteristics of all SaaS products: their ability to aggregate all customer interaction with your product, communicate with all customers, and learn directly by observing and analyzing customer’s working with your system.