Quality matters much more in a SaaS offering than with an on-premise offering.
QA managers may disagree with me -- after all, it's their job to get quality right regardless of the delivery model. But in my experience, SaaS gives a vendor far less room for sloppy quality than with an on-premise solution. Some of this is really a question of velocity. With most SaaS solutions, an upgrade is done for all customers at once or for large blocks of customers in server "pods", which makes it a fast and efficient model for putting new capabilities into customer hands. Unfortunately, it also means you're putting bugs into your customers' hands quickly and efficiently!
In an on-premise model, when a new release is shipped, there's generally a nice, gradual roll-out, as customers take the upgrade on their own schedule. If 10% of a customer base adopts a new release in the first month or two, that's not a bad take-up rate at all, and problems will tend to start trickling in, not gushing. That gradual pace often gives the vendor time to fix reported problems before too many customers are impacted. And that's often why customers choose to wait, of course -- give it a couple of months, and someone else will suffer through the release's teething pains.
But with a SaaS model, the entire installed base may go to bed on one release, and wake up to another. If there are quality problems, there are no gradual roll-outs -- no early adopters to find the problems on behalf of the rest of the pack. The effects of poor quality will be multiplied, accordingly -- from Support, to Engineering, to Account management to the Executive team. And remember, delighting customers and securing renewals are the name of the game with SaaS. Poor quality, in this case, can be terminal.
There are many ways to keep quality problems at bay. But I think the most important is cultural. QA is often under-resourced relative to Development, and it's not uncommon for developers look down their noses at their QA counterparts, instead of looking to them for partnership. An organization serious about stamping out quality problems could do worse than to look for and eliminate these two causes (I'm betting they'll be found more often than not).
As Product Managers, we need to champion that cause, and also acknowledge our own contribution to quality problems. It's tempting to ask for one more feature, change or bug fix late in the game. It's easy to look at our backlog of enhancement requests and conclude that we can't live without way more than can reasonably be done in a high quality manner. We need to remember that the software has to work, and work well. There are no more important requirements, and shame on us if we put the business at risk for something lesser.
There's a good case in here for agile development approaches, as well -- more on that another time.
All for now,
J
Sunday, November 7, 2010
Tuesday, October 26, 2010
Who Owns Renewals?
For a company with a traditional on-premise license/maintenance pricing model contemplating a shift to a subscription business, the revenue model changes in several important ways. Rather than getting a big license fee up front and a small annuity, the initial value of the deal drops, the cost of servicing the account goes up, and the annuity increases. Making money here depends on delighting customers and getting them to renew multiple times. And once you've got a base of happy customers, the bulk of your revenue will come not from new sales, but rather renewals. I've talked about this already, I know, but it's a huge conceptual shift for a company used to living on new business.
So how to make sure customers renew? It really starts with ownership and accountability -- ownership of and accountability for revenue. Who owns revenue? Typically that's Sales.
The shift in the revenue model puts the VP of Sales in an interesting position. A successful SaaS/subscription business will eventually value farmers more than hunter/gatherers, because successful farmers will represent the main source of revenue. Most of the VPs of Sales I've ever known were principally hunters who were used to building teams of hunters.
But if they want to keep their stature in the company as the executive responsible for revenue, these folks can't just be the VP of Sales -- they have to be the VP of Revenue -- of Sales and Renewals. They need to think just as hard about how to be absolutely sure that customers are delighted and will renew, as they do about how to win that next deal. Or even harder. And they need to be prepared to organize their department accordingly, with rock-solid account management teams whose job it is to ensure that the revenue keeps flowing from happy customers year-over-year.
This is a pretty big change in role, and it's not one that every VP of Sales will immediately understand, or be well-suited to. And if they're not up to it, the responsibility may better fit with a VP of Services or client care or something. The big problem I've seen with this approach is that the potential for conflict is greater when hunters and farmers report into two different departments, let alone two differnent teams. Comp plans can work out some of the conflicts, but there's no substitute for having teams that can work well and closely together.
Where have you seen this responsibility land, and how did it work out in your case? What were the challenges and advantages of the approach?
Regardless of where this lands, ownership and accountability are crucial to success. As PM, you're at the hub of making sure the organization is ready to make your product financially successful, and it's important to drive this issue to conclusion as you're preparing your GTM plan for your SaaS/Subscription product. If you're not confident in the ownership, the incentives, the staffing plan or the accountability, neither should you feel confident in the long-term financial prospects of your product. Talk to your CFO, the VPs of Sales and Services -- the CEO if you have to. Whatever it takes -- get this right.
All for now,
J
So how to make sure customers renew? It really starts with ownership and accountability -- ownership of and accountability for revenue. Who owns revenue? Typically that's Sales.
The shift in the revenue model puts the VP of Sales in an interesting position. A successful SaaS/subscription business will eventually value farmers more than hunter/gatherers, because successful farmers will represent the main source of revenue. Most of the VPs of Sales I've ever known were principally hunters who were used to building teams of hunters.
But if they want to keep their stature in the company as the executive responsible for revenue, these folks can't just be the VP of Sales -- they have to be the VP of Revenue -- of Sales and Renewals. They need to think just as hard about how to be absolutely sure that customers are delighted and will renew, as they do about how to win that next deal. Or even harder. And they need to be prepared to organize their department accordingly, with rock-solid account management teams whose job it is to ensure that the revenue keeps flowing from happy customers year-over-year.
This is a pretty big change in role, and it's not one that every VP of Sales will immediately understand, or be well-suited to. And if they're not up to it, the responsibility may better fit with a VP of Services or client care or something. The big problem I've seen with this approach is that the potential for conflict is greater when hunters and farmers report into two different departments, let alone two differnent teams. Comp plans can work out some of the conflicts, but there's no substitute for having teams that can work well and closely together.
Where have you seen this responsibility land, and how did it work out in your case? What were the challenges and advantages of the approach?
Regardless of where this lands, ownership and accountability are crucial to success. As PM, you're at the hub of making sure the organization is ready to make your product financially successful, and it's important to drive this issue to conclusion as you're preparing your GTM plan for your SaaS/Subscription product. If you're not confident in the ownership, the incentives, the staffing plan or the accountability, neither should you feel confident in the long-term financial prospects of your product. Talk to your CFO, the VPs of Sales and Services -- the CEO if you have to. Whatever it takes -- get this right.
All for now,
J
Thursday, October 21, 2010
Feature Boy and Demo Girl
Maybe 10 years ago I attended the Pragmatic Marketing course along with a Marketing team I was then part of. I enjoyed it and found it worthwhile, but mostly in the context of the whole department getting on the same page about what our roles would be in launching products. Beyond that, it was a good reminder of best practices and there were a bunch of great tips in there.
One of the cautions Steve Johnson (our inimitable instructor) gave us was to avoid becoming Demo Boy or Demo Girl -- to remember to keep our eye on the market, and not to let the Sales team bleed us dry with building and delivering demos. Good advice, a decade later. Since then, I've either heard or read or made up a corollary to Steve's Demo Boy/Girl caution -- that is, to also avoid becoming Feature Boy or Feature Girl.
There's a balance in both of these cautions that needs to be maintained. Being invited to give demos gives you an audience to learn from -- time with customers and executives who can help you with your product, your market, and your career. And likewise, learning the in's and out's of your product, either through giving demos or reviewing features closely with developers and designers gives you great insight into how well or poorly it'll actually satisfy the market needs you wanted to address.
The trouble is, if you're great at giving demos or shaping features, the people that need a demo or help with a feature will do everything they can to use your talent to their advantage, leaving you less time to do other important work. Deflecting these requests or finding ways to scale them is a classic PM challenge, and I'd love to see comments back with your personal tricks -- I'm sure we'd all benefit from them!
Whatever your approach, remember that your job is to be the custodian of a product -- the custodian of that business -- not to be the savior of a feature or a deal. It's the rep's job to close the deal, and the engineering team's job to deliver well-designed capabilities that work as intended. They need to do their jobs, and you need to do yours. Keep your eye on the problems your market needs solved, and focus on leading the organization to solving them.
All for now,
J
One of the cautions Steve Johnson (our inimitable instructor) gave us was to avoid becoming Demo Boy or Demo Girl -- to remember to keep our eye on the market, and not to let the Sales team bleed us dry with building and delivering demos. Good advice, a decade later. Since then, I've either heard or read or made up a corollary to Steve's Demo Boy/Girl caution -- that is, to also avoid becoming Feature Boy or Feature Girl.
There's a balance in both of these cautions that needs to be maintained. Being invited to give demos gives you an audience to learn from -- time with customers and executives who can help you with your product, your market, and your career. And likewise, learning the in's and out's of your product, either through giving demos or reviewing features closely with developers and designers gives you great insight into how well or poorly it'll actually satisfy the market needs you wanted to address.
The trouble is, if you're great at giving demos or shaping features, the people that need a demo or help with a feature will do everything they can to use your talent to their advantage, leaving you less time to do other important work. Deflecting these requests or finding ways to scale them is a classic PM challenge, and I'd love to see comments back with your personal tricks -- I'm sure we'd all benefit from them!
Whatever your approach, remember that your job is to be the custodian of a product -- the custodian of that business -- not to be the savior of a feature or a deal. It's the rep's job to close the deal, and the engineering team's job to deliver well-designed capabilities that work as intended. They need to do their jobs, and you need to do yours. Keep your eye on the problems your market needs solved, and focus on leading the organization to solving them.
All for now,
J
Tuesday, October 19, 2010
If you don't ask...
Knowing what anyone else is thinking or feeling is a tricky business, so how do you really know that your SaaS customers are delighted and likely to renew?
The SaaS model offers great potential for seeing how/how much customers are using your system. As PM's, we need to think about what visibility we need to know customers are happy, and find a way to get that data. Instrumenting the product to capture it needs to be built into the requirements early on, or you'll be constantly trying to catch up with your needsas they evolve. We also need tools to view and analyze the data, and finally to make time to actually look at it, interpret it and use it in improving our systems.
There are some obvious examples of quantitative metrics to think about:
Insight into other parts of your broader solution may be important, too. For example:
Stats are useful and important, but it's just as important to ask customers how they're doing, and let them tell you what's really on their mind. Customer calls and visits are indispensable opportunities to do this as PM, but this task ought to be operationalized by the customer care teams as well. Consider polling customers regularly with a brief survey -- for example, after each support inquiry (up to once per month) or proactively on a quarterly basis, if the customer hasn't initiated outreach themselves. So armed, your customer care teams can address satisfaction issues before they become a risk factor for renewals.
Knowing where your customers stand is crucial to keeping them happy. What are you looking at to gauge customer satisfaction? And how are you using that data across your organization? I'd appreciate your insights!
All for now,
J
The SaaS model offers great potential for seeing how/how much customers are using your system. As PM's, we need to think about what visibility we need to know customers are happy, and find a way to get that data. Instrumenting the product to capture it needs to be built into the requirements early on, or you'll be constantly trying to catch up with your needsas they evolve. We also need tools to view and analyze the data, and finally to make time to actually look at it, interpret it and use it in improving our systems.
There are some obvious examples of quantitative metrics to think about:
- The number of unique users who are logging in, relative to the number of subscribers
- The amount of use they're giving the system (how often do they come in, and how long are they using it)
- The type of work they're doing with the system
Insight into other parts of your broader solution may be important, too. For example:
- The usage of education materials within a customer's user base
- Support statistics for a customer (how many incidents, what types of incidents, how quickly they were resolved, etc)
- The number and types of suggestions for enhancements that have come from the customer
Stats are useful and important, but it's just as important to ask customers how they're doing, and let them tell you what's really on their mind. Customer calls and visits are indispensable opportunities to do this as PM, but this task ought to be operationalized by the customer care teams as well. Consider polling customers regularly with a brief survey -- for example, after each support inquiry (up to once per month) or proactively on a quarterly basis, if the customer hasn't initiated outreach themselves. So armed, your customer care teams can address satisfaction issues before they become a risk factor for renewals.
Knowing where your customers stand is crucial to keeping them happy. What are you looking at to gauge customer satisfaction? And how are you using that data across your organization? I'd appreciate your insights!
All for now,
J
Sunday, October 17, 2010
Delighting Customers
I'd been a PM for 10 years or so before I first heard the phrase "delight our customers". It struck me as an odd turn of phrase, honestly, mostly because I don't often hear the word delight or its variants outside the context of polite social discourse. But the idea of truly delighting customers carries with it a lot of powerful implications, and the expression itself is powerful in part because the word delight gets people's attention. It's a great way of planting a stake in the ground as to what's truly expected and required, particularly if I find myself in a room full of folks who've grown weary of trying to cover too many bases with too little resources.
And make no mistake -- in a SaaS business in particular, everything hangs on delighting customers. The subscription revenue model makes it imperative to delight them and secure their renewals (and expansion) year-in and year-out, and if your customers can't see their way to delight, their renewals (and your business) are at risk. To make things even more interesting, the SaaS delivery model raises the stakes for delighting customers far beyond what you see in an on-premise model.
The chief driver of this raising of stakes is the way in which customers interact vendors and their solutions. In a SaaS model, the vendor doesn't just own the solution -- they "own" everything. Everything about the user's experience from the point their PC touches the Internet sits squarely in the lap of the vendor, and in some cases. Opportunities to distribute blame for a shabby experience are few and far between, and even if there were, it's the vendor who will ultimately suffer the most from unhappy customers -- the vendor needs renewals to make the subscription business model work.
Fortunately, the connected usage model gives us some great opportunities to stay in touch with our customers, and understand how we're doing at keeping them happy. Because the users are connected, the potential exists to gather a great deal of insight into how they are or aren't using the system. That can start with something as basic as tracking when users get in and how long they stay, but by instrumenting the product to track user activity within the product UI, much greater insight can be gained -- actionable insight. If you're trying to figure out where to enhance your solution, wouldn't you love to know which features users actually use the most? The least? Wouldn't it be great to see where users get confused and abandon things they start? Anyone would, of course.
Other than getting genuine visibility into how the system is being used, there's also a fantastic opportunity in a SaaS model to engage with users. Because they're connected, you can ask them in real time what they think: How do they like the system? What do they think of this new feature? How are the colors working for them? Was this help useful? What do they need more of? Less of? And that dialog doesn't just give you the ability to ask them questions, it offers the potential (and carries the obligation) to tell them what you're up to: What's coming and when? How will they be affected by a change, and how will they not? A big part of delighting customers is avoiding unpleasantly surprising them.
For organizations used to an arms-reach relationship with customers, there's a lot of new ground, here, But the core of a successful business remains the same as it has for centuries -- you need delighted customers. As you think about your own organization, I'd love to hear examples of the energy you've seen in this direction. Thanks, as always, for sharing.
All for now,
J
And make no mistake -- in a SaaS business in particular, everything hangs on delighting customers. The subscription revenue model makes it imperative to delight them and secure their renewals (and expansion) year-in and year-out, and if your customers can't see their way to delight, their renewals (and your business) are at risk. To make things even more interesting, the SaaS delivery model raises the stakes for delighting customers far beyond what you see in an on-premise model.
The chief driver of this raising of stakes is the way in which customers interact vendors and their solutions. In a SaaS model, the vendor doesn't just own the solution -- they "own" everything. Everything about the user's experience from the point their PC touches the Internet sits squarely in the lap of the vendor, and in some cases. Opportunities to distribute blame for a shabby experience are few and far between, and even if there were, it's the vendor who will ultimately suffer the most from unhappy customers -- the vendor needs renewals to make the subscription business model work.
Fortunately, the connected usage model gives us some great opportunities to stay in touch with our customers, and understand how we're doing at keeping them happy. Because the users are connected, the potential exists to gather a great deal of insight into how they are or aren't using the system. That can start with something as basic as tracking when users get in and how long they stay, but by instrumenting the product to track user activity within the product UI, much greater insight can be gained -- actionable insight. If you're trying to figure out where to enhance your solution, wouldn't you love to know which features users actually use the most? The least? Wouldn't it be great to see where users get confused and abandon things they start? Anyone would, of course.
Other than getting genuine visibility into how the system is being used, there's also a fantastic opportunity in a SaaS model to engage with users. Because they're connected, you can ask them in real time what they think: How do they like the system? What do they think of this new feature? How are the colors working for them? Was this help useful? What do they need more of? Less of? And that dialog doesn't just give you the ability to ask them questions, it offers the potential (and carries the obligation) to tell them what you're up to: What's coming and when? How will they be affected by a change, and how will they not? A big part of delighting customers is avoiding unpleasantly surprising them.
For organizations used to an arms-reach relationship with customers, there's a lot of new ground, here, But the core of a successful business remains the same as it has for centuries -- you need delighted customers. As you think about your own organization, I'd love to hear examples of the energy you've seen in this direction. Thanks, as always, for sharing.
All for now,
J
Wednesday, October 13, 2010
Supporting a Subscription-based Business Model
One of the most significant changes for many companies moving from on-premise to SaaS is a shift in the pricing and licensing model. It's critical for product managers to understand the differences -- to truly incorporate these distinctions into their decision-making framework, or literally risk failure.
Typical on-premise fees are structured in a license+maintenance model, where the cost to acquire the software is high, and then there's a smaller fee that recurs annually to cover the cost of upgrades and support. Because SaaS software solutions are a service, the fees are generally structured around an annual contract where each year the customer pays the same amount, provided that their usage is consistent. Because the fee recurs, it is generally smaller than the up-front license fee in an on-premise model, but larger than the maintenance fees.
So what's the impact of this on PM's? Don't we still have to satisfy the needs of the market? Don't we need to keep our customers happy either way? Yes, of course we do. But it's still very important to have a crystal clear understanding of how revenue is flowing into our companies, as well as the drivers and risks associated with that revenue. How else can we make the best decisions as custodians of the business?
As PM you should be able to build a financial model for your business, to get a feel for how money will flow in under different assumption sets, and how you'll spend the money -- just a simple P&L should give you the insight you need. If you can't do this, you should learn how, or even just ask a Finance person to sit you down over lunch one day and help you build something that you can run with. I suspect what you'll find is this: in an on-premise model, new business is the life-blood of your company, but in a SaaS model, renewals quickly become the life-blood, after a few years of building a book of business. They're both important in both models, but their relative weight is decidedly different.
Think about that -- renewals will become the life-blood, not new sales. How does that affect how you view your investment choices as PM? How does that impact the calculus you make when you're processing feedback from your various internal and external stakeholders? In a SaaS/subscription world, your Sales team is still going to insist you go after things that will help them close new business -- that's how they tend to get paid, after all. But when you model the impact of that spend, vs. fixing issues that are dragging down satisfaction levels and putting pressure on renewal rates, you're likely to find one-off deals to be of little importance.
This isn't just a shift for you as the PM, it's a shift that in a very real way re-levels the importance of different functions within the organization. Where your hunters have previously been the main contributor of revenue, other teams (service, support, and account management functions) may now be more important. The organizational dynamics of such a change are not trivial, and as PM's we'll be right in the thick of it, with the mission of getting everyone at the table to understand the flow of the money. And as I said, the stakes are high -- without high levels of satisfaction and outstanding renewal rates, the SaaS/subscripton model probably isn't sustainable. Get it right or go home.
This is hard stuff, but it's a big part of why this is the best job ever. If you're reading this, and have made this transition, you're undoubtedly familiar with this work. What else have you seen? Do you have any stories to share? Thanks, as always, for your thoughts.
All for now,
J
Typical on-premise fees are structured in a license+maintenance model, where the cost to acquire the software is high, and then there's a smaller fee that recurs annually to cover the cost of upgrades and support. Because SaaS software solutions are a service, the fees are generally structured around an annual contract where each year the customer pays the same amount, provided that their usage is consistent. Because the fee recurs, it is generally smaller than the up-front license fee in an on-premise model, but larger than the maintenance fees.
So what's the impact of this on PM's? Don't we still have to satisfy the needs of the market? Don't we need to keep our customers happy either way? Yes, of course we do. But it's still very important to have a crystal clear understanding of how revenue is flowing into our companies, as well as the drivers and risks associated with that revenue. How else can we make the best decisions as custodians of the business?
As PM you should be able to build a financial model for your business, to get a feel for how money will flow in under different assumption sets, and how you'll spend the money -- just a simple P&L should give you the insight you need. If you can't do this, you should learn how, or even just ask a Finance person to sit you down over lunch one day and help you build something that you can run with. I suspect what you'll find is this: in an on-premise model, new business is the life-blood of your company, but in a SaaS model, renewals quickly become the life-blood, after a few years of building a book of business. They're both important in both models, but their relative weight is decidedly different.
Think about that -- renewals will become the life-blood, not new sales. How does that affect how you view your investment choices as PM? How does that impact the calculus you make when you're processing feedback from your various internal and external stakeholders? In a SaaS/subscription world, your Sales team is still going to insist you go after things that will help them close new business -- that's how they tend to get paid, after all. But when you model the impact of that spend, vs. fixing issues that are dragging down satisfaction levels and putting pressure on renewal rates, you're likely to find one-off deals to be of little importance.
This isn't just a shift for you as the PM, it's a shift that in a very real way re-levels the importance of different functions within the organization. Where your hunters have previously been the main contributor of revenue, other teams (service, support, and account management functions) may now be more important. The organizational dynamics of such a change are not trivial, and as PM's we'll be right in the thick of it, with the mission of getting everyone at the table to understand the flow of the money. And as I said, the stakes are high -- without high levels of satisfaction and outstanding renewal rates, the SaaS/subscripton model probably isn't sustainable. Get it right or go home.
This is hard stuff, but it's a big part of why this is the best job ever. If you're reading this, and have made this transition, you're undoubtedly familiar with this work. What else have you seen? Do you have any stories to share? Thanks, as always, for your thoughts.
All for now,
J
Thursday, October 7, 2010
Comparing SaaS to On-premise
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
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
Subscribe to:
Posts (Atom)