Ever wonder why European company sounds so mundanely wierd (as oppose to obscurely wierd here in the Valley) ? Egg, Orange, Song, Thus vs. Yahoo, Google, (any startup name).

Well, here is a article with interesting insights into the phenomenon titled “Accidental Naming”

Remember the days of drugs.com selling for $700K? Well, Naseem certainly believe that branding requires clear brand names rather than simple English words. I tend to agree with him but do think that company name should connote something (implicitly or explcitly) in order for the startup to have a leg up in creating a brand personality for the company.

As wierd (and frivolous) as it sounds I find the process of finding a name quite a bonding experience for the founding team. In many ways its the first step toward creating and finding a collective vision for the venture. People like to talk about strategic inflection points, in the first 3-6 month of launching a company, a simple “naming” exercise can be that turning point. The brain storming, debate, and agreement process can be the very first step in learning to work together and finding common ownership in a “work product.” Many times it can become the “point of no return” where everyone decides to jump in and forgoe their previous commitments/jobs.

Ofcourse, dont let finding a name kep you from tending to the many short term priorities you can’t take your eyes off - like product development and funding. . . .

I’ve been waiting for this for over 7 years. Anyone living/working in Palo Alto especially on Sand Hill Road knows exactly what I’m talking about. (Ironic that the center of the information revolution - Palo Alto, and more specifically Sand Hill, has had spotty coverage for years.)

Here is the WSJ article.

All this for around $600 bucks (the cost of a high end handset)

Now I wonder if I can get Cingular or Sprint to pay me for third party traffic I route to their network (that would only be fair for their crappy service). . . kinda like distributed power generation. . .

BTW, I wonder which VC would be the first to get one (or already has one!)

Blogspotting has posted a conversation Heather Green had with Scott Gatz. In it she writes that

And Gatz imagines amping that up so that you can get these alerts delivered to you when and where you want, whether it’s on your cell phone or even in your living room over a settop box. So, say, if a Soho apartment in the right range comes up for sale and you’re in Central Park uptown, an alert would be sent automatically to your phone, allowing you to scoot downtown and take a gander.

Ok so that sounds fine and pretty cool to me but I’m getting a little confused . . .

Then comes this line. . .

Still, Gatz doesn’t think that centralized services go away completely.

Ok now I’m confused. In fact for the above scenerio to happen a centralized service will almost HAVE to exist. If I’m not mistaken, RSS is a pull architecture. It would be almost improbably inefficient for a cellphone app to ping the RSS feed every 10 sec to get updates on SOHO housing prices. Furthermore, the RSS feed will have no way of uniquely identifying the feed request and thus serving up a personalized listings. What needs to happen is for the RSS feed service to ping ONE centralized server that new content has been added/updated, the server will comeback and grab ALL the new content, then it will selectively push that content (using a proprietary protocol) to subscribers who wants a portion of that content (such as houses in a certain price range).

Maybe Scott is planning to implement proprietary RSS feeds or proprietary applications to create some sort of barrier to entry for Yahoo! (which is the central server scenerio I described). OR he is assuming that a authentication & push implementation of RSS is going to be part of RSS 3.0. In that case, I am eargerly waiting for the future - free and open.

I tend to get stuck on one train of thought and it takes me a while to get off it. . so more open souce ideas today . . . (I promise to get off this open source thing over the weekend)

I think the world needs an open source hosting platform. Before I get into what it is exactly, here is why. . .

1. Software as a service - aka hosted model, aka ASP, aka on-demand (thanks to salesforce.com for adding to a list of confusing acronym) is finally becoming a reality after over 5 years of hype (anyone remember Corio?). SMB and even some larger enterprises have begun to adopt the model.

2. Open Source software is moving beyond infrastruture to applications (both enterprise and personal/group utility)

3. Some Open Source applications will need some sort of hosting to be delivered to the end user to offer end-to-end solution, increase adoption, and compete with commercial hosted software.

4. Hosting costs money

5. Open Source contributors contribute brains but not money (asking for contribution doesnt quite work)

6. Open source infratructure stack is becoming more and more standardized - LAMP+Jboss?

