In SaaS, product management is essential, not optional

A while back, I had a spirited exchange with someone who took a rather extreme position about the role of product management in software as a service companies. The less polite version: He staked out a silly position - just poll your customers...


A while back, I had a spirited exchange with someone who took a rather extreme position about the role of product management in software as a service companies.

The less polite version: He staked out a silly position - just poll your customers about what to build, and eliminate the PM role altogether - so I felt obliged to refute it. With two additional years of research into SaaS and PM, it's worth returning to that contretemps for a moment.

Then, I argued that PM was necessary in SaaS ventures.

Now, it's clear that PM is not merely necessary but essential.

Product managers are really innovation managers

If the sole responsibility of PM were requirements, as my foil assumed, a poll might replace a person, but only if you had no interest in the long-term success of your company. Polls are extremely useful tools, and it's far better to use them than not to. However, polls have their limitations: most obviously, as a tool for taking the temperature of the customers you have, they tell you absolutely nothing about the customers you don't have yet.

This week, I've already written a little about the need to go beyond polls to use other tools, such as serious games. In an upcoming post, I'll have more to say on the topic. For now, I'll just say that, in both business and politics, voting alone is not the ticket to ultimate success.

If you zoom out a bit to look at the larger landscape of what PMs do, the essential role of PM in SaaS (and cloud in general) becomes even more obvious. That's the basic thesis of my most recently published Forrester research, which looks at SaaS in the larger process of innovation. Inventing technology is laudable, but innovation doesn't stop with the invention itself. Technology companies, IT departments, and the external product-like parts of other companies (web banking applications, interactive marketing tools, etc.) all have a vested interest in convincing people to use their technology. Just ask anyone looking for a reference customer or justifying their IT budget for next year.

Each stage of innovation can end In "game over"

Unfortunately, the latter portion of the innovation process is fairly tricky, and until recently, people treated invention and adoption (as well as other later innovation stages) as two separate processes. They're really part of a single process, which frequently fails after building the invention. In an ISV, customer- and partner-facing groups may have no ability to support a new product for several months after its release. In IT departments, teams often underinvest in UX, so the product "works," but no one can figure out how to use it. Phrases like "business/IT misalignment" are really another way of saying that innovation failed, even if someone delivered the technology on time and on budget.

But again, if you're indifferent to the financial well being of the technology company that employs you, the old model of "build the product, then throw it over the wall" makes perfect sense. It's the path of least resistance, and after the launch event, you can go back to building the next product.

Otherwise, you have to brace yourself for a much tougher challenge, an innovation process that can go pear-shaped at each of several stages:

  • Conceive. Which ideas deserve consideration? Have we missed any good ones?
  • Test. Which ideas are worth pursuing, based on multiple criteria (business value, technical feasibility, etc.)?
  • Build. Are we converting the idea into reality in the most efficient way? Are we building the technology the right way?
  • Deliver. Do we have the means to deliver the technology into the hands of the people who might need it?
  • Adopt. Once they receive the technology, will these people use it?
  • Assess. Looking back on the whole innovation process, what can we learn to make it successful the next time?

SaaS changes innovation
While the job description for product managers may not be exactly the same in every company, no one's definition of product management limits it to just one of these stages. In cases where product managers (the people) don't play a role in every stage, product management (the business imperative) happens in all these stages anyway.

When SaaS enters the picture, the whole innovation playbook changes. The same stages happen, but in different ways. To take one tiny example, SaaS increases the amount of data available about how customers become aware of a product, evaluate it, pilot it, expand its usage, and in some cases, abandon it. If this information exists, someone needs to sift through it, extract the "actionable insights," and chase down the people who can improve each part of the "customer journey." (I like how words like "action" and "journey" add zest to meetings to mundane tasks like sales training and bug triage.) Chances are that, if anyone does this task, it's someone with a product manager title, or something darn close to it.

And that's how SaaS puts new responsibilities on the shoulders of product managers in just one part of one of these innovation stages. (For the rest of the story, read the document.) Even that one aspect of innovation in a SaaS world should be enough to show that it's ludicrous to think of replacing a product manager with a poll, or a Magic Eight Ball, or Koko the chimp. As cloud computing expands, so does the importance of product management.

A final note: Now I'm an application development & delivery analyst

I've recently moved from the Technology Marketing (TM) team at Forrester to the Application Development & Delivery (ADD) team. While my research agenda looks very similar to what I've been doing (including writing about product management), my research documents up to this date may not be available to everyone who has access to the ADD research, as some ADD clients do not have access to the archive of TM documents. For that, my apologies.

On the other hand, the new content, such as an upcoming comparison of PMs, business analysts, and project managers, will be available to ADD customers. Many TM and other types of tech industry customers will have access to the ADD research, too. Meanwhile, I'll be expanding my coverage to include topics like productization (not just product management), innovation beyond ISVs, and the embedding of software as a component of other products. I'm also doing my first Forrester Wave„¢ with Dave West, covering the application life-cycle management (ALM) market, which is as much a rite of passage as it is an interesting research project.

Posted by Tom Gran

Find your next job with computerworld UK jobs