The Fiducial Mark

Planning software launches is a core element of Product Management, and typically requires a great deal of planning and preparation.  There many opinions on launch planning and instead of covering such a broad topic, I thought it would be interesting to write a few observations on differences between desktop software launches and software as a service (SaaS) releases.

Desktop software release cycles can be lengthy, and the QA and Acceptance Testing planning can be a challenge.  Operating systems, compatibility with other desktop software packages, as well as any proprietary format testing are all major considerations .  The time between major releases could be up to a year for products that I’ve been involved with, which may be interspersed with one or two minor releases.  Because of the lengthy release cycle, it always felt like there was a lot riding on a successful major release: when a year of effort is at stake you want to minimize the risks and ensure the launch delivery is smooth and successful.

With SaaS releases, the fundamentals of Product Management remain the same but the delivery mechanism is quite a bit different.  Here are a few observations, along with thoughts on how they can impact PMs:

Frequency: One characteristic of SaaS is a comparatively fast release cycle: any given individual release may not be as feature-rich, but significant releases may come every few weeks instead of every 6-12 months.  This means that launch plan components which used to be relatively sporadic need to be happening on an ongoing basis.  For example, a communication pipeline to sales teams, partners, and ultimately customers is something that needs to be revisited with a higher frequency.  For distributed teams, conducting internal webinars instead of or in addition to traditional events (e.g. in-person sales enablement training at an annual internal sales meeting) might be a practical method of delivering updates.

Quality Assurance: One of the perks of SaaS is the QA process, since operating system support is much less of a drain on velocity. Instead of having to corral beta customers on different operating systems and worrying about how your test matrix is exploding, you can focus on the fundamentals.  SaaS systems have different sorts of challenges (e.g. you don’t have to worry about up-time reporting in a desktop environment), but the ability to focus on core testing rather than running the same tests on X number of operating systems is a nice benefit.

Delivery:  Depending on the installation footprint, a lot of desktop packages need to be shipped out via DVD.  This represents planning, costs (and ensuring you get your quantity estimates right!), and an extra 4-6 weeks (shipping time) before customers can get their hands on the software.  This entire step is eliminated with SaaS, and from a user’s perspective the new features simply appear in the software upon release.  This presents a unique challenge…  Unlike the desktop software environment, customers cannot simply uninstall a shoddy release.  So the pressure for quality is high in a SaaS environment.  Any critical bugs that slipped through the cracks need to be dealt with immediately – but on the upshot deploying fixes is easier: they can be pushed out to all users at once.  This highlights on of the nice factors in delivery and customer care: when diagnosing an issue, you don’t need to query the customer on what version and patches they have installed and attempt to “find a needle in the haystack” of what could be causing a conflict.  All of your customers will be using the exact same version…

Marketing / Communication: Since SaaS users do not have to manually install new releases themselves, it’s important to think about communication.  I think the ideal is delivering an in-application notification system, but other channels such as blogging, email notifications, or direct contact by account managers are all viable options.  The challenge in the early feature planning is to ensure that new updates improve user experience and do not break or inhibit any existing workflows.

Documentation: A consideration here is that a traditional User Manual, training docs and other materials may become outdated rapidly or a burden to produce due to frequent release cycles.  I don’t have a silver bullet for this one, but I believe a positive direction would be a framework that allows you to plug in new material without a lot of overhead.  In practical terms this could mean digital documentation as opposed to print, and perhaps use of alternate mediums such as video content and short, concise quick reference guides instead of verbose documentation.  I’m definitely interested in other thoughts out there on this topic.

I’m enthusiastic about Product Management in a SaaS environment, and these are just a few initial observations.  Overall it seems to me like the principles of Product Management between SaaS and desktop products are quite similar, but timing and certain tactics can be different…

I’m very interested in insights and opinions on the topic: are there other considerations as well?