7. Open Source contributors & users do have some limited bandwidth and CPU cycle on their machine

So why doesnt someone create a program that aggregates the LAMP stack and add virtualization layer to the stack so that users of open source software as well as contributors can “tie” their computers together to create a free virtual p2p hosting platform? Be a great way for users to give back and contribute to the programs they are using. Can definitely let hosting resource contributors set limits as far as bandwidth/cpu cycles. And perhaps only people with broadband speed of over XXX Mbps can join the network. Also integration with eclipse and sourceforge would be nice to let project admins push code to the platform seemlessly.

Obviously lots of people will still want to modify the open source code and host the software themselves. But for lots of applications that would not make a lot of sense. Think of all the personal or group utility/ware thats being produced ( all the open source wiki’s for one) that could be hosted on the platform. BTW, this could be used for open source webservices too which would need a hosting service even more critically.

If whoever is creating this really really wants to make money he can also embed an option for the source owner to charge for usage. By building a billing platform for source owners (like content owners in Brightcove’s biz model), the company can take a cut of the transaction.

I’m sure there is a lot of lantency issues that still need to be solved. But it might not be such a far-fetched idea in the near future.

Jeff Nolan posted some notes on Blake Ross’ thoughts on Firefox’s product philosophy and practices here. As you’ll knows, I’ve been very interested in the whole PM function within the context of an open source project and this post provided me with lots of good insights.

Generic thoughts I agree with…

- making easy to use/simple applications is harder to do than most people think
- many times, the ONLY way to make easy to use applications is to cut functionality/features (there is only so much UI design can do)
- nothing can replace the human interaction as far as understanding the needs of existing and future customers

Futhermore here are the development rules Ross abide by:

Development rule #1: all patches are not created equal. Second level of review that evaluates not simply whether the code is sound, but is it doing something useful. This is a departure from typical open source projects which gravitate to sound code belonging in the tree.

Rule #2: All users are not created equal. Firefox has a voting mechanism for bugs, but a lot of votes aren’t necessarily heavily weighted if the source of the votes is regional or somehow. They also claim to be a meritocracy where peer respect is critical to having a voice in the community.

Rule #3: Make decisions and get a thick skin.

#1 is a PM funtional responsibility that Open Source projects are getting smart to.

#2 is very interesting. Most companies have “customer councils” but this voting system really expands the sample size so PM’s wont get sample biases. Ofcourse, how to incorporate the needs FUTURE customers is question that is not addressed by this system effectively. Either case, increased transparency is something that closed sourced company should work on with their customers. (Kinda of a “architecture of semi-participation”) Of course this rule also reminded me of my “market efficiency” theory with regards to PM a few posts back.

Another nugget was that

Why was Firefox created? The only reason it was created was because people were asking for it. The problem with Netscape was too many cooks in the kitchen… endless debate and infighting by too many people and they didn’t listen to customers.

I would not be surprised if the “cooks” where product managers. Maybe lots of companies are over staffed with PM’s and should let engineers take over some of these responsibilties. (Or maybe not, cause I still need to make money somehow )

I quote Blake on his latest post

I expect more developers would be disgusted, too, if they interacted with Normal Human Beings using software on a regular basis. But the emergence of “usability” as a separate industry only insulates them.

Very true, that sometimes specialization reduces an individual’s sense of responsibility and de-humanizes decision making. Product Managers are effected by the “usability malaise” in much the same way. The problem is that without specialization all of us would not get to see our wifes for dinner.

Ripple has to be the coolest application of this whole social XXXX (network, software etc) trend. Thanks for Bubble Generation for pointing this out to me. It is even an open source project, the sourceforge project home page is here. Too bad it doesnt look like Ripple has a lot of traction getting code contributors. (But if they need a PM, I’m able and willing)

