Incompatibility strategy

It occurred to me the other day that one of the major benefits of releasing a new version of a product that is not very compatible with previous version is the speed of uptake within migrating orgs.

What I’m thinking of is how rapid the implementation is likely to be. If a company decides to adopt Office 2007 say, its likely to be a fairly sharp switch over. More so than say the move from 2002 to 2003, those co-exist much more easily.

Also for independent consultants like some of us here, switching back and forth from 2007 to prior versions is more pain than previously. That might encourage us to encourage clients to migrate to 2007, Or it may mean we drop non 2007 clients so we can stick with one version. Or we may avoid 2007 of course and offer 2003, 2002, 2000 and maybe 97 and OOo instead.

It seems that if you release an incompatible version you force people to make a choice about which version (or vendor) they will work with, but those that do migrate are unlikely to go back, and likely to drag others with them.

I know there are plenty of resources to help the move to 2007, thats not my point. I’m thinking that as soon as an org gets some 2007, they will want to move completely, rather than support 2 vastly different versions. If your IT team was going to support 2007 and 2003, then I wonder how much extra work it would be to support OpenOffice as well?

Many of the folks who have got past the initial hurdles of 2007 have suggested they do not want to go back and use previous versions as its is too hard to work with such different designs. Thats an interesting observation as I don’t mind at all using anything from 97-2003 and OOo as the differences are quite easy to work around.

I think the strength of the (generally strong) views around 2007 (either for or against) are part of the same thing (over the hurdle in ribbon user experience nirvana or resenting its pointlessness).

I’m not sure how the VB6-.net thing ties in, or if it does?

I’m not softening to the jumbled up UI, but I am starting to see a hint of a possible strategic justification. (I’m not suggesting it will work)

Do you think this is just standard planned obsolescence?
Would you do it with your product?
cheers
Simon

2 Responses to “Incompatibility strategy”

  1. Marcus Says:

    Hi Simon.

    I see planned obsolescence as a double-edged sword and can (should?) only be implemented if you have enough clout to force it through.

    I once read a definition which stated that taxation was the process of pulling the most amount of feather from the goose with the least amount of hissing. Previously the goose (us) could hiss all we wanted but had few alternatives when our feathers were plucked through planned obsolescence. Today the goose has more choices (OOo) and may decide that its fed-up being plucked.

    If MSO2007 is the version that the geese decide to overlook, could this provide OOo alternatives enough time to implement sound office-automation technology to be a viable alternative when the geese do decide to upgrade (or in this case migrate).

    Would I do this with my product? It would be software suicide. As a small business concern, planned obsolescence just provides a (now hissing) client with the opportunity to investigate alternative solutions.

    Cheers – Marcus

  2. Simon Says:

    Good point Marcus, balance of power is a key factor

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.