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.
In contrast, on-demand shortens the path from invention to adoption, which makes it easier for people at the beginning of the value team to understand the people at the end, as long as they make the effort to do so. Some vendors, such as RightNow, Salesforce, and Rally, have made the investment in building the necessary information collection mechanisms. Without violating any customer's privacy, tech vendors can collect some extremely valuable information. The actual usage of a new feature, as compared to its expected usage, tells you how well you designed that feature, so you can go fix it quickly. Usage statistics also tell you how accurate the assumptions behind the prioritization and design of the feature were, which can lower the probability that you will have to re-engineer anything.
These statistics can provide equally valuable information about how quickly customers embrace or adapt to new releases, and how that process works. Through communities, users can add further depth and context to these behaviors. Mature SaaS vendors, such as NetSuite, then arrive at a tolerable interval of a few months between releases.
The new delivery model also puts the tech vendors themselves to the test. Rather than waiting for IT to complete the implementation, SaaS companies can deliver something whenever they want. This opportunity forces organizations to pose a painfully self-critical question: Why can't we deliver faster than we do? A harsh light shines on many parts of the business, not just the development organization. If there are problems in development, teams can change processes to achieve a faster cadence, with a more predictable outcome — which, of course, is why the rate of Agile adoption among SaaS vendors is relatively high. With no cushion of time between the release of new technology and its implementation in a customer's data center, the staff of the technical support and consulting groups need to figure out how to get readier faster.
When I started in the technology industry, everyone would have answered the question posed at the beginning of this post (How often should we deliver something new to our customers?) with a fatalistic shrug. Today, many SaaS vendors can give you a prompt, credible reply. If that's not progress, I don't know what is.
[Postscript: A few weeks ago, my posts were all about Agile. In the next couple of weeks, expect to hear a lot about on demand a.k.a. cloud a.k.a. SaaS, PaaS, etc.]