I'm working on a report about the role of PM in an on demand setting (SaaS, PaaS, and all the other aaSes). As often happens in discussions about PM, the role is a window into many bigger issues. Since their responsibilities span both business and technology, product managers and product marketers find themselves in the middle of many fundamental questions for technology vendors, such as, How often should we deliver something new to our customers?

That question has two sides: (1) how often do customers want to receive something new, and (2) how often can the vendor deliver it. Both questions can be difficult to answer. Customers often want tech vendors to deliver value faster, but they also complain if the changes happen too fast. Vendors know that they could deliver new technology every time they do a build, but they also know that the entire company (sales, marketing, support, etc.) won't be able to keep up at that pace. There must be some golden mean between the pace of technology production and consumption, but what is it?

By shortening the distance between producers and consumers, on demand, and SaaS in particular, has made it easier to reach a meaningful answer. The on-premise model creates a very long value stream between the development team at the beginning of the technology adoption process, and the users at the very end. In fact, adoption is, at best, a blurry image on the distant horizon of the development team's field of vision. Since the success of a development team's work products depend on its adoption, lack of information about adoption is not an information gap, but a yawning chasm.

A lot of my recent research – about SaaS/PaaS, Agile tools, requirements tools, and innovating with your channel – share a common conclusion: successful technology vendors see integration as more than just a necessary evil. Here's why.

Business problems drive technology adoption 
You can see this principle in action in the requirements tools market, which in the last decade has grown larger and more complex. Teams use these tools to address more than one type of requirements-related challenge, so it's easy to see why the tools themselves are now as diverse as as Micro Focus (née Borland) Calibre, Atlassian JIRA, Ravenflow RAVEN, and VersionOne's Ideas Management module. If your problem is, "People don't like using our product," you might look at a visualization tool like iRise to shorten the feedback loop, leading to better design decisions. If, instead, your problem is, "We don't have a good business justification for what we build," you might look at IBM Rational DOORS to evaluate the pros and cons of alternative scenarios for what goes into the next release.

Within 24 hours, InfoWorld published two seemingly unrelated articles. One covered HP's announcement of its intent to acquire Palm, which led people to speculate aloud, "What the heck were they thinking?" The first part of the article spent a couple of paragraphs musing about how this move might or might not help HP's interest in the slate computer market. The path from acquiring Palm to becoming an iPad competitor isn't very clear, however, so maybe the real point has nothing to do with slate computers. We can't get enough of talking about slate computers, but what if Palm's products have some potential connection to HP's existing portfolio? Crazy idea, I know.

The next day, InfoWorld published another article with the acidic headline, "Smartphone management becoming a nightmare":

Smartphones and mobile devices are becoming a nightmare for IT shops to manage, with users carrying multiple types of phones with different operating systems and expecting access to email, video-conferencing, and various types of corporate applications.

In other words, IT departments struggling with these standardization efforts might want to talk to a company that can help. Say, someone with a lot of products and services for solution areas like cloud computing, application transformation, portfolio and asset management. It'd be great if said vendor had mobile technology that factored into these larger IT infrastructure concerns.

Oh, yeah...

Next Wednesday, May 5th, fellow product management/product marketing blogger and Informatica PM Saeed Khan and I will be having a conversation, live via teleconference, about the two sides of PM metrics:

• Metrics by PM. What are the important metrics about a tech vendor's business and technology that should PM maintain? This question strikes at the heart of PM's core responsibilities, making sure that a tech vendor's products and services help its business, and vice versa.
• Metrics about PM. Want to start a lively conversation? Ask product managers and product marketers about the metrics used to measure their performance and contribution. These metrics do more than just point PMs in the direction of quarterly goals. They also communicate within the company the value of what PM does.

Saeed always has sharp insights on these sorts of topics (which is why you should be a regular reader of the On Product Management blog, by the way). This call is a real conversation, not a one-way blabfest, so we're definitely looking for your questions and comments during the call. Expect a mix of observations about the state of PM in the tech industry, as well as best practices developed through hard experience.

The call is scheduled for next Wednesday, May 5th, from 8:30 to 9:30 PDT / 11:30 to 12:30 EDT. If you're interested in attending, send an e-mail to Steve Davidson (sdavidson@forrester.com), who runs the Technology Product Management & Marketing Council here at Forrester. Look forward to talking with you next week.