Software companies love hiring people that like solving hard technical problems. On the surface this seems like a good idea, unfortunately it can lead to situations where you have people building a product where they focus more on the interesting technical challenges they can solve as opposed to whether their product is actually solving problems for their customers.

I started being reminded of this after reading an answer to a question on Quora about the difference between working at Google versus Facebook where Edmond Lau David Braginsky wrote

Culture:
Google is like grad-school. People value working on hard problems, and doing them right. Things are pretty polished, the code is usually solid, and the systems are designed for scale from the very beginning. There are many experts around and review processes set up for systems designs.

Facebook is more like undergrad. Something needs to be done, and people do it. Most of the time they don't read the literature on the subject, or consult experts about the "right way" to do it, they just sit down, write the code, and make things work. Sometimes the way they do it is naive, and a lot of time it may cause bugs or break as it goes into production. And when that happens, they fix their problems, replace bottlenecks with scalable components, and (in most cases) move on to the next thing.

Google tends to value technology. Things are often done because they are technically hard or impressive. On most projects, the engineers make the calls.

Facebook values products and user experience, and designers tend to have a much larger impact. Zuck spends a lot of time looking at product mocks, and is involved pretty deeply with the site's look and feel.

It should be noted that Google deserves credit for succeeding where other large software have mostly failed in putting a bunch of throwing a bunch of Ph.Ds at a problem at actually having them create products that impacts hundreds of millions people as opposed to research papers that impress hundreds of their colleagues. That said, it is easy to see the impact of complexophiles (props to Addy Santo) in recent products like Google Wave.

If you go back and read the Google Wave announcement blog post it is interesting to note the focus on combining features from disparate use cases and the diversity of all of the technical challenges involved at once including

• “Google Wave is just as well suited for quick messages as for persistent content — it allows for both collaboration and communication”
• “It's an HTML 5 app, built on Google Web Toolkit. It includes a rich text editor and other functions like desktop drag-and-drop”
• “The Google Wave protocol is the underlying format for storing and the means of sharing waves, and includes the ‘live’ concurrency control, which allows edits to be reflected instantly across users and services”
• “The protocol is designed for open federation, such that anyone's Wave services can interoperate with each other and with the Google Wave service”
• “Google Wave can also be considered a platform with a rich set of open APIs that allow developers to embed waves in other web services”

The product announcement read more like a technology showcase than an announcement for a product that is actually meant to help people communicate, collaborate or make their lives better in any way. This is an example of a product where smart people spent a lot of time working on hard problems but at the end of the day they didn't see the adoption they would have liked because they they spent more time focusing on technical challenges than ensuring they were building the right product.

It is interesting to think about all the internal discussions and time spent implementing features like character-by-character typing without anyone bothering to ask whether that feature actually makes sense for a product that is billed as a replacement to email. I often write emails where I write a snarky comment then edit it out when I reconsider the wisdom of sending that out to a broad audience. It’s not a feature that anyone wants for people to actually see that authoring process.

