Silicon Valley Technology Commentary & Archives · Est. 2006 3,032 Posts · 2006–2026

July 15, 2009

July 15, 2009 · 3 MIN READ · BY LOUIS GRAY

Venture Capitalists, But In Text Form

Venture Capitalists, But In Text Form

On Monday night, during a blogger briefing, I struck up a conversation with Dave McClure (he being the Master of 500 Hats) around the process of blogging, and participating in those social networks where we have put our energy. And during this exchange I said something that I have long held as a driver for me, but hadn't yet quite articulated in this way - that as a blogger and technology enthusiast, be it for hardware gadgets, software or Web services, I sometimes take on the role of a venture capitalist, investing not my own money, as I have little, but instead, my focus, my words, and my time.

Venture capitalists are wooed constantly by companies looking to get off the ground, or to gain a push to the next level, be it greater visibility, higher market share, or profitability. And the VCs have to make a choice. Not having unlimited funds, they need to determine which companies, markets and individuals can get access to those dollars. The VCs, based on their own expertise, their analysis of the products' future, the potential market and the products' uniqueness, invest a percentage of their available portfolio, and then push to help make those investments a success - often helping to connect the founders with partners, customers, or providing guidance through board positions and personnel.

Similarly, whether as bloggers, social media participants or technology acquirers, we too are bombarded with choices. With limited funds ourselves, and limited hours in each day, and limited opportunity for attention, we have to make choices as to which products we will buy, which social networks we will embrace, and which companies' services we will use or cover. And while many bloggers aim to be as impartial as possible, keeping a journalistic line to avoid 'favorites', we all have a bias. And some of us wear our hearts on our sleeve, clearly choosing this route, as I told Dave, of being "venture capitalists in text form".

On Monday, Dave and I talked about the array of social networks vying for our time, and he told me that he had once tried to evenly split his time between a handful, but eventually focused on Facebook, LinkedIn and Twitter. While not shutting off his data flow to other networks, he simply stopped using them, picking up his chips and moving elsewhere. Meanwhile, in my role more as an angel investor (in text form) than a late-stage investor, I am more willing to make more aggressive investments in a wider array of smaller services just getting off the ground. And I will make those investments of my time, not always because I think they are going to be the most popular products of all time, but because I see they have the potential to be the best - even if I know that this potential means my bet is of higher risk, for my chosen solutions have a higher chance of closing and washing my investment away.

If you have read this blog for long, you will know that there are some services I really believe in - ones that I have selected based on their merits, and ones that I choose to invest my own time in to use personally, and to cover often. And should they 'pop' and become successful, leaving my little realm and moving on to the larger stages, like we saw with Socialmedian and TweetDeck last year, I won't get rewarded monetarily in any way, but am rewarded to know that I had some impact, and that I saw a real return on the investment to see people and products I invested time in have their success come to fruition. It's likely the same reason that Mike Arrington, at TechCrunch's 4th birthday party, which I attended, highlighted the fact that many in the room had gone on to make a lot of money since debuting on his blog, more than he focused on his own success. Even if he didn't gain monetarily directly from their success, as a VC (in text form), he had a member of the family graduate.

Not every investment will be a winner. Some of the products I've really liked (on paper anyway) have already closed. Some have flatlined or not gained the momentum I had hoped they would. But just like in the world of VCs, it only takes a few home runs to make the whole thing profitable. I'll keep writing and you watch where I invest my time and my words.

July 13, 2009

July 13, 2009 · 5 MIN READ · BY LOUIS GRAY

We Have Invites! Five Stages of Beta and Battling to Get Access

We Have Invites! Five Stages of Beta and Battling to Get Access

When launching a new service, entrepreneurs have a myriad of things that make them nervous. Maybe the product won't be seen as having value. Maybe competitive offerings are good enough. Maybe there are bugs that nobody has discovered yet. And sometimes, the rush of new users who arrive to kick the tires is enough to break the system, as the infrastructure is not ready. To help reduce such public outages, many products start out with a small audience, and there are many ways to grow slowly, each with their own pitfalls.

