The arguments over SaaS University's "SaaS companies don't need product management" post continues. The original author, has taken the comments seriously enough to answer them, often at length. Unfortunately, he's not helping himself in the process.
Brevity is the soul of wit
To his credit, Chapman has disentangled the issue of product management training from the value of product management:
I'll break this into two parts. First, I think for a SaaS company, all
the current product management courses are mainly irrelevant and you
should save your money. In next week's post, I'll describe where I think
PM is going. I do think that SaaS will greatly change the role and
scope of what PMs do, and I wonder if the title will exist in the near
future.
I've certainly been guilty of trying to cram too many points into one big blog post. (Watch me give into that temptation again in this post.)
Having addressed the confusion, Chapman should have stopped there, and told people to wait a short interval for his next post. Instead, he started to make his argument in bits and pieces through the comments section. Neither the bits nor the whole picture are very convincing.
Is that really Agile?
It was inevitable that Agile would enter the picture at some point in this discussion, particularly given the close linkages between Agile and SaaS. Unfortunately, in trying to use Agile to prove his point, Chapman instead highlights the gaps in his understanding of Agile. Here's a prime example:
But Agile was never intended for PMs. It was intended for DEVELOPMENT groups to better communicate with users/customers! If you can learn and communiciate directly with the community, what value does the PM bring to the process?
The rebuttal to this vulgarized version of Agile was sitting within arms reach, and took me only a couple of minutes to look up. Jim Highsmith, one of the authors of the Agile Manifesto, has a lot to say about product management's role. In the section of Agile Project Management in which he paints a favorable picture of feature-based development, Highsmith says:
Using this style of planning, product managers control which features are included in the product. Development engineers control how features are designed and implemented. Product managers wouldn't have the authority to say, for example, "We're running behind, let's cut testing time." Instead, they could only say, "We're running behind; let's cut featurs 34 and 68." Similarly, the development team couldn't arbitrarily add a feature
because "it would be way cool." Obviously this delegation of
responsibilities undergoes discussion and debate, as product managers
may have suggestions about (but not final authority over) how products
get built, and development engineers may make suggestions (but not
decisions) about potential features
Clearly, Highsmith sees PM as the prime authority on the business value of the features themselves. (See below for a few words on that business value.) Product managers appear thoughout Highsmith's book.
The Framers of Agile didn't set down a formula for defining the relationship between the product owner and the product manager. In practice, approaches vary widely; in many cases, the product manager is the product owner. However, even if you overlooked how Agile teams actually work, it's pretty clear that Agile theorists vested some PM-ish responsibilities in the product owner role.
For example, Ken Schwaber, in Agile Project Management With Scrum, says that the product owner, among other responsibilities, creates "the project's initial overall requirements, return on investment (ROI) objectives, and release plans." If weighing business goals against the feature list, both of which the product owner owns, isn't a PM function, what is?
I'll be anything you want me to be
Chapman's argument seems to be based on the assumption that, if your customers want you to build a feature, that feature will have business value for you. (Therefore, you can automate the process of selecting them, eliminating the PM as "middleman.") That reductionist formula is flatly wrong.
I covered a lot of the reasons why in my earlier post. I'll add one more critical point here: Customer demand is not the only criterion for building a feature. It seems a bit ridiculous to have to say that, but it's apparently necessary, in this case.
Giving customers the features they want is not an end in itself. By meeting demand, you hope for something to happen. More people may buy your product, and you may retain more customers. These are business goals that enhancement requests are supposed to help achieve.
And these definitely are not the only goals. A new feature may sharpen the contrast with a competitor. Your current customers might not be asking for the feature, but it might be critical for entry into a new market. You might build the feature just to look like a cool company brimming with good ideas. None of these goals would be attainable if all you did was put product decision-making on autopilot, the way that Chapman advocates.
These aren't the developers you're looking for
The really weird thing about Chapman's proposed strategy is, I can't imagine any development group agreeing to it. The difficulty of building a feature has no relationship to demand for it. Release planning, therefore, is a negotiation. How can we meet the objectives of the release without pushing out the schedule too far? Or introducing too much complexity or instability in the product? Or creating long-term maintenance headaches?
On the other side of the scale from development costs, of course, are the business benefits. To find the right balance, product teams examine different scenarios, argues their pros and cons, and makes a strategic bet on whichever set of features make the most sense.
These discussions feed on information. Some of it comes from the outside world, and go beyond just how many users have voted on a feature. (See the previous post for examples.) Some of the relevant information comes from within the company, such as the development risks, or how various corporate goals affect product decision-making.
It's difficult to imagine developers embracing Chapman's "robo-PM" strategy, which effectively eliminates a lot of the data needed to mitigate risks. Companies reward developers for executing, executing, executing, not mumbling excuses for why they designed a feature the wrong way, or misinterpreted what customers really wanted.
Playing "Telephone" with your customers
Chapman has an almost child-like faith in the literal truth of what customers say:
Again, consider an environment where you have developed a
strong SaaS customer community. You don't need a PM to "sense" the
market; you can sense it directly. Your community will be quite happy to tell
you about its problems. And I believe THEY'LL be driving prioritization! Why do
you need a keeper of a tick list when your community can tell you what it wants
and what it's doing in near real time.
If, through some electronic medium, you listen to customers propose features, comment on them, and vote for them, you are not engaging in a Vulcan mind-meld with them. You're getting very valuable information, but it's the same species of raw data that leads superpowers to invade countries they don't really understand.
Customers can be unclear. They may have ulterior motives that shape their enhancement requests. They might be talking about an imagined implementation of a feature, instead of explaining the actual need for the feature. Interpreting the information is critical, and it takes effort, maturity, experience, judgment, and imagination.
By the way, you're hearing why the "social media as a resource for product requirements" study I wrote turned into three separate documents. Alas, if only product decision-making were so simple that you could subscribe to some RSS feeds, set up some polls, and wait for further instructions.
Yer bein' too uppity fer yer own good
What's very clear from Chapman's responses is that he doesn't have a very high opinion of the value that PMs can provide:
Hakan, PMs are not upper management; let's keep that in mind. All responsibility; no authority; that's the traditional PM laments, and it's a middle manager's mantra.
+++ Latent markets not using your product, new segments, new verticals, business unit strategy, collaboration and communication with different stakeholders within a company, and many other areas needs someone to take the reigns and own. +++
But PMs don't do that. PM's are middle managers. PMs are almost never hired when a company is young; PMs are brought in after a company has reached a certain level of maturity. Vision is usually owned by the company founder. Collaboration? Can't the community collaborate? BU strategy? Owned by the BU head? (Not a PM.) Strategy? The job of the CEO, no? New verticals.
Chapman is talking about a stereotype that may be prevalent in many companies, but is no more accurate than Charlie Chan was a fair depiction of Chinese-Americans. In fact, in many companies, PMs are not middle managers. They have both responsibility and authority. One Vice President of PM I recently interviewed told his peers in Sales and Marketing, "If I do my job right, I'll help you cut down the sales cycle and increase the revenue per purchase." And that's exactly what happened.
In fact, PM is becoming more strategic, not less. An increasing number of PMs report directly to the CEO, instead of being subordinate to Development or Marketing. They may not set grand strategy, at a corporate level, but they do set product strategy, and in many cases, market strategy (i.e., which markets or solution areas to pursue).
It's hard to argue with a stereotype, because it's usually deeply ingrained in how people see the world. All I can do is offer the data from our research into product management and product marketing, and cross my fingers that the stereotype collapses.