A previous post on this blog shared observations about high-stakes SaaS product development initiatives; and a follow-on piece took a deeper dive into setting related cloud services strategies. Together they focused on considerations when undertaking major SaaS product initiatives (such as re-platforming projects, new user interface introductions, infrastructure changes, functionality expansions, code re-writes, and others).
Although this post builds on those prior pieces, it steps away from the product side of things. Instead, it examines a wide range of critical, but often overlooked, “other stuff” needed to successfully introduce meaningful product changes to customers. Borrowing from the world of project management, we’ll broadly call this topic operational readiness. The harsh reality is that even a well-executed product development initiative can be greatly undermined by inadequate operational readiness. And this is often where many SaaS companies falter, particularly small-scale businesses without mature systems and processes. With that in mind, here are ten quick lessons learned and five “non-product” questions / exercises that can help organizations manage major product change initiatives.
1. Never underestimate resistance to change: Easy to say, hard to do. We as operators are generally so much more excited about product changes than our customers are. Always respect their fear of change.
2. Overestimate the resources your customers will need…then double it: Tip-sheets, webinars, videos, hand-holding, whatever you think customers need: they will value more than you think…and resent just as much any perceived deficiencies.
3. Whenever you plan to introduce to the market, allow >2 months prior to train the team: Your team members need to be the experts on whom customers rely. Expertise takes time and repetition. Don’t make your team look bad in the eyes of their customers by shortchanging their opportunity to develop proficiency.
4. Identify very clearly what the pain points are to the customer base and organize around them: Their pain of change needs to be dwarfed by the value they receive. Never confuse value to the business with value to customers — the latter is all they care about. Period.
5. If it is everybody’s job, its’ nobody’s job: The upgrade / migration / change initiative needs to be one person’s sole responsibility to manage. Although it takes a village, that village needs a full-time, fully empowered leader in order to thrive.
6. Communications around the initiative is a full-scale project in its own right: What gets communicated to whom, when…and how? Overinvest in this area; underinvest at your peril.
7. Be mindful of dependencies that come up and influence other departments: This is NOT just a technical endeavor; it touches every department. If a department seems insulated from the change, you might not be thinking about it hard enough — and you’ll likely be surprised later.
8. Establish up front how you will measure success: What is the one metric that matters most in this endeavor? The number of divergent views on this point is surprising, so don’t allow this to remain ambiguous.
9. Determine early what, if any, ancillary tech projects / demands will emerge: Perhaps you’ll need to build an internal tool to help support migrations. Maybe you’ll need to redeploy developers to support customers. These can kill your timelines; don’t get surprised by them.
10. Decide what to decide: What follows are thoughts on some of the important items that warrant intentional decision-making.
QUESTIONS / EXERCISES:
1) What are our “big rocks” of operational readiness?
This deceptively simple question forces companies to consider all the aspects of their offering that directly or indirectly impact how customers experience their software solution. Although there is a wide range, just a few of the usual suspects on this list include:
· Internal education: Who needs to know what in advance of product changes hitting the street?
· Client Communications: How to make customers aware of coming changes and avoid unnecessary disruption?
· Client Education / Resources: What can be done proactively to arm users with self-help tools?
· Market Support: What services should be put in place to effectively address inbound questions?
· Migration Management: What support infrastructure should be available to manage the pain-of-change on technical / data / process levels?
2) Who benefits from this project and how so?
Again, this one seems simple but warrants focused attention. The truth is that big product initiatives can take on a life of their own and cloud our understanding of their true purpose and benefit. It helps to think of each stakeholder group (e.g. customers, prospects, partners, internal team members, financial stakeholders) and even sub-sets of users (admins, super-users, casual users, executives). Then, lay-out the tangible benefit each group will derive from the initiative. These might include: a shorter learning-curve (for customers), ease of support or ability to code more efficiently (internal team), or less resource intensive implementation cycle (multiple beneficiaries, including financial stakeholders). We better have good answers for each stakeholder, or else it is going to be hard to justify to them the inevitable cost / effort it will require to adopt the proposed changes (aka: the “pain-of-change”).
3) What are the situation-specific complexities to consider?
Complexities reflect the unique nuances of each product and user-base. These are the characteristics of your business that will largely define how the company must prepare to support impending product changes. Examples of these include:
· Number of clients: 12 is different than 1,200 is different than 120,000
· Number of users: Similar point as above, on a different scale
· Client business cycles: seasonal demands of specific segments demand consideration
· ACV: Free solutions vs. economy solution vs. premium offering
· Interdependency: standalone solution versus highly integrated / interdependent
4) What are the guiding principles to be upheld?
Like any set of principles, these should represent the “non-negotiable” commitments. These may be commitments to customers or to your own organization; and they may be tacit or openly communicated. In any case, what is most important is that they are not open to compromise. Some hypothetical examples of these might be:
· The out of pocket cost for customers to implementing this product change should be $0
· We will not introduce this change to customers in production until [X] milestone is met
· Scheduled down-time will be limited to [Y]
· Clients will always be able to choose / control [Z] aspect of their change process
5) What are the operating decisions to be made?
All of the questions / considerations above play a role in organizational readiness; and companies must ask and answer a number of pragmatic questions. A few of the usual suspects tend to be:
· Should migrations occur on a rolling basis in cohorts (OR…all at once as a big-bang)?
· Should clients be able to move to the new solution when they are ready (OR…on a timeline set by the company)?
· Should functionality be introduced in phases, or with a flip of the switch?
· Should clients be able to roll-back to what’s familiar or pushed hard to forge ahead?
· Should clients be able to access legacy system if they so desire? Will the company continue to invest in / support those legacy solutions…and for how long?
In sum, change is hard. Operational readiness, when painstakingly undertaken and executed by a company, goes a long way toward easing that pain for its clients. Failure to do so, however, can result in tenfold the pain downstream for everyone involved.