SocialStartups.com

Customer forums are always interesting, particularly for e-commerce sites. There is something about staying at home and being bored that ultimately leads people to “window shop” online, which leads them to socializing with other people who are doing the exact same thing. The range of personalities is wild and wildly interesting.

Four hundred and twenty eight posts ago, I started a thread on the Etsy forums. The thread was intended to have two purposes. One was to simply get a sense of the community and introduce myself to them. Second, I wanted to get some better intuition as to how sophisticated Etsy sellers (the majority of forum posters) are about running their business and the e-commerce business generally. So I asked a basic prioritization question – would you rather us make search better or fix a bug that would occasionally reset the page views counter on your item listing pages? (For those curious, the views system is stored entirely in a cache, and when the cache gets full and a record gets evicted, the page view number resets to 0. Clearly, the system was not engineered to be used in this manner.) My follow up was, if fixing the view system is not a priority, would you rather we get rid of it entirely or keep it broken.

The danger is to get lulled into an urgency to please. When hundreds of users are demanding a feature, you may feel compelled to acquiesce and build the requested feature. Before you do that, stop and consider Henry Ford: “If I did what people said they wanted, I would have built a faster horse.” (or something like that.) Customers are excellent gauges as when something is wrong, but can be extremely misleading about both what exactly is wrong and how it should be fixed. Furthermore, customers do not (or should not) have better visibility than you do into strategic goals, key business metrics, engineering resources, etc. They don’t have your long-term vision nor your understanding of complex dependencies. So don’t jump the gun. Listen, follow the comments to the source, and solve the root of the problem.

While on the subway heading back to Brooklyn – I had gone to see Iron Man at Union Square, it was great – I was thinking about Microsoft. I was trying to imagine what exactly Microsoft could do that 1) doesn’t have an entrenched player, and 2) they might be able to be successful at. Search the Google way, in my opinion, does not satisfy either requirement, even if they bought Yahoo. So what else?

I considered Tim O’Reilly’s suggestion of investing in pieces of an “Internet Operating System”, which could be the answer although they’d have to fight Amazon, Google, Cisco and others for the bragging rights. Requirement (1) no, (2) yes.

I considered gaming, hardware, healthcare, social networking, and others…. but Microsoft is always involved there with mixed success. Is there anything left?

I’ve got a crazy suggestion. And yes, your own personal blog is the perfect place for crazy suggestions. So here it is – Microsoft should work to be the #1 destination site for vertical searching of the “organic web” (I just made that phrase up). The organic web would be defined as information that is continually changing. One example is airline ticket prices. Another is real estate, and another is classifieds. Microsoft should go out and develop / acquire any company who currently has the following properties: (1) The relevant data changes continuously, (2) The site is a leading player in their vertical, and (3) search is the main user activity on the site. Examples I can think of are Farecast (they bought this one), Craigslist (good luck there), and Redfin. With insider access to the data, Microsoft could provide superior search experiences to Google. Microsoft could then create a search portal that would be the first place everyone would go to search for data in these areas. Google’s crawlers can only go so fast – if Microsoft could provide a “real-time” search engine customized to a particular vertical, they could differentiate themselves in a very powerful way.

That’s it, keeping it short tonight since I’ve got a meeting in 10 hours with the CEO, COO, a few others.

Om Malik wrote an interesting post about twitter pricing yesterday, but I think he’s a little off. I don’t blame him, considering his background is not computer science. And besides, it started a really interesting conversation. Before we start talking about Twitter pricing plans, we need to come to an agreement about what technically is hurting Twitter. Ideally, scaling issues should be orthogonal to your business plan; if you are successful, lots of people use your product, and that’s a good problem to have. Generally, you don’t want to tax your best users.

So on to the technology. Here’s the clue that we’ll start with:

Twitter is, fundamentally, a messaging system. Twitter was not architected as a messaging system, however. For expediency’s sake, Twitter was built with technologies and practices that are more appropriate to a content management system.

From Twitter’s post on architecture and the problems they are facing 

When I read “content management system”, I’m thinking “blogging platform”. My guess is that Twitter is built to be a massively multi-user blogging and blog reading system – every user gets a blog to publish posts with and a blog reader to aggregate the posts of their friends. Considering Evan Williams was the founder of Blogger, I think it’s pretty reasonable.

So if you think of it that way, then the obvious way to architect the system is publishing via RSS and aggregating via RSS. When you write a new tweet, your message gets stored in the database. (Yes, shoving all of that data into a database is a really difficult engineering problem in itself. Assuredly they will partition across multiple databases if they don’t already.) The massive pain comes in when pulling in what your friends’ tweets are. Let’s talk through how it works. Your twitter homepage is acting like an RSS reader, so first it will lookup all of the feeds it needs to check – all of the people you follow. Then, for every person you follow, an RSS feed will be read or generated. The resulting set of RSS feeds will be merged back together and sorted chronologically. The result is your Twitter homepage.

