Launching iPhone is a lot more fun than doing the same for even the coolest web app. The physical nature of consumer electronics allows for some launch activities that can’t be replicated with web products. This includes the promotional frenzy of having people line-up outside retail outlets to get early access to a new gadget. As Apple demonstrated last week, nothing beats the dynamic of a physical crowd even in the digital age.

But after launch, true glory tilts in the favor of the web. Web products may launch with a whisper but when things go right, their traction and growth can be heard with a roar.

This starts with the fact that web products are generally available to everyone. There are little to no barriers to consumption. Not only are they almost always free, increasingly, they are also registration-free. Examples of this would be Pageflakes and Netvibes, which allow you to customize a personal page without any sign-up. Web products generally subscribe to logic that product consumption will speak for itself, leaving traditional (outbound) product marketing obsolete.

Distribution is getting to be almost frictionless as well. In web 1.0, there were many gatekeepers like AOL and Yahoo. But now users can add services to their pages whether those pages sit in a content or social network. Facebook and now MySpace are being fairly open about all of this. Blogging platforms have allowed for this from the start. Browser extensions also opened a new channel of portal-circumvention that is now so obvious, we are drowning in a sea of options. The word of mouth factor is so powerful on the web that new products need only get two things right to grow business. The first is the core application and innovation. Not so easy. The second is allowing for all the hooks that users could imagine as ways to pluck great services into other places on the web.

Maintenance is also a snap compared to physical products. iPhone is reported to have bugs. With a web product those bugs can be fixed right away. Most early web companies conduct major releases monthly, minor releases weekly and random fixes on a daily basis.

So what exactly would be some best practices on launching web products? I decided to look into the matter.  Here are four key takeaways.

Landing Sites Are Okay

Companies are generally formed before products are ready to launch and need to establish a presence to communicate their existence to early stakeholders. Landing sites are important as a means to say, “hey, we’re out here doing some work in category X.” Bazooked, a company which was just formed a few weeks ago, put up a first version of a landing page to communicate a high level vision for content discovery that it will actively work on. The goal is not publicity but instead just putting a stake in the ground. Since not all web products (especially those with fairly deep technology) can be developed in weeks, landing pages may also go through versions. It’s important for a landing page to tell users what problem will be solved and to create some excitement about it. As a company gets close to functional product, a more detailed landing page (which speaks to the product and not just the space) can be used to complement outbound publicity efforts. It’s the more detailed landing page which signals to the market pending availability of the product in some limited way, whereas the initial landing page does not carry this implication.

Don’t Compromise on Good First Impressions

There’s an oversupply of choice out there. Many thought-leaders who evaluate new products like Michael Arrington at Techcrunch strongly advise against blowing a first impression. The risk of doing so is being placed in a bucket of noise that is hard to emerge from later on. The idea makes sense but it’s always hard reconcile with the prevailing sentiment of iterative, experience-based product development cycles. Truth is, it depends on the application you’re working on. My thought is to focus on the core net new experience you’re bringing to the table and to launch when you can demonstrate it completely within the context of a very simple and relevant use case. Under this approach, product innovation can be showcased in a way that matters and is satisfying to a small sub-set of the potential market for the product. The use case(s) has to be focused yet complete to pull off the balancing act between experiential learning and sufficient development cycles. That said, in early product categories (no dominant player), early adopters can be somewhat forgiving. I’ve seen examples of applications where user feedback seems to say “we see what you’re trying to do and believe it’s a valuable problem to solve, but your product hasn’t quite nailed it.” Companies in this bucket seem to have another strike or two left in the count and should be aggressively focused on the break-through experience.

Private Betas

Private betas make sense in a variety of circumstances. It’s the closest tool web companies have to replicate the feeling of exclusivity that comes from lining-up for iPhone on the first day. Word spreads very quickly when a product really works and adds value and the exclusivity factor can help build broader anticipation. But this is not a healthy motivation for a web company in and of itself. These benefits need to be viewed as a serendipitous offshoot of more practical reasons to go private first.

One practical reason is risk management. Inviting a network of peers, consumers, journalists and analysts to the table will provide ample feedback on the product and experience. If all goes as planned, key learnings from the private beta will be manageable to improve upon within a short to medium time frame. Ideally, the space between private and public beta is not very long. But again, the key is to nail the user experience for wider launch and if iterations are required, so be it.

Another pragmatic rationale exists when a web service may only be capable of handling a certain amount of traffic. It makes sense to build the architecture of a service for scalability but not make that part totally functional at the start (overhead and fixed costs) because it may not matter. User feedback on the core features of the service remain the core focus but when they start materializing, it may be necessary to “turn on” more scalability in the platform. Since user uptick is unknown at the start, private betas allow for more contained environments that keep focus on what matters most first.

That said, the current vogue of products staying in a perpetual beta mode seems counter-productive. One year after launch, how can the same core product still be in beta? I think very few product categories require this treatment. Instead, it makes sense to adjust what aspects of the product experience are in beta and which are in full release. Web companies should introduce new facets of the product and partition those in usage and marketing sense as beta while confirming to users that more and more of the experience has progressed beyond it. This is typically done by labeling or calling-out a specific tab or section of the site as beta.

Make it Easy to Leave a Mark

Even good products have a tough time competing for user mindshare. Early product releases need to include some high probability and high value ways of ensuring leveraged consumption. By leveraged consumption I mean ways to use the product to save something, say something or share something. Each of these actions provides users with a feeling of participation that results either is higher repeat usage (we all go back to look for things we place in storage) or referral marketing (sharing is the highest form of referral). The specific use cases that allow for participatory marks to be left on product consumption will vary from product to product.

There’s no way to generalize about all the possible permutations of a web launch. However, if the stars align, a late-stage landing page that builds significant interest with a private launch that is well-received makes for a virtuous circle. If the application has “viral-inside” design (in other words, it’s easy for users to leave their mark), then a great amount of leverage is added upon public release. Those of us building new products can only dream about this ideal sequence while preparing for less immediate traction out of the gate.

I’m very interested to hear about the experiences of others in observing or launching web products. Please feel free to share what you know.

• Techcrunch - Don't Blow Your Beta
• Beta--The Four Letter Word of Web 2.0
• iPhone Debuts in Sea of Hype
• Can iPhone Sustain its Launch Success?

Filed under: User Experiences, Web Apps, Innovation

Email It   Digg This!   Slashdot It!

Tags: iPhone, Product Launches, Private Betas, Landing Pages,