I think the idea has legs given enough resources and integration with an existing social network (linkedin?). What has me excited was that there is actually an analog analog in Asia. Given their less developed financial markets, emerging countries in Asia has long developed P2P, micro-lending, and social network based “mini-financial markets.” When I was little, I remember groups of relatives, neighbors, or co-workers will form co-ops (no more than 10 people) where members of group will take turn borrowing from the rest of the group for a short duration (~1 year). Credits are established through friendships or blood relations implying simple understanding of the borrower’s willingness to pay back as well as financial standing. Ofcourse Ripple extends that model by finding trusted “chains” rather than circles which makes sense given our ability to map networks through technology. Although I do think marketing wise, Ripple shoud focus on acquiring “group” based lending networks which will be much easier to achieve critical mass while “chain” based model will allow it to scale in the future.

Metcalfe’s Law was the mantra of the dot-com generation. With it, spawned dozen of more mundane but more digestible corollaries: winner takes all, network effects, first mover advantage, time-based competitive strategy, time to market advantages, etc. While it certainly lost some of its luster, its impact on the technology industry can not be understated. Entire venture capital firm, read Benchmark, has made innumerable billions investing in “network effects” or as Bill Gurley calls it “Increasing Marginal Utility” ventures. Companies like eBay, Keen, uShip, Zopa, Betfair, Dropshop, Shopping.com, WorldWinner, Ingenio, Open Table (wow thats long list) were founded/funded based on the “law” by Benchmark.

So what happened to Metcalfe in China? Before Taobao, EachNet had 80% of the market. Before Baidu, Google had similar domination. A few years later, both former leaders are losing market share and fighting teeth and nail to recover its former glory. Both companies were typical network effects business models - eachNet with its marketplace, Google with its advertising network. Certainly Metcalf law does tilt the scale in favor of the incumbent, but it doesnt mean the game is over. In fact, what happened in China deserves deep introspection for entrepeneurs working at Web 2.0 companies taking on Web 1.0 incumbents. Here are some of the things I gleamed (I’m sure there are more, especially for those on the inside)

1. Metcalf’s law is less powerful when the incumbent owns a large percentage of a small nascent market. Overall Internet penetration was/still very low in China when eachNet and Google achieved its leading position. With a large percentage of the total addressable market still up for grabs, late entrants still have an opportunity to gain marketshare and match the critical mass achieved by incumbents in a short (or even shorter) amount of time based purely on the fact that adoption rate are often expotential. This is key, in that, given an exponential growth rate of a small emerging market, late entrants can actually “catch-up” to the incumbents quickly if they are able to acquire these new users (which is still hard to do given Metcalf’s law). So how can they capture these novice users? That brings me to the next point.

2. More importantly the total addressable market is highly heterogeneous- that the market is segmented into various groups which is very different on a attitudinal, behavioural, and demographic basis. This allows new entrants to creat tailored solutions which offer a particular segment more bundled value than that offered simply through network value. (think localization & more) In China, these new users were different enough from the early adopter that using Taobao or Baidu’s solution made much more sense than eachNet or Google. In fact, the brand awareness of the incumbents was low enough in the total addressable market, that the “law” conferred much less advantage than previously thought.

3. Heterogeneity must also exist in the way users make their purchase/adoption decision. In typical marketing parlance, the awareness-consideration-purchase funnel must be decidedly different in the target segment for the late entrants (from the segment which the incumbent owns) to enable them to effectively market/sell to that segment. In China, the later adoptors were much less affluent, much less web-literate, and live in less urban areas outside of Beijing and Shanghai. By putting more feet on the ground, being more scrappy, and messaging in a decidedly different channel geographically/offline/online, late comers were able to convince users to use their solutions instead.

Paypal China is now online. Despite articles (Reuters & WSJ) which says the service will be launched by “end of the year,” the service is now available online. Couple of interesting notes,

1. Looks like the service is free for merchants and for p2p transactions, eBay is getting aggressive with pricing to compete with Alibaba
2. Partners with the same banks as Alipay - China Merchants Bank and China Construction Bank
3. No escrow, instead it’s betting that Buyer Protection is good enough to compete for “trust”
4. The lack of escrow will also translates to transaction simplicity/ease of use which Paypal hopes to be a competitive advantage
5. Alipay claims to process US$12M in payments a month, so Paypal will have a ways to go
6. Paypal brand name in Chinese is “treasure” “spelled backwards” - ie the two Chinese characters are switched. Interesting to note that while it is a phonetic translation - its sounds like PayPal in English, the name also plays on the word “treasure” which is a prominent brand word/character that Taoboa (”Find Treasure”) and AliPay (”Payment Treasure”) employs prominently. Dont think its a coincidence despite the phonetic similarity to English that the PayPal Chinese team decided to use the word “treasure.”

