Last week I hosted a group of NYC entrepreneurs who came out to hear from Steve Blank. It was a great event and I am working on getting the video online.

During the night Steve asked the audience a great question; “when did Google launch?”

It was met with blank stares as nobody really knew the answer.

The answer is that they never officially “launched”. Sure they opened up the product to a larger sample, but from the first index of sites, to the next 100,000, to the next 1,000,000 then just kept having people use the product. They outgrew their servers and office space and continued to grow the product. They iterated along the way and used the crawling of the web as a catalyst for growth and adding new hardware.

This has resonated with me and gives an important lesson; never launch, just iterate.

By launching you are setting yourself up for the inevitable drop off in users, interest, and clicks happening at your site. Yes, you can have a press cycle and let folks know at the same time what you are up to, but I believe that having a fixed date can be a detractor from your core mission.

By putting things out there in current form, iterating on feedback, putting the next product out there, then iterating again – puts you in a unique position of always having people using your product.

Although this may not work for everything, I think web services provide the perfect playground to see this in action. I see companies that line up press, users, bloggers, and hope the stars align for their “launch day” whereas they should be concentrating on a useful user experience.

Having an alpha, beta, or early access program (as Steve likes to call it) is great – but having your product being used is the important step.

So launch today, iterate tomorrow, and never have a reason why somebody new can’t get on the system right now.

Post from: Eric Friedman
You should follow me on Twitter here
Never Launch, Just Iterate

This remains one of the core investment thesis ideas in my mind when I look at a company that lives on the web. In an inverse relationship to environmental exhaust where usually the more left behind the worse the system, the web works in just the opposite way. The more data left behind, that can be harvested, the better the underlying network. This process of collection can be done via a lazy login, a deliberate subscription, or a federated login system – in each case allowing the underlying infrastructure you are traveling across (or consuming) the ability to retain this data.

The data retained from data exhaust can be use for many different things. The first and most obvious is to make your experience better. Your profile and activities give off information that can be used and processed with a system, making your experience better the next time you arrive. This presents a sparse data problem for new users and new systems, but once the data asset is in place you have more of an incentive to return.

This dynamic behind a new web service shows the importance of allowing users to traverse across an already present data asset.

Many services do this well today, while others built up this asset of data over time. Being a new user on a service is tough, but the opportunity to grab the data exhaust of each of those new users to turn around and use of for the betterment of the system and other users is great.

Federated login systems such as Facebook Connect and Google Connect enable you to bring your data with you, something that I think will become common place over time. As these paradigms solidify in peoples minds, and the value of such activity becomes apparent I think you will see demand increase to bring a customized set of decisions, opinions, and “personality” with you whenever you sign up for a new web service.

Post from: Eric Friedman
You should follow me on Twitter here
Data Exhaust

I have found that now more than ever I am automatically browsing the web and at an “always logged in” status with many services. Currently those services inlclude; Google, Twitter, my blog, Delicious, Yahoo, and Zoho. Each has their own reason for remaining constantly logged, but 6 services is definitely more than it used to be. At certain times other enterprise software sites or individual web services remain logged in simply because I either forget to log out, or I need them for work I am completing at that time.

Looking at the world through an “always logged in” filter makes things slightly different both from a UI perspective and how important information is surfaced. As we continue to broadcast location, preference, mood, and actions on a regular basis I see this logged feature happening more.

It was not long ago that “always connected” was something new with updates for your browser, anti virus, even your OS becoming more normal. Now with always being logged on changes behavior even further by always having access to your data on another network, in the cloud, keep in touch, and simply use web services the way they are intended. Tracking your movements around the web, sharing your visits with a website publisher, helping target advertising are all after effects of an always connected + always logged in experience.

I am not sure where this is all going but its an exciting ride to see how my own behavior has changed with the advent of such options.

Post from: Eric Friedman
You should follow me on Twitter here
Always Logged In

Analytics
Paramount from the time of launch are the analytics behind any web service. They provide clear insight into where traffic is coming from, where people are spending their time, and where any bottlenecks are occurring. They provide the best way to take an instant pulse of what is going on.

Areas within the realm of analytics range in theory and importance. One area that I spend a lot of time in are referral sources which provide transparency into where people come from before visiting your site.

Currently my two tools that I used for most sandbox projects are Google Analytics and Sitemeter. Both provide overlapping features, but I feel between the both of them I get the real time stats I want (SiteMeter) with the long term trends that I am able to pivot around all sorts of data points. In upcoming projects I have also become interested in trying out Mint – but have never used it personally on any sandbox project.

Scalability
Thinking about how your service will scale from the beginning can mean the difference between a scalable realistic launch with an expected interested and growth curve to a service that cannot handle the load of being linked for any number of social news sites that can bring your site down fast.

Realistic testing of a web service prior to launch is paramount. Hopefully you can do predictive load testing on both the servers themselves and stress test things from a front end user perspective. Overlooking the little things are why many people open the door early to family and friends, those trusted to tell you what is wrong in return for an early peek.

Speed
I have talked about the fact that speed is a feature before and I still stand behind that. The fact that Google results appear in less than 1 second can mean the perceived difference in relevance over another search engine that takes longer. Speed of a system can influence trust, perception, and return visits. I personally look negatively upon a service that delivers on what it promises, but in an unrealistic time frame. For example; if an office application “in the cloud” promises similar features to Microsoft Excel but navigating between cells takes greater than two seconds and calculations take multiple seconds, than the value of working in the application in a browser vs. on the desktop diminishes rapidly.

Deployment and Information
One of the areas that is sometimes overlooked when pulling the curtain back is being prepared for people to find every public facing point of your site. Below is my checklist of things to provide;

1. FAQ – frequently asked questions – usually preemptive of any real users but generated form the friends and family beta round discussed above. Generally, if one person asks you others will have the same question. This also provides an excellent place for someone who is coming through for the first time to get a general sense of
a. The name and short description of your service
b. The problem or purpose of your service
c. Who is behind the service and where it came from
d. Quick facts about the service

2. Contact Form – Whether you are a one man operation or a company filled with employees, having a proper contact form is very important. This also includes having a choice of an email address somewhere near, around, below, or close to the form itself. Give people the choice to fill out the form OR contact you directly. Many people tell me that this induces spam, sales contacts, waste of time contact, or otherwise. To these complaints I ask; How much is a customer worth who wants to get in touch with you? (translation: deal with the spam)

3. Who? All about the team

a. Since so many services are created by a small team or one person, do not be afraid to tell people what is behind the curtain. Having multiple email addresses such as sales@ support@ webmaster@ is confusing and will deter people from making contact. Rather have the form itself route things to the right person with a drop down, or have one clear delivery to everyone.

4. The problem – The solution

a. More often than not I stumble on what the purpose or meaning is behind something. By having this clearly defined can provide that clear concise communication you can get at if you simply drill down into the facts about the service.

Another thing to remember is what your service looks like to first time visitors. Logging into your service as a first time user can show how things look and feel the first time around without an account that is filled up.

To be continued…

Post from: Eric Friedman
You should follow me on Twitter here
Thinking about web services