If a product manager is the custodian of a business, and if the core responsibility of the product manager is to make sure that business is successful, it's incumbent upon the product manager to understand what the business needs to be successful. I think that's a fair position and a fair expectation to levy on the PM team.
But for a PM used to working in an on-premise model, delivering software as a service will alter large chunks of their familiar playing field. Some of these changes will stem from fundamental shifts in the business model, others from shifts in responsibilities towards the vendor, and still others from changes in customer expectations based on their experiences with other solutions. Product managers need to understand these shifts, both in general terms and in terms that are specific to their business (market/industry/company/solution).
So how are things different in SaaS? Let me tee up some major topics, and I'll drill into them in more detail later. In many cases there's a lot to go into, and far more than can be covered in one post:
Business model: If I can generalize for a moment, it's common for on-premise solutions to follow a license/maintenance pricing model, and for SaaS solutions to follow a subscription model. Regardless of how software is delivered, these two pricing models create very different revenue streams, and these very different revenue streams will create very different lenses with which your organization will view customers and their satisfaction. This one isn't a SaaS issue per se, it's a pricing model issue, but its impact is huge and PM needs a deep understanding of the differences.
Operations: With a SaaS model, the vendor is essentially assuming all responsibility for delivering their solution to the client. The customer's IT organization doesn't own those "five nines" of up-time -- the vendor does. So there is no room to be anything but flawless in operational execution. If you are going SaaS, you will need a stellar head of SaaS Operations, and they will need a seat at the Product table equal to that of the heads of Development, Quality and Product Management.
Risk: When an on-premise upgrade is released, the risk associated with bugs is relatively low. Even if an egregious bug is found in the field, the generally slow adoption of new releases will ensure that there is plenty of time to address the issue before a large set of users is affected. In a SaaS model, new releases will more commonly be deployed to all customers at once, or to "pods" of many customers on a specific schedule. Bugs in the code, or problems in the configuration of the software or infrastructure will affect many users across many customers in short order.
Requirements: With SaaS comes the opportunity and responsibility to rethink many aspects of your customer experiences around the software, and alignment around which of these you will pursue and when is important early on. In addition, there will be entirely new drivers of requirements stemming from your SaaS Operations team, and their needs. And changes in the business model will drive still other requirements aimed at understanding usage and satisfaction. There's just so much to think about on this score -- nice, rich topic on its own!
Enginering: Changes in requirements and deep participation from Operations will alter what Development needs to create, and the elevated risk profile may well require greater consideration of and respect for the quality organization, depending on the discipline and culture in place. SaaS teams generally can't afford for the Quality team to be a poor cousin to Development, and the true "rock star" coders should be the ones who deliver quality, not just innovation. There's a really good case to be made that agile development and SaaS should go hand-in-hand, as well. I can certainly chime in on that, but I don't consider myself an expert in development methodologies, and will need to disclaim what I say, there, when the time comes.
Marketing: SaaS can change the nature of the conversations technology companies have with prospects. Without having to convince IT our solutions are fit for their infrastructure, we as marketers can relax about how clever our engineers were in building the things, and focus on discussing the business value of our offerings with buyers. There is still a need to engage with IT, sure. But it's a different and toned-down conversation in many cases, and rather than filling our websites and data sheets with boasts about our technology, we can focus on the benefits prospective customers can expect if they subscribe. And with SaaS, marketers also get new opportunities, channels and obligations to communicate with customers, and need to be ready to capitalize on and satisfy thess.
Selling: There is an opportunity with SaaS to solve problems in such a way that using a sales force engaged in a typical enterprise sale will prove unnecessary. But whether that opportunity fits with your problems, solutions and organization is another question, and regardless of the answer, you need clear alignment internally on this point. In fact, a vision of how you want to bring your SaaS solution to market ought to be at the start of the project.
Implementation: As with choosing an approach to selling, you ought to establish assumptions about how your system will be provisioned and implemented very early on. Whether you want customers to be able to self-service on one or both counts, or whether you prefer to have a services engagement of some kind will drive a big set of requirements and an even larger set of design decisions along the way. And if the goal is to ultimately move to a self-implementing model, it can be really difficult to get there if the system wasn't envisioned with that goal in mind -- it's a lot easier to complexify something that's simple than simplify something that's complex.
Education: I'm convinced that the right thing to do for any piece of software is to hire great designers and make the user experience so good that documentation and training become largely unnecessary. But where it is necessary, SaaS introduces options for innovative ways of helping customers that aren't practical with other delivery models: An ongoing library of video tutorials, for example, delivered based on customer usage and feedback, with links from the appropriate screens added as the content is developed. The possibilities are really endless, as are the sources for inspiration out there (the b-to-b and b-to-c SaaS solutions we all encounter in our lives).
Support: Online support models have been around for a very long time, but in a SaaS solution, your customer is by default already connected to your company and its resources, every time they log into the product. That opens up the possibility for embedding support resources and experiences into the application, rather than requiring users to stop what they're doing to go off to some other place to get help. The definition of "support" is also open to interpretation, with community, eductional, online chat, Skype and other options at your fingertips.
These are really just a few of the areas in which product management needs to be ready to provide leadership to the rest of the organization. As I start to peel the onion on these and other subjects, I'd love to hear other thoughts and ideas, as well. Thanks for reading and sharing, as always.
All for now,
J
No comments:
Post a Comment