1. The Closed Private Beta

Often sites will have a private beta period, open only to a known set of users, typically starting with the company's inner-most friends and supporters. In order to get onto the list, you have to know somebody at the company, or be so influential to gain early access.

The upside for a private beta to the developers means that typically the product is in safe hands of people who understand what you are doing, and are willing to forgive rough edges and mistakes. Also, the small load means you can fix bugs leisurely without the threat of public exposure.

The downside for the private beta is that the site itself still isn't really being tested by a more natural audience, either in terms of how they plan to use the service, or in terms of scale. What might work during a closed private beta might not be good enough when the doors open.

2. The Private Beta With Open Invitations

Sometimes, a site will start with a private beta period, but users can invite their friends - often a limited number. You saw this with GMail back in 2004, when early users could invite others, but only a few at a time. Similarly, FriendFeed did the same in 2007, as did Toluu in 2008, closing their early sites off to the mainstream, but letting you in if you knew somebody who had already gotten through.

The upside for this process is much like the closed beta in that the audience is going to be relatively forgiving and small. Also, the influx of less-known people can give a more realistic expectation of what features are needed and which need to be improved.

The downside for this process is that there may be people who could help try the product who don't have an in, so their interest is muted. Also, the small group tends to be insular and will use the product differently than an open audience.

3. The Numerically Limited Invitation Beta

After internal testing, some products will release a known quantity of invites, either through their Web site, or the media, in an effort to expand the testing, and give early users a flavor of the site. The invites, often tied to specific sources for tracking purposes, can range from few dozen to hundreds or even thousands, depending on how robust a test, and how deep the infrastructure. We've recently seen this approach with the site Lazyfeed, which gave out a few hundred invites in the last week by way of TechCrunch, ReadWriteWeb and from me, both on FriendFeed and Twitter.

The upside in this case is that this wave of users best simulates actual usage of a product, to see what is working and what is not working, while stressing the system's back-end only to a predetermined level.

The downside is that users who don't get to the invites quickly can get discouraged, and often, the very first people to get in aren't necessarily the ones who will most deeply investigate your product, but instead, happen to be those who were fastest at getting to the news and signing up.

4. The Open Beta

For some services who don't want to limit the testing, they might open up a site to all who wish to register, but do so under the guise of a "beta" tag, explaining that some features might be missing and others might break. While anybody can enter, they should not assume full functionality. You could see this with GMail for years, even after the product went away from strict invites.

For developers, the upside here is that they have a perpetual excuse for problems. But it's beta! Also, any user who wants in can get in, without having to get on a list or know someone. It also can often give the ability to stress-test a product under the impact of a large audience.

Downside is more limited, but can be seen if users are more wary of beta products, preferring to wait until they are more stable for use.

5. No Beta

Some products might skip the beta process altogether. They are just open for business, period. This removes the guise of the testing period and lets the entire audience at them at once. I call this the "Open. Fail. Scale." method, because often there are bumps along the way that come with growing a product, and one can never anticipate them all. Twitter would be a fantastic example of this, although both its fail and scale have gone on more than anticipated.

So how do you choose, if you are an entrepreneur, how to get your product out the door? You can see, for instance, that Brizzly, by Thing Labs, is still in Private Beta. (And I want in) Lazy Feed is opening up more, and you can get an invite here. They each may have their own reasons. In the example of Brizzly, it's probably not ready yet. For Lazyfeed, maybe they aren't ready for a million support questions and they want to start slow.

I tend to believe you should open as big as you possibly can without breaking. If users want to get in to your service, don't stop them in their tracks. Just set expectations and work with them as partners to continue to improve. Don't insult them by using beta as an excuse, but instead as a stepping stone. And yes, get me in as early as possible. I promise I won't break anything.
July 13, 2009 · 1 MIN READ · BY LOUIS GRAY