Some of you may remember that there was a time when I was literally the face of XML at Microsoft (i.e. going to http://www.microsoft.com/xml took you to a page with my face on it ). In those days I spent a lot of time using phrases like the XML<-> objects impedance mismatch to describe the fact that the dominate type system for the dominant protocol for web services at the time (aka SOAP) actually had lots of constructs that you don’t map well to a traditional object oriented programming language like C# or Java. This was caused by the fact that XML had grown to serve conflicting masters. There were people who used it as a basis for document formats such as DocBook and XHTML. Then there were the people who saw it as a replacement to for the binary protocols used in interoperable remote procedure call technologies such as CORBA and Java RMI. The W3C decided to solve this problem by getting a bunch of really smart people in a room and asking them to create some amalgam type system that would solve both sets of completely different requirements. The output of this activity was XML Schema which became the type system for SOAP, WSDL and the WS-* family of technologies. This meant that people who simply wanted a way to define how to serialize a C# object in a way that it could be consumed by a Java method call ended up with a type system that was also meant to be able to describe the structural rules of the HTML in this blog post.

Thousands of man years of effort was spent across companies like Sun Microsystems, Oracle, Microsoft, IBM and BEA to develop toolkits on top of a protocol stack that had this fundamental technical challenge baked into it. Of course, everyone had a different way of trying to address this “XML<->object impedance mismatch which led to interoperability issues in what was meant to be a protocol stack that guaranteed interoperability. Eventually customers started telling their horror stories in actually using these technologies to interoperate such as Nelson Minar’s ETech 2005 Talk - Building a New Web Service at Google and movement around the usage of building web services using Representational State Transfer (REST) was born. In tandem, web developers realized that if your problem is moving programming language objects around, then perhaps a data format that was designed for that is the preferred choice. Today, it is hard to find any recently broadly deployed web service that doesn’t utilize on Javascript Object Notation (JSON) as opposed to SOAP.

The moral of both of these stories is that a lot of the time in software it is easy to get lost in the weeds solving hard technical problems that are due to complexity we’ve imposed on ourselves due to some well meaning design decision instead of actually solving customer problems. The trick is being able to detect when you’re in that situation and seeing if altering some of your base assumptions doesn’t lead to a lot of simplification of your problem space then frees you up to actually spend time solving real customer problems and delighting your users. More people need to ask themselves questions like do I really need to use the same type system and data format for business documents AND serialized objects from programming languages?

Now Playing: Travie McCoy - Billionaire (featuring Bruno Mars)

This morning I stumbled on a great post by Dave Winer titled Why didn't Google Wave boot up? where he writes

So why didn't Google Wave happen?

Here's the problem -- when I signed on to Wave, I didn't see anything interesting. It was up to me, the user, to figure out how to sell it. But I didn't understand what it was, or what its capabilities were, and I was busy, always. Even so I would have put the time in if it looked interesting, but it didn't. 

However, it had another problem. Even if there were incentives to put time into it, and even if I understood how it worked or even what it did, it still wouldn't have booted up because of the invite-only thing. It's the same problem every Twitter-would-be or Facebook-like thing has. My friends aren't here, so who do I communicate with? But with Wave it was even worse because even if I loved Wave and wanted everyone to use it, it was invite-only. So the best evangelist would still have to plead with Google to add all of his workgroup members to the invite list. The larger your workgroup the more begging you have to do. This is exactly the opposite of how you want it to work if you're in Google's shoes. 

This is an important lesson on the value of network effects on social software applications. A service that exhibits network effects is more useful the more of my friends use it (e.g. having SMS on my cell phone is only useful if I have friends who can send & receive text messages). By definition, a social software application is dependent on network effects and needs to do everything in its power to promote them. Placing artificial barriers that prevent me from actually using the product as a communication tool with my social network works against the entire premise of being social in the first place.

Google definitely learned the wrong lesson from the success of Gmail as an invite only service. Being invite-only worked for Gmail at launch because my friends don’t have to use Gmail to receive or send messages to me. So word off mouth could spread because the people who used it would sing it’s praises which caused anticipation amongst those that couldn’t. On the other hand with Wave, the people who got invites couldn’t get to the point where they could sing its praises (if there were any to be sung) because it was too difficult to get their friends on there. By the time they made the service open to all, it was too late due to what Joel Spolsky called The Segway Phenomenon

PR grows faster than the quality of your code. Result: everybody checks out your code, and it's not good yet. These people will be permanently convinced that your code is simple and inadequate, even if you improve it drastically later. I call this the Marimba phenomenon . Or, you get PR before there's a product people can buy, then when the product really comes out the news outlets don't want to do the story again. We'll call this the Segway phenomenon.

Some may point to Facebook as an example of a network that was invite-only but still managed to have network effects but there is a crucial difference in how Facebook regulated growth before opening up to all. Facebook opened its doors to entire networks of people at a time (i.e. everyone in a particular college, all college students, people from select employers, etc) not to arbitrary swaths of people on a first come, first served basis.

Hopefully more startups will keep this in mind before jumping on the invite-only bandwagon.

Now Playing: Eminem - Hell Breaks Loose (featuring Dr. Dre)

I've spent the past week going over the ideas in Chris Dixon's excellent post titled graphs and thought the ideas were powerful enough that they are worth reiterating. The thesis is simple, in recent years many have been focused on social graphs (i.e. graphs bidirectional or one-way “friend” relationships between users) but there are other ways in which users can be connected to each other besides whether they are friends or not. The key points from Chris’s post are excerpted below

Facebook’s social graph is symmetric (if I am friends with you then you are friends with me) but not transitive (I can be friends with you without being friends with your friend).  You could say friendship is probabilistically transitive in the sense that I am more likely to like someone who is a friend’s friend then I am a user chosen at random. This is basis of Facebook’s friend recommendations.

Twitter’s graph is probably best thought of as an interest graph. One of Twitter’s central innovations was to discard symmetry: you can follow someone without them following you. This allowed Twitter to evolve into an extremely useful publishing platform, replacing RSS for many people. The Twitter graph isn’t transitive but one of its most powerful uses is retweeting, which gives the Twitter graph what might be called curated transitivity.
...
Over the next few years we’ll see the rising importance of other types of graphs. Some examples:

Taste: At Hunch we’ve created what we call the taste graph. We created this implicitly from questions answered by users and other data sources. Our thesis is that for many activities – for example deciding what movie to see or blouse to buy – it’s more useful to have the neighbors on your graph be people with similar tastes versus people who are your friends.

Financial Trust: Social payment startups like Square and Venmo are creating financial graphs – the nodes are people and institutions and the relations are financial trust. These graphs are useful for preventing fraud, streamlining transactions, and lowering the barrier to accepting non-cash payments.

Endorsement: An endorsement graph is one in which people endorse institutions, products, services or other people for a particular skill or activity. LinkedIn created a successful professional graph and a less successful endorsement graph.

Local: Location-based startups like Foursquare let users create social graphs (which might evolve into better social graphs than what Facebook has since users seem to be more selective friending people in local apps). But probably more interesting are the people and venue graphs created by the check-in patterns. These local graphs could be useful for, among other things, recommendations, coupons, and advertising.

One of the things that has been interesting to watch is how many services have tried to build this other sorts of relationship graphs on top of Facebook Connect. Quora has tried to build an endorsement graph from Facebook Connect as a basis while Yelp has tried to build a location graph using Facebook's Instant Personalization and Facebook Connect as the foundation. As more of these sorts of relationships graphs between people and other entities are created it is slowly becoming clear to me that there are many scenarios where Facebook’s graph is not the best starting point.

Take this screenshot of the Facebook Friend’s Activity plugin on Engadget as an example.

What this plugin does is show which of my Facebook friends (i.e. mostly family, coworkers and high school friends) have found interesting on Engadget. I couldn’t help but think back to what Chris Dixon mentioned about Twitter being an “interest graph”. I realized that this feature would actually be more useful if it showed me what Engadget articles people I follow on Twitter found interesting rather than what my Facebook friends did.

As the utility of the social graph grows beyond providing a stream of updates from people in that graph to being reused in other contexts, the lack of universal appeal in some of these relationships will grow more obvious. Using Twitter as an example, I suspect if asked to chose between a widget on TechCrunch that shows what articles are interesting among your Facebook friends versus who you follow on Twitter a non-trivial amount of people would pick the latter.

Similarly I wonder how soon till we start seeing some of the endorsement graphs being built on services like LinkedIn and Quora being leveraged in other places where you need to vet the opinions of strangers such as Amazon or even Monster.com.

There are times I’ve debated with others whether there will be one social graph to rule them all and whether that graph will Facebook’s. Now I ‘m convinced that although their graph is likely to be the largest and most generally applicable in the long term, there is a market for social graphs based on relationship types other than whether someone is a “friend” or not which can still significantly improve the user experience on the Web.

Now Playing: Eminem - Untitled