Notice here that this is what is called a “pull” or “poll” model – you are checking for new posts whether there are new posts or not. This can generate a ton of unnecessary load on servers and databases, not to mention network traffic costs. With the advent of Twitter applications, these applications are constantly polling Twitter to see if there is anything new to publish. Ping, ping, ping. All to see if there is something new afoot.

Which brings us around to pricing. It is not, as Om suggested, Scoble’s fault for having 25,000 people following him. The cost is not sending one of his messages 25,000 times. No, actually it’s Scoble’s fault for following 21,000 people and constantly checking for new tweets from those people. It’s also the fault of power users like him using applications that aggressively use the Twitter API to check for new tweets – most likely the same people who use those applications are following large numbers of people.

As with all scaling problems, the first idea is “cache more!”. And sure, you can cache the heavy Twitter producers. But Scoble isn’t following just the big twitter users – he’s following everyone he can, because that’s how he believes he can get an edge on news and trends. Can the long tail be cached? Doubtful – there are too many users who fall into that category. Can you charge those who follow more than, say, 1000 people? Maybe $10 a month for every thousand people you follow, with the first 1,000 free? That could work, but it’s risky. Would Scoble, in the face of paying $210 a month, permanently switch to Pownce? Or Friendfeed if they built a twitter clone? How many would follow?

The solution, of course, is to do exactly what Twitter says they are doing – switch to a different model and scale horizontally (“throw more machines at it”). I’m interested to see how it turns out for them.

How Thinking Costs You – washingtonpost.com

Found this via Paul Kedrosky’s Weekend Reading post.

Really interesting stuff – given that people are really bad at making correct stock market predictions, the more information they know, the worse they perform.

Behavioral economics studies these phenomena, and firms are counting on it.

I wonder if this is true in other areas as well, like deciding on how to price items for sale on Etsy.

Tags: behavioraleconomics, pricing

I think the best innovation from twitter was messaging with @username. If I remember right, Twitter didn’t support that at first – it was a grassroots invention by Twitter users that was picked up and officially supported. Facebook did something similar even before Twitter: when you wrote a post on your Facebook blog (haven’t seen much uptake there), you can choose from your friends list which friends are mentioned in the post. Kinda kludgy solution though, since you have to scroll through hundreds of people and click a bunch of checkboxes.

It’s obvious from the evolution of @replies on Twitter that this is something very organic and natural to humans. The internet is not a solitary vacuum; all software is social.

So here’s a thought: let’s bring @replies to the rest of the web. Whether I’m writing a post on my blog or commenting on a Flickr photo or sharing an item on Google Reader, I should be able to use @username. This serves two purposes.

1. Who is being referred to?

One is to give everyone reading your comment to understand who you are talking to. This is a basic tenet of face-to-face group communication – you turn to a specific person in the group, address them by name, and speak. Sometimes, like at a big dinner party, you might not know all the guests, leaving you guessing as to who is whom and what their background is. On the internet, we can do better. By linking to some kind of profile, the comment reader can read up on who is being pulled into the conversation and better understand context.

2. Who is referring to you?

Here’s something the internet can do that can’t happen in real life – being able to read the record of all conversations that made reference to you. Twitter does this with their “Replies” page. Why not off Twitter as well?

How #1 could be implemented

This is a really difficult engineering problem, and I won’t pretend like I’ve got all the answers. So I’ll do my best. There are a number of existing web sites that vend OpenID accounts, including Yahoo, Blogger, and LiveJournal. Here’s the list. All of these services support some kind of “Profile” page, where the user can publish information about themselves. So we have a decentralized way of naming people (OpenID) and we have a way to lookup information about that person (hosted profile). So what’s missing is browser support for interpreting the @reply markup.

What’s that you say? No one is going to use awkward OpenID URLs to name people? You’re right. So, browsers will also need hooks into your Address Book, so that they know which “John” you are referring to. This could have the same auto-complete UI that email clients already support – as soon as you start typing @John, a small drop down appears next to your cursor showing the various people you know who match “John”. You pick the right one, and the markup is entered for you, linking to John’s profile.

How #2 could be implemented

The last bit of this is discovering all the places people are referring to you. This is tricky, and the two ideas I have have weaknesses. One idea uses another open technology called XMPP, the Jabber protocol. Here’s how it could work. When your browser publishes “@John”, it will use XMPP to send a message to John’s OpenID server notifying John of the reference to his name. When John logs into his OpenID-supporting service of choice, he can be shown all of the messages that have been pushed to him.

The other idea is for the OpenID server to support an HTTP POST whose payload would be the URL where the reference was made. The OpenID server would log all traffic to that special URL and pass it on to John once he logs in.

Thoughts?

Anyone have thoughts on this? Obviously to big (some might call it “unlikely”) changes need to happen. First, browsers need to add support for OpenID based @name markup. Second, browsers need to know how to send XMPP messages (or, invoke a hidden URL hosted by the OpenID server, which might be easier.) Lastly, OpenID servers need to process these incoming messages and present them to the user in some helpful way.

Naturally, I imagine there are a host of security concerns to work through, especially with browsers pushing URLs around. Still, I think this would create a very interesting social ecosystem. What do you think?