Will Mainstream Adoption of GPS Reduce the Need for Google Maps?

Will Mainstream Adoption of GPS Reduce the Need for Google Maps?

Last week, for the first time in a while, I finally went gadget shopping. On my short list of things I wanted to possibly get was a GPS unit for my car. With my traveling more frequently to various meetups in the evening, combined with my notorious penchant for getting lost, having a GPS unit on hand has practically become a necessity. And unfortunately for me, Robert Scoble's having been an early adopter didn't mean that one came with his hand-me-down car. So when I spotted a Garmin Nuvi 265 unit in a gadget vending machine for a reasonable price at the local mall, I pounced.

And now, with handy directions on my dashboard to practically anywhere I need to go, I know I'm going to stop going to Google Maps. So gone are the days of my having piles of papers printed out from Google Maps from trips since past.

Like most Web consumers, I slowly made the move from Mapquest to Yahoo! Maps and eventually to Google Maps. Google continues to expand their geo-team with Google Earth and Google StreetView, but for me, this little unit from Garmin means I don't really care all that much. So what will happen next, assuming that all vehicles going forward, and eventually all smartphones, will have this data? I understand that Google data could power each of these devices, but the actual process of going to Google Maps, putting in a starting location and an ending destination, as we have done for years, is decimated. It's just not going to happen for me.

Today, I'm solving my need to find out where to go, step by step, with a dedicated unit - an interim step before GPS is an embedded, standard feature in my car. It's part of a natural progression, one I don't see reversing. If you have a GPS unit, are you using Google Maps any more?

July 12, 2009

July 12, 2009 · 6 MIN READ · BY LOUIS GRAY

What Is This Real-Time Thing, And Where Is It Going?

What Is This Real-Time Thing, And Where Is It Going?

The final panel at Friday's CrunchUp focused on the phenomenon of real-time, featuring a high-profile panel complete with representatives from Google, Microsoft, TweetDeck, TweetMeme, Seesmic, FriendFeed, Stanford University and a pair of venture capitalists. The discussion ranged from the opinion that real time was simply yet another feature, or a revolution in terms of application and Web service development, while the panelists discussed revenue opportunity or how large companies would try and control the data from being shared with competition.

Iain Dodsworth of TweetDeck said that his own experiences using his Twitter application had a dramatic impact on how he was using the Web. "I was using TweetDeck more than anything else," he said. "I wasn't using e-mail or RSS and this to me was a massively big deal. I wasn't going to Web pages any more. I was going to stream data and that was what I was consuming now."

And while Dodsworth and many of us early adopters may have gotten to this stage before a more mainstream audience, the trend seemed to be recognized across the board. Google and Microsoft representatives talked about how they were working to best harness the real-time phenomenon, with the advent of Google Wave, and in Microsoft's case, trying to find ways to improve the user experience for hundreds of millions simultaneously, all while maintaining a stable infrastructure.

David Hornik of August Capital Venture Partners said he believed the advent of real time was "an important piece of the evolution", harkening back to what he called the "dark days of RSS" where that was considered real-time. He said that the problems faced in the early days of RSS, around sorting and filtering, had only escalated since, saying "we have that problem in spades".

A relative newcomer in the shadows of monoliths like Google and Microsoft, FriendFeed has helped push the envelope on the world of real-time as much as practically any other service, spurring on social networks like Facebook to do the same. Representing the company, co-founder Bret Taylor said real-time was no longer becoming an oddity, but instead a core aspect of the Web experience.

"Real time is an important feature of every site. It can now be said that every product evolves until it has e-mail, a social network and real time. It is something that all products will incorporate," Bret said, adding that one of the biggest challenges in this new realm was how to display the stream of data. "There is a tension between the simplicity of chronology and the need for filtering and ranking. You don't want to lose the feeling that you know something when it comes out. You need a mix of things that recently happened with things you need to see, and get a sense of both. If something is missing, users get an uncomfortable, anxious feeling."

