A recent post at SaaS University ("Where CEOs Go For SaaS Higher Learning") argues that SaaS companies don't need product managers. Here's a quick summary of the argument.
- Product managers maintain the prioritized list of features.
- SaaS applications can ask the users to vote, within the application, on what features they want.
- Therefore, product managers aren't needed.
This argument is based on such a rich smorgasbord of fallacies that it's hard to decide where to start. I'll just elbow my way into the buffet line of bad assumptions at the point where the features are spread out on the table, waiting for people to select the juiciest among them. Here's how Rick Chapman, the author of this post, depicts the process of defining and prioritizing features: The
tick list is traditionally gathered from the product manager's
imagination, development's imagination, the CEO's imagination,
competitive analysis, press reviews, and, most importantly (and often
only theoretically) from user requests. It is the job of
the PM to collate these new features, prioritize them, and fight
(persuade) development that the PM is accurately reflecting the wishes
of the customer in terms of the added functionality needed by the next
version of the product.
Which begs the question, How do you figure out if you're "accurately reflecting the wishes of the customer" if everything runs on autopilot? Letting customers vote on features is important, but it's no substitute for understanding what customers really need, or who among them you should heed.
The tick list is traditionally gathered from the product manager's imagination, development's imagination, the CEO's imagination, competitive analysis, press reviews, and, most importantly (and often only theoretically) from user requests. It is the job of the PM to collate these new features, prioritize them, and fight (persuade) development that the PM is accurately reflecting the wishes of the customer in terms of the added functionality needed by the next version of the product.
Making yourself clear
Say you propose Feature A. The one-line summary reads, "Streamline the process of imanetizing the eschaton." Now, assuming that your customers understand what the eschaton is, even if they're using it every day in your SaaS application, you're still hardly giving them enough information to know what streamlining really means. Are you proposing to cut down the number of clicks needed to get through the imanetizing process? Make it easier to learn how to use the imanetization management features in your SaaS application? Make the application run faster?
Crafting a good design
If you think that I'm being unfair by making the original feature proposal too vague, let's assume for the moment that the customers completely understand the importance of this feature. How then do you decide what the design constraints are? What might seem, to the developer writing the code, like the best eschaton-imanetizing feature ever conceived, might turn out to be baffling to the end user, or perhaps not all that helpful. Without any clear sense of the use case, the business problem, and the user, you're as likely to make bad design decisions as good ones.
Listening to the right people
But let's even put that risk aside for the moment, and focus instead on the voting process. The people doing the actual eschaton imanetization might have very strong feelings about the need for streamlining it. Unfortunately, these users may also have no impact on the business success of your SaaS application. For every 10 end users, there may be 1 manager that wants a new report instead of the streamlined imanetization. The manager may be the one who makes the buying decisions, and may be royally POed if you don't give them what they want, even if they're in the minority of voters.
Going after a bigger market
And what about market development? Our hypothetical SaaS vendor has already attracted a particular kind of company--say, medium-sized eschaton brokerage firms in the continental United States. But is that the ultimate market that you, the SaaS vendor, want to reach? By following the direct feedback of current customers, you may be missing the features that are important for the next market you want to enter, where neither streamlined imanetization or improved reporting may be the cost of entry.
Letting PM focus on the customers PMs are
traditionally supposed to spend a great deal of time with customers
learning what they like and don't like about the product they're
responsible for. The reality is that in most companies, most PMs learn
a great deal about how to manage a tick list, communicate the tick
list, prioritize the tick list, fight for the tick list, write the MRD, revise the MRD, examine the PRD, fight about the PRD, etc., etc. This doesn't leave much time to spend with customers.
As startlingly naive as this view of enhancement requests might be, the bigger error of this post is its conflation of bad product management with all product management. Here's how Chapman describes the role of PMs as voices of the customer:
The companies in which Chapman worked may not have granted PMs the time to research customer use cases, market characteristics, buying behaviors, and other critical topics. However, that's hardly true of all technology companies.
PMs are traditionally supposed to spend a great deal of time with customers learning what they like and don't like about the product they're responsible for. The reality is that in most companies, most PMs learn a great deal about how to manage a tick list, communicate the tick list, prioritize the tick list, fight for the tick list, write the MRD, revise the MRD, examine the PRD, fight about the PRD, etc., etc. This doesn't leave much time to spend with customers.
For example, in the soon-to-be-published Forrester Leadership Board on product management best practices, a VP of product management describes how he writes time spent with customers into every PMs quarterly goals. Other PMs I've interviewed since taking this job as an analyst have similar stories to tell. Either they have taken the initiative to protect the time needed for their research, or their management has made it a bigger priority, fearing the bad consequences of misguided product decisions. Chapman's argument smacks of, "Well, we've never given the PMs the chance to do the most important part of their jobs, so we'll just get rid of them altogether."
Understanding PM's to-do list
Maintaining the prioritized feature list is hardly the only thing PMs do. The list of tasks that PMs perform may vary across companies, but it's always a big list. Sales and marketing support, training, release management, customer reference recruitment, social media outreach, press and analyst briefings, release management--someone has to do these sorts of tasks.
I might have my disagreements with particular approaches to teaching product management. However, Pragmatic Marketing, AIPMM, et al. don't limit their description of product management to "the tick list."
Since Chapman begins his post with the statement, "If you're a SaaS company with product managers and are considering sending your PMs to one of these courses, I wouldn't bother," it makes me wonder how much he really knows about these organizations, or the curricula they present. Nevertheless, even if these outlets for PM training were to prove completely worthless, that's not the same as saying that product management is worthless, too.
[Postscript: The role of PM does change in SaaS organizations, but it hardly disappears. If you're a Forrester client, you can read the complete report on what PMs actually do in SaaS companies here.]