From my point of view, a better term would be 'covering' a feature. For one, I love cover versions in music, I could spend hours browsing secondhandsongs or finding rare gems in the last.fm covers tag radio. And just as in music, there can be a lot more variation when covering a feature then when simply cloning it.
So Friendfeed's new beta is really a bit like twitter, but they are covering it just like Franz Ferdinand is covering the Beatles' "This Boy", giving it new energy and speed.
On the other hand, covers can simply go wrong. This applies to software as well as to music, but the difference is that awkward covers in music can be quite entertaining, while in software they are most of the time embarrassing to all involved parties.
Next time you are covering a feature, try to make the best out of the cover version, so that your software is able to fit into this equation.
Did you know that there is a Beatles song about the Microsoft Windows, Microsoft Office and Apple's iTunes? Of course, there is not, but there is a song about the lock-in effect. The song is called Chains and appeared first on the Please Please Me album. Listen for yourself.
If you do not have the time to watch the video, this is the crux of the lyrics:
Chains, my baby's got me locked up in chains.
And they ain't the kind that you can see.
Whoa, oh, these chains of love got a hold on me, yeah
Software companies love their customers so much that they would like to keep them forever, so they try to lock them in. The best lock-in effect leaves the customer of the software in a situation that keeps uses chains of "the kind that you can [not] see" and make the lock-in appear as "chains of love".
The best time to attempt creating a lock-in effect is when your new product is having maximum market impact and growth. The reason is that at this time you will have most goodwill in the market, so customers and prospects will be uncritical to your attempts of creating a lock-in. Even if the chains are recognized,hey, they are chains of love. The second reason is that with having achieved maximum growth there is still plenty of time for your product to become a cash cow that can subsidize the development of related products that will reinforce and profit from the lock-in effect.
A good example is how Microsoft created its lock-in of the Desktop. After the launch of Windows 95 and NT 4.0 it had overwhelming market acceptance. My father took me, as a boy to a trade show, just to see Bill Gates speaking. And we were not the only fans eager of new Microsoft products. With this momentum, Microsoft could consolidate its offering by combining the Windows operating system with the Microsoft Office productivity suite, with the Exchange groupware server. This combination created a sustainable ecosystem, that customers happily accepted, developers adopted (remember the times when custom business applications were Visual Basic desktop applications) and that allowed Microsoft to conquer adjacent markets such as the Browser market.
The design problem with Microsoft's lock-in is that it is too visible and obvious, which means customers are aware of it, which creates an opportunity for competitors to attack the lock-in and offer "breaking free from the Microsoft lock-in" as an additional value proposition. As a result, Microsoft's ecosystem of connected applications is under market pressure: Firefox is gaining market share on the browser market and has just surpassed Internet Explorer, at least here in Europe. Google (and millions of web developers) are working to make the desktop operating system irrelevant, with Android they are challenging Microsoft's hold on mobile operating systems. With Eclipse developers have an alternative to the Visual Studio brand of software development environments (yes, I am aware, there are other cool open source IDEs, but not a single one has the breadth of Eclipse). Microsoft, noting how competition is starting to pick the locks, is doing its own job to damage its lock-in by offering a web-based version of Microsoft office that teaches customers to accept compromises on the look, feel and functionality of their productivity software, which opens another window of opportunity for competitors.
For a better way to design a lock-in we should not think of the big padlock, but of the thousand lines that are tying down Gulliver. For one, he is being tied down, while sleeping, which means - start the lock-in while nobody, at least not the customer, is watching. Secondly, with thousand lines there is no single line to identify that drives the lock-in, that can be easily attacked.
A good example of this is Apple's iTunes. Apple offers a very comfortable lock-in to its customers to make sure they stay loyal when new competitors emerge. Wether it is a streaming service like Spotify or Amazon's MP3 download service, all of them are unlikely to lure me away from iTunes - and it is not just iTunes, it is the iPhone, that extends the lock-in to the mobile carrier, it is the Airport Express and Apple TV that wire the living room entertainment system, it is the Genius service that gives personalized music recommendations (which are better than Amazon's item-based recommendations), it is the iTunes remote control application for the iPod touch, it is the Bonjour music sharing, it is the locked iPod database, it is the integration with iLife. If one line breaks down, for example DRM in the iTunes store, there are still enough combination points to make the lock-in effective and attractive.
If you have the opportunity to create a lock-in effect, keep these rules in mind:
do it at the right time
make sure nobody is watching
make it attractive to be locked in
keep building integration points
As a customer, keep in mind that a lock-in is not necessarily a bad thing. Vendors create a lock-in, because they do not trust their customers to stay loyal, customers should ask themselves if they trust a vendor's continued ability to innovate and satisfy your needs. The more mutual trust there is, the more attractive a lock-in appears and the less important it becomes.
Last week Douglas Bowman announced that he is quitting his job as leading visual designer at Google. Among the reasons for quitting was tight corset in which visual designers had to operate at Google. Each design decision had to be tested, verified and optimized for maximum user acceptance. This lead to situations where 41 shades of blue were put to a multivariate testing, because the team could not decide for one. I would argue that this way of decision making (using huge amounts of data, huge user numbers and heavy number crunching) is part of Google's DNA, there is not much they can do about it, but the result is that your software improves only in small, evolutionary steps. If we were speaking in terms of genetic algorithms, Google has a very good fitness function, but the process does not allow for too much mutation, which means you can find the local maximum surely, but you are also likely to miss the global maximum.
The result of such an evolution is a design that looks like Google Reader. The most impressive part about Google Reader is not the technology, it is the feature sprawl that is messing up the user interfaces. You see lines, boxes, icons, buttons, input fields, links and lots and lots of googlish-blueish texts and backgrounds. It might be the local maximum, found by rigid testing, but it still leaves the user with the question "Is this all they could come up with? Can't there be something that feels better?".
Sure there can. One approach to increase recombination and to speed up evolution is to create a framework like GMail labs, where new features like offline GMail, GMail gadgets and others are tested. This is an internal, voluntary way of increasing the speed of evolution, similar to the invention of sex in nature that lead to more and faster recombinations, but that happens voluntarily.
The other approach is involuntary mutation, which also has its equivalent in software that can be observed using Google Reader as an example. Greasemonkey is a browser-add-on that allows running custom Javascript and CSS on a website and with modern AJAX-driven websites this means you have the ability to run a completely different web application using the same data or web service in the background. For GMail there is a Greasemonkey script that I especially like, Helvetireader. It simply puts a new skin on your Google Reader that makes it look like a hommage to Swiss design - white and red, clear cut forms, everything unnecessary is removed and everything that distracts you from the content is hidden. As a result you get an user interface that seems to be very close to the gobal maximum.
What we observe with Helvetireader is the power of mutation, opinionated Software and swiss design. And that's a good ending for a blog post in any case.
Both with CQ DAM 5.2 and CQ Social Collaboration 5.2 I have been standing on the shoulders of giants, which have enabled me to implement a bold vision of Digital Asset Management and Social Collaboration integrated into Web Content Management in such a short time, following our CQ5.1 release last November. These giants are our developer team and our product marketing team who have a done a marvelous job on getting this product to countless demos, POCs, beta projects, press and analyst briefings and who have implemented one cool feature after the other.
But standing on the shoulders of giants also means reusing a great platform to build upon. We did not have to think a single second about clustering, backup, scaling, permissions, LDAP integration, workflow, development environment, because all this is at some level provided out of the box by CRX (and its underlying Apache Jackrabbit and Apache Sling foundations) and the CQ5 Platform we share with CQ5 Web Content Management.
I would like to take the opportunity to shed the light on two smaller features, one in CQ5 DAM and one in Social Collaboration that we typically do not include in demos, but that offer a huge potential for everyone who sees our products as a platform to realize his own ideas.
Feature number one is the workflow launcher we are using especially for CQ5 DAM. This workflow launcher will listen for repository events at a certain part of your content repository, for example the DAM bulk upload hot zone or a Sharepoint repository we are monitoring through our connectors. Once a new file is being created here, we launch the workflow that will take care of the actual processing. For the end user this means: more flexibility in creating complex workflow-driven processing solutions for digital assets. And it means a reduction of magic, because everything that will happen to your assets is visible (in the Workflow Models tab) and the reason why it happens is visible in the workflow launcher tab. Not attempting to do magic and to appear as magician should be a goal for every software engineer.
The second feature is even less graphic (guess why we are not demoing it), but it is one of the small pieces that makes Social Collaboration so great. We call it the 'Feed Importer', but it actually does a lot more. The idea of the feed importer is to poll a remote resource at a specified interval, to parse it and to create nodes in the content repository that represent the content of the remote resource. We are using this at two places right now - for subscribing to remote iCalendar files just like you do in Apple's iCal or Google Calendar and in the blog, where you can aggregate existing blogs in one 'planet blog' that for instance contains all bloggers of the JCR community. This auto-blogging-feature has been in the blog since Advanced Collaboration 1.1, but with Social Collaboration 5.2 there is a proper and powerful API that can be used in customer projects as well. Needless to say, in order to implement a new parser & importer all you have to do is implement one OSGi component and I expect it to be not too long till we see Twitter-mashups on CQ5-powered websites that are using the Feed Importer.
So thank you very much for all the help with the 5.2 release and I am looking forward to see many CQ5-powered community websites and public asset repositories soon.
Handing out beta invites has become an accepted practice for launching a new web service. Interestingly the user experience you get from signing up for beta invites can differ a lot. Basically there are three things that can happen:
you sign up - and get an invite immediately: the service is not running a beta program, they are just harvesting email addresses and you fell for it.
you sign up - and never hear from them again: the service did not launch successfully, with a little bit of tough luck your email address is being sold with the assets of the company
you sign up - and have to wait some time (more about that later) to finally get your invite. Sometimes it helps to publicly ask for (or beg for) invites to speed up the process.
The question is: why do I get some invites very easily, whereas I have to wait for others weeks or months, and there seems no evidence of successful begging for invites. Example: if you are looking for an invite to Unblab, an innovative email client for high-traffic communicators, you should prepare for a long wait and you are not alone.
The reason is that product managers are running closed beta programs for two reasons (and there is a third for web services).
Reason number one is to get high-quality feedback from a selected number of users, ideally from users that are in your target group. With a private beta program for a consumer-web service you can get this kind of feedback, because your beta users will be highly engaged, after all they have been selected to see your product before anyone else does, you can ask them questions regarding their demographics and other services they are using, so you can make sure they fit into your market segment (a service that demonstrated this nicely is Gist, which required me to fill in a 10-page survey before I got the invite) - and as many startups do not have established customer support practices, let alone detailed usage analytics or business intelligence software, it is easier to handle the load of 1.000 selected beta testers than the crowd of people that will sign-up & forget once you hit the Techcrunch start page.
There is an important draw-back to this approach: in reality you will not get a fair representation of your target users with a closed beta program. You will get early adopters who linger around at places like the friendfeed Invites room to get the first peek at the web service that might become the next big thing, but forget about it if you do not hit their sweet spot (and this is probably not the sweet spot of the target user), you will get your competition's product managers and subsequent feedback that is not representative of your user group. But do not abandon the notion of a closed beta yet, because there is still reason number two.
Reason number two is to build a community and to get people talking about your service. The more people you invite to the service, the more people can potentially talk about it, but on the other hand, the more rare your invites are, the more reason people have to talk about your service, for example by asking for beta invites, by leaking screenshots, by promoting your service (if you tell them that this will increase their chances of getting an invite). Again, we have the problem that this is the early-adopter crowd that will talk about the service at early-adopter places like Twitter and friendfeed, but once you have enough buzz, attention will spill over to tech blogs and you are ready to move up the technology adoption curve. So what is the right amount of invites you should hand out: this chart explains it.
The real question, where is the local maximum depends on the size of your market, the share of early adopters in it, how likely people are to talk about your product. But with proper monitoring of Twitter (and a good, trackable product name) you can easily move along the curve giving out more and more invites until you see that the additional attention you get from giving out an additional invite degrades.
By the way: the third reason to run a closed beta program is a lack of technical scalability. If a service cannot sustain more than 10 concurrent users, you have a very good reason to cap the amount of invites at 1.000 until you have fixed your problems. So the next time you see a service high on the attention scale, but with a little amount of invites circulating, it could be the case that they just have more pressuring issues than putting additional load on their servers to people asking more or less politely on Twitter.
Comments [2]