And it is the user experience that will likely make or break services, in terms of how they can master the flow. Kevin Marks, who recently left Google, and announced that he will be joining British Telecom to work on standards, said it is about finding value in the data.

"It is about the flow and sense of flow," said Marks. "Real-time is one piece of that dimension and preserving history, so it can be found again and discovered later. This is something that FriendFeed is doing better than Twitter. Those things that used to be real time are now stored."

And storing the data for later consumption is getting increasingly difficult as the total volume continues to skyrocket. Andreas Weigend of Stanford noted the total volume of data had increased an order of magnitude just in the last five years.

"The real-time aspect is one way to incentivize people to make actions with their data," Weigend said. "It is not just about the data, but what question you ask, and the experience. It is how fast it is for me to get a question answered. The real-time aspect is the timescale of innovation being an order of magnitude faster."

But while everyone on the panel clearly recognized that real-time was being integrated into many services, and users were looking to make sense of the data explosion, there were clearly concerns about interoperability, and having services communicate well with others. Often, the current situation was compared to the wars that once were rife in the Instant Messaging world, where different providers simply did not communicate - such as from AOL to Yahoo! or MSN. Not surprisingly, much of that debate was on the two largest providers - Twitter and Facebook.

Bret Taylor hoped that the battle would be different this time around, pointing specifically to the work Kevin Marks and others have pursued around standards.

"Users will demand interoperability," Bret said. "If your friend uses Twitter for broadcasting shared links and if you use Facebook, it is reasonable to be frustrated about that. If (somebody like) Yahoo! wanted to compete, they wouldn't need to compete, they would have to set up ad hoc or formal standards and it would just work."

Daniel Lewin of Microsoft agreed, saying, "As long as you adhere to core standards, which we are committing to, there is an evolution of use cases. People experiment, interesting things will happen, and as time rises, there will be capabilities where end-users will program what they want."

In many cases, the move to real-time came as developers and users grew tired with slowness elsewhere. As we have discussed a few times, in terms of the speed of RSS versus that of Twitter, FriendFeed and other networks, there can be a gulf between what was previously acceptable and what is expected now. It's a major reason why, for instance, Nick Halstead and the team at TweetMeme started to focus on their current product more, and less on their original site, Favorit.

"Real time is about collecting news in real time," Nick said. "The slowness of Feedburner is quite well known and we didn't realize it until we ran TweetMeme and we would see it two seconds later. We would go fetch it and find it 20 minutes later on Google. The important thing is instant. You press the button and it goes back to Twitter. It is fun for me to watch FriendFeed. I push retweet and it shows up on seconds in FriendFeed. The trends we see appear and something might get retweeted 50-60 times in 20 seconds and we can bubble it up in front of users interested in those things, get the content in front of people who want to see it."

And it's not just Twitter that's pushing the gas pedal. Loic Le Meur of Seesmic said the company is pushing more than 4 million API calls to Facebook per day. Just yesterday, Loic added the number of active users on Facebook had doubled in a single week.

Loic added, "It's not about the tool. It's about the people, realizing they have communities around themselves. It will go from tool to tool. In a few years, it might be our tools, and it might not. What matters is how it transfers to real life."

The conclusions? We are at the very beginning, still, of determining how to best harness the firehose of real time data. Tools like Twitter Search, FriendFeed, TweetDeck, Seesmic, TweetMeme and others are working to parse the signal from the noise. It's suggested that real-time will become a major part of many applications going forward, and users are still going to be in the experimentation phase of how they imbibe the data, or in terms of what kind of interfaces they will use to be best satisfied. There remain concerns about openness and how companies will play well with each other, especially if they are in a leadership position. And it's very likely that in five years, many of the names we consider household names today may be gone, replaced with others. It's all going to play out in real-time in front of our eyes.