Andrew Pollack's Blog

Technology, Family, Entertainment, Politics, and Random Noise

Professional Services

Second Signal

Presentations

Andrew's Blog

Support

A New Product Launch Paradigm

By Andrew Pollack on 09/04/2006 at 08:18 PM EDT

Software products are released as complete and supported, or as beta with the expectation of bugs and little support. For now, there is very little between these two paradigms. The idea of “Release Candidates” is getting more common as are “Gold” releases but something is still missing.

IBM launched Domino 7.0 with the DB2NSF functionality marked as “Limited Availability” at the last minute. The name is wrong, really. It’s not the availability that’s limited; it’s more accurate to say that there isn’t enough confidence in the technology yet that IBM wanted to support it for all users in all circumstances. Anyone with Domino can get it, but they can’t expect guaranteed results yet. The problem is, IBM has no way to release something that isn’t 100% rock solid finished enough to work for every large enterprise customer in every supported environment.

Big, complex, enterprise scale products aren’t like browsers and word processors. New technologies being added are themselves very complicated and prone to use in many unexpected ways. Do you hold the release of an entire product suite because a new feature isn’t fully baked yet? Do you withhold that feature even though it may work perfectly well for 80% of the user base and be a fully committed tool for future development?

There needs to be a set methodology and nomenclature for releasing a new version with some features that are “almost there” -- past beta, confirmed to be part of the long term strategy, but not yet battle tested enough to bet the store on without more than the usual amount of testing. In the Linux kernel, these are “Experimental” options but that implies less stability then I’m looking for.

The NAME for this kind of release is really the crux of the matter. You don’t want to call it “Beta” or “Experimental” because that’s not really true. The feature is working and tested, but complex enough that the developers know there will be cases they haven’t considered that will cause problems. They’re committed to resolving those issues and making it stronger and stronger, but cautious about telling you to store the company jewels there. The new tools will probably work perfectly for 99% of the people who try them, but they still need that warning.

I believe firmly that sometime soon someone will get this kind of release methodology right and it will become a de facto standard almost overnight. The naming and marketing of it is the only holdup. Google just keeps everything in Beta forever. Microsoft releases beta after beta followed by release candidate versions in a series until they’re confident that only the least damaging bugs are still in before finally releasing a new product. IBM tried their “Limited Availability” thing with DB2 (and frankly did it very poorly, IMO).

So who is going to get it right first, and what will these “almost there” features be called? Would you try them if you knew the score?

There are - loading - comments....

InterestingBy Gab Davis on 09/04/2006 at 08:36 PM EDT

In many ways it's a marketing battle - if IBM introduce a feature that's less
than 100% bulletproof they risk damaging the image of the entire brand or
anything 'tainted' with the same name. It's a very difficult question - would
having these add-ons available via optional download be the way of addressing
it? If for instance I download something from Sandbox (even something generated
by IBM) I know it's a case of buyer beware.

Maybe the solution is what they tried to do with DB2 which is to not ship it
with the core product but make it an optional, risk associated, non supported
download until it's ready. The problem with what they did with DB2 is they
made it almost impossible to find and download and actively discouraged use by
making it sound like a closed program. T

Since naming clearly isn't my forte I'll leave it to someone else to come up
with a catchy name for an "Optional, Risk Associated, Non Supported Downlaod"!

I agree with GabBy Amy B on 09/05/2006 at 10:33 AM EDT

I went to a Lotus launch event when 7 shipped and a lot of customers there were
very interested in NSFDB2. They were repeatedly told that they would receive
"limited support", which frustrated them because they felt that they couldn't
roll it out into production under those circumstances.

I think Gab's idea of having it be a separate download with separate rules
would help somewhat by making it clear that this was not a part of the gold
shipping product.

But I think that these customers would (rightly) still be concerned about
putting it into production, which really frustrated them.

Bit of a Catch-22, eh?

My own thoughts on this are...By Karen Hobert on 09/05/2006 at 12:54 PM EDT

To echo Gab and Amy it's a marketing and sales issue - really how you package
it. No enterprise wants to deploy something that is "limited" support or
availability. Larger orgs (or consultants) with R&D departments can "afford" to
test out these things and prevent disruption. They also get customized
experiences from the vendor. As far as the NSFDB2 program, from what I know,
people who were accepted into the program had identified the applications that
they wanted to port. So it's a controlled environment with IBM deciding what to
support. Of course that doesn't prevent someone from going it alone and
hopefully an eye doesn't get poked out. Regardless, it's bad marketing when you
say my product has a feature but only certain people can use it. IBM also had a
PR issue since they have been promising NSFDB2 for several years, kept pulling
it, and yet felt compelled to put it in the R7 product. (IBM has pulled stuff
at the last minute before, remember Garnet?) They are still digging out of it
from a PR perspective. It remains to be seen if they can pull it off
(technically or PR -wise) in Hannover and Domino Next.

Back to a distribution model. There is one that works quite well. Make a
separate product. Domino started out as the Internet Publisher - a separate
product that some (nudge, nudge) people thought was a good idea, despite the
objections of marketing and sales. Didn't take long for it to roll into 4.5.
Many good product features start out as separate products. They end up in a
product once they've proven themselves in the market as solid code or as a
money maker. This happens all the time, whether it's a niche product that gets
acquired or an internal project (like Domino) that gets rolled into a bigger
product.

I think IBM should have not mixed NSFDB2 into the Notes product right off the
bat. It should have been an add-on technology, like Internet Publisher. Of
course IBM has some self-inflicted pressures. It would have been crazy for them
to release another data integration product (what with LEI, DECS, LSX, etc.
confusion) without providing some way to resolve the multiple products
(doable). I go back to what they did with Internet Publisher. It was a
grassroots project, little budget, demoed a lot by marketing in front of
customers (anyone remember the Internet Playroom at LS?), and got a few
interested parties signed up for trying it out. Not a bad approach, they found
their issues, they found their market, and they made a good product.

Pros and cons of bundling featuresBy Tim Tripcony on 09/05/2006 at 02:17 PM EDT

This issue makes me even more convinced that Damien is taking the right
approach with CouchDb: keep add-ons separate from the core product. The primary
disadvantage in this is that the installation and configuration will likely be
more complex. The advantage, however, is that customers would only be
installing the features they specifically see a need for.

Notes and Domino have an amazing featureset. Unfortunately, there is so much
bundled into the core that most customers never even use. In many cases a
customer doesn't even realize those features are there. As a result, an
administrator must manually disable the features that don't apply to that
organization to avoid needless consumption of server resources. Because many of
the features are tightly intertwined, however, disabling a given server task
often has unforeseen impacts on other tasks. Moving closer to a "deli menu"
style installation - install the core separately, then add only the features
that are needed - would likely result in a more efficient underlying framework,
but also draw more attention to just how many features are available, which
ones may not be applicable to all customers... and which should be used with
caution.

My own thoughts on this are...By Linda on 09/19/2006 at 01:33 PM EDT

We often release software with features in this state - we refer to them as in
their "initial" release. Everyone knows they'll get better in the future but
they realize they're ready for some initial market.

Subject
Your Name
Homepage
*Your Email
	* Your email address is required, but not displayed.

Your thoughts....


	Remember Me

Andrew Pollack's Blog

A New Product Launch Paradigm

Site Links

Useful Links

Other Recent Stories...