by Merrill R. (Rick) Chapman

We’ve been seeing a great deal of industry press these days discussing “the Agile Product Manager.” There are a plethora of new books, new training courses, and new “tools” that are supposed to transform yesterday’s slow and sluggish product manager into a new sort of sleek, streamlined being, something akin to Tony Stark in an Iron Man suit streaking through the sky on a mission to save the software industry from the Sloth Monster and pull trapped revenues and profits from the Slough of Despondency.

Unfortunately for all involved, these articles, training courses, and tools are a waste of time (and money) for SaaS companies.

Before going further, let’s get to the main points of this article right away

• Agile methodologies were never designed nor have they evolved in any practical way to encompass the job of product managers.
• All the training programs that you may have been reading about that purport to teach your product managers to be “Agile” or “work” in an Agile environment are pointless and should be avoided. There are other areas of your SaaS business where you need to be spending your money (we’ll discuss where later on).
• There is no such thing as an Agile product manager (though as SaaS firms continue to incorporate community management and analytics into their applications, it will be possible for the SaaS product (or community) manager of the future to provide high-quality information from your customers on a continuous basis that will help fuel effective Agile product development at your company).

Now, before proceeding any further, I’d like to urge you to download the following E-book from Pragmatic Marketing, the leading firm in the industry currently offering product management training courses. It’s not really a book, more like a PowerPoint on steroids, but it makes the case for “Agile” product management. Unfortunately, the case it makes is incoherent and illogical, but I think it’s the best that can be done with the topic and it’s not a long read. Download it from the link below:

Click Here to Download Living in an Agile World

A Brief History of Agile

Given the title of this article, I think a brief history of the Agile movement is in order. Agile methodologies were conceived as a reaction against the development processes that dominated the software industry from the 50s through the mid-90s. Traditionally, software firms would develop a product, release it, then have a series of big sit downs and meetings to discuss the capabilities the next version of the product should possess. These sit-downs and meetings were typically accompanied by heated discussions, temper tantrums, political knifings, assassinations, underhanded deals, betrayals, blackmail, and other forms of bloodletting normally associated with high-tech corporate life.

The end result of this cyclical Apocalypse Geek was an agreed upon list of requirements that would be incorporated into the next version of the product. Work would begin, and over the next 12 to 36 months or so, a new version of the product would appear. The cycle would then repeat itself and so things proceeded along. This approach to development is often referred to as a “waterfall development,” no doubt a reference to the rivers of corporate blood that spilled down the aisles and flowed down the steps of corporate HQs while the new requirements spec was under development.

An interesting adjunct to this history is the introduction in the late 70s/early 80s of the idea of the software product manager (PM). The idea and title were lifted from consumer companies such as Procter and Gamble, though unlike PMs at these firms, their software counterparts rarely had P&L authority over “their” products. In the software industry, the primary function of PMs was to:

• Coordinate information about product development processes and progress between the various functional groups associated with the product’s development (development, QA, documentation, sales and marketing, etc).
• Manage the requirements list (tick list herding) and, in theory, ensure that at least X% of it was incorporated in the next release of the product.
• Talk to customers and, hopefully, transmit their opinions and desires to the rest of the company.
• Execute or assist in executing various marketing programs, assist in pricing the product, and in general make themselves useful in dozens of undefined and measurable ways.

(Another powerful, unspoken reason was that upper management, which dislikes holding itself accountable and is afraid to terminate programmers because they’re the only ones who can build the next product and understand what went wrong with this iteration, wanted someone to fire when something went wrong.)

Things thus proceeded apace in the world of software until 1995, when word spread throughout the industry of the C3 project. C3 stood for Chrysler Comprehensive Compensation System, a software development project launched at the carmaker that was an attempt to build a new, complex software application (a payroll application that would replace several existing systems at the company) in a new way using what was christened an “Agile” system called “XP” (extreme programming. Up till 2010 the system was still in use, though its use has faded to almost zero today.

XP was an attempt to replace waterfall development approaches with something new. Instead of a vast requirements framework created after much corporate sturm und drang, development would focus on short, highly focused periods of development during which an actual user would sit side by side with the programming group and provide instant feedback on the code being created by the developer(s). The Holy Grail of this first Agile project was to develop code more quickly with fewer bugs that adhered closely to the needs of actual users. All Agile methodologies seek this same Grail.

C3, objectively analyzed, was a failure; after five years the product wasn’t completed and the development effort was terminated (one reason being that the poor schnook who was picked to be the user sitting next to the programmers literally broke down). But the industry thought a great many lessons had been learned and new Agile methodologies and theories were introduced, debated, and argued over with a sometimes religious ferocity.

One point that all these methodologies agreed upon, however, was the need for intense user involvement during the development cycle. Since real users, when approached about sharing cubicles with programmers during Agile development cycles tended to pretend to suffer from epileptic fits when the topic was brought up, then, when pressed, made loud noises about the 14th Amendment to the Constitution and the prohibitions against involuntary slavery, this idea was dropped. (There were rumors about an abortive attempt to breed a race of clones to fill in, but the concept seems to have gone nowhere.)

Now, this was a problem, because ALL Agile methodologies crave direct customer involvement in the development cycle. What to do, what to do.

Then, one day, an innocent product manager headed down the wrong aisle in their company’s office complex, ignored several warning signs, and found himself strolling past a row of programmer workstations. The desperate coders looked up, spotted the luckless functionary, and had an epiphany. There was a quick ambush and a brief struggle, followed by some fast DNA resequencing. When the PM finally fought free of his captors, he discovered to his horror that the letters “Agile Customer Stand In” now appeared on his forehead in dayglo lettering. This DNA reconfiguration soon went viral and PMs everywhere were now expected to represent customers in Agile frameworks. Which they were happy to do when they weren’t doing all the other things they were expected to do. Which was most of the time.

Now, this isn’t wasn’t as big a problem as it sounds because the flock of those worshipping at Agile alters remained fairly small despite the loud sounds the movement made. That’s because, as we noted in the previous issue of SaaS U Journal, while it was fine to discuss how to rapidly and incrementally improve software products, the underlying infrastructure of the desktop and client/server systems aren’t a great fit to Agile. These platforms still adhere to the traditional 12 to 18-month development cycle; in such a milieu, development agility isn’t that critical. Waterfalls will do.