The Fiducial Mark

After reading about Autodesk’s Project Butterfly, I took some time to give it a whirl.  Project Butterfly is an on-demand system designed for users that want to experience AutoCAD through a web browser.  Being a technology preview with limited functionality at present, it isn’t a product available for sale – but you can try it out for free and see how the experience differs from the usual desktop (on-premise) experience.

I’m not a heavy CAD user, but there are several reasons why I think Project Butterfly is compelling.

1) The fact that it is an on demand solution:

• No installation required.  A secondary benefit is that updates are pushed out rather than downloaded and installed.
• Platform independence: enables accessibility on desktops, laptops (netbooks!), and a number of operating systems.
• Project Butterfly utilizes Amazon Web Services.  This enables online data storage, but also allows users to download models to local computers.

2) SaaS solutions are nothing new, but I’m not aware of a precedence of a solidly entrenched geo-related desktop application being offered as an on-demand service in addition to the traditional desktop ownership model.  I wouldn’t bet on the decline of AutoCAD as a desktop solution anytime soon, but Project Butterfly provides and attractive glimpse of future possibilities in terms of CAD and geospatial data production and editing.  It will be interesting to see if and when Product Butterfly can graduate into a commercial product!

3) Online data hosting:

Data Download Capability Via Amazon Web Services

Files are stored using the Amazon Simple Storage Service.  It is possible to upload your own data (e.g. I was easily able to add a JPG image as a backdrop), or download data in a number of formats.  These include DWG, PNG, JPG or Zip (with Xrefs).

4) Data production and editing tools: I played around with the geospatial sample data in Project Butterfly.  While the current functionality is limited (it is a tech preview after all), the available features are presented in an nice user interface that is easy to navigate.  Basic drawing and editing tools are available, as well as modes such as snapping and ortho.  It is also possible to upload (import) local data.

Editing in Project Butterfly

5) Collaboration: I didn’t actually try it out, but there is an option to invite others to edit and also set permissions for invitees.  These include the ability to edit and download the data – great features for showing the data to someone without actually allowing them to edit or download the data.

It’s great to see a major vendor moving in this direction.  From a product perspective, an application like this should be able to dramatically reduce the typical software release cycle (e.g. 6 months or more for a heavy desktop application), and create greater efficiencies in terms of product rollouts, technical support, removing the need to ship traditional media discs, and more…

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?