The Diffusion Group released a report claiming huge market for Podcasting. Quoting from
Om Malik’s blog

TDG’s new report, Podcasting: Fact, Fiction and Opportunity, suggests that between 2004 and 2010, the use of podcasting among US consumers will enjoy a compound annual growth rate (CAGR) of 101%.

Rssblog also made fun of the report.

Given that I’ve came up a few of the market sizing estimates before in my life time, I want to share a few tricks. One of the best way to get a huge market size number is to take an existing related market and count that in the “new” market. If you think that the old market will be replaced or augmented with the new technolgy, its can be a somewhat defensible estimate. I dont have access to the research report but I bet that if you count in the audio books market and factor in somesort of e-commerce penetration rate (its a $800M market based on a businessweek article I dug up) you can certainly claim that Podcasting is a billion $ market eventually. It all really depends on how you define Podcasts - commercial recordings or only amateur “audio-blogs.”

Also a random thought. . . I bet the legal/trademark department of Apple is having a hard time trying to manage this “Podcasting” phenomenon. I wonder if the fact that Podcasting/Podcast is not an Apple trademark will adversly effect its ability to defend “iPod.”

Last week a couple venture fund cropped up claiming to be “RSS” focused VC’s. (1, 2, 3, 4, 5, 6, 7) But if you dig a little deeper you’ll realize that they are simply using RSS as a marketing angle (a little disgenuous?). Instead, what they really want to say is that they are a “XML” funds. Funny how an old buzz word like XML is now being replaced with a catchier acronym - the final sign that XML is now fully in the “tornado” phase of adoption.

That had me thinking about broader uses of RSS as a general XML schema because RSS needs to expand its current applications in order for there to be enough companies for these VC’s to fund. As I explore the various application scenerios and use cases I kept on coming back to two extensions that RSS currently lacks. 1. Authentication 2. Push Implementation of RSS.

Now, lots of people has been clamoring for the above things for quite a while (and people are working to incorporate it into the standard as Atom with its more centralized development process has it). Furthermore, RSS can certainly be hacked to do both of these things. But the key here is how to gain broad concensus on the new extension so all RSS “readers” can understand all implementation.

1. Authentication - beyond simple security reasons (seem to be what previous blog conversations focused on), I want RSS authentication to allow me to build products that create personalized feeds AND personalized content modules within feeds. I cant emphasize how much more applications I can think of when personalization comes to RSS. Similarily, the switch from static web pages to dynamically generated web pages enabled much of the web as we know it today. Furthermore, content aggregators like myYahoo seems to have all the leverage and user lock-in due to the fact that personalization comes in the form of selective aggregation. With feed personalization, the power and value add will shift back to the content providers allowing businesses to embrace RSS as a method to build brand loyalty.

2. Push RSS - A little harder to implement and a little less interesting. Still because RSS is essentially a pull protocol (the “S” for syndication makes people think its push but its really not) there lacks a real-time component to RSS needed for certain use cases. For example, if you really want to use RSS for publishing inventory information to your trade partners you’ll need 1) authentication 2) some way of pro-actively alerting trade partner’s interfaces that inventory information has been updated & push data out at the same time. You can ofcourse have your trade partners’ systems ping the feed every 10 second to see if anthing changed, or ping the server with update notice and have it get the RSS feed but I dont think thats very efficient nor very real-time. I dont think push will replace the current system because the current implementation is actually a much more efficient architecture given hundreds if not thousands of subscribers. But for real-time B2B implementation where the subscriber base will likely be low hundreds at the most, the server load issue will not be as acute to simultaneously push out data to subscribers. (Ofcourse a good argument would be why would you want to use RSS to do this in the first place)