(If you're interested in learning more about the new model of product management discussed in this posting, Patrick Fetterman of Plex, a SaaS-based ERP provider, will be discussing how his company has replaced the concept of product managers with community management at Softletter's upcoming SaaS University Conference in Washington, DC, July 20-22. Patrick was our top-rated speaker at our program in Dallas in January. Click here to see the SaaS U in DC agenda. This article also references data and uses charts from the upcoming Softletter 2010 SaaS Report; click here to download the Softletter 2010 SaaS Report Sampler.)
I'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 products 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 unmeasurable 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, 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. The system is still in use and is the principal Agile methodology at 10% of SaaS firms (please reference the table/chart below).
What is the principal Agile methodology used by your development group?
| FDD (Feature Driven Development) |
18% |
| Iconix |
1% |
| Lean Software Development |
15% |
| RUP (Rational Unified Process) |
5% |
| Scrum |
45% |
| XP (Extreme Programming) |
9% |
| Other |
7% |
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 sometime 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 concpet 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.
This has changed with SaaS. Take a look at the results from our 2010 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)t?
| Less than once a year |
7%
|
| Once a year |
15%
|
| Twice a year |
16%
|
| Three or more times a year |
21% |
| We do not have a "timed" or set release schedule; we release new features as they are ready |
27% |
| Other, please specify (four respondents said "monthly") |
5% |
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 four 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 the 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 lof 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 mangers. 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 staffmembers 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 manger" 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 2010 SaaS Report (due for a week of June 6th, 2010 release). This is the fourth year of this report, and the current edition was based on 140 top SaaS executives participating in our 119 questionnaire. 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?
| Yes |
38% |
| No |
33% |
| We are planning to add this capability |
29% |
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?
| Yes |
49% |
| No |
30% |
| We are planning to add this capability |
21% |
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?
| Yes |
18% |
| No |
62% |
| We are planning to add this capability |
20% |
As the numbers show, while a significant number 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 manger) 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 were 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.