making time
archives
Music discovery should be push, not pull

Music discovery is a revenue driver for content owners before it is a convenience to consumers. So why are music discovery services more like destinations than features? Look at Last.fm, Pandora, Imeem, TheSixtyOne — they all require users to break out of the normal habit of listening on iTunes/WMP and proactively visit a separate site. If helping people discover music increases consumption, and presumably revenues, why is discovery not being pushed to users’ primary usage channels?

Music discovery should be persistent companion to music consumption

Relevant recommendations could exist alongside as users browse their own libraries and at best, users should spend as much time enjoy their own content as they do engaging in discovery. And I mean more than that shitty footer-bar inside iTunes that merely links to the storefront. What about interactive widgets that connect users to multiple forms of discovery (crowd favorites, characteristically similar, social heatmap, digital mixtapes) as well as artist info and even a little event discovery?

What’s the single best way to promote music? Let people be constantly connected with what their friends listen to—it’s like free advertising, but people will perceive it as a feature.

The problem with the channel strategy today is that each channel only cares about a small-piece of the distribution landscape. Apple wants you to buy music, not spend all day browsing around last.fm or muxtape. Last.fm wants you to spend less time building your personal library, and more time listening to their radio. We need to have some kind of one-stop-shop that isn’t loaded with conflicting interests across its own sales/discovery channels.

Should it have been Facebook mail instead?

Facebook chat is sexy and well implemented—we didn’t expect any less from them. Adding more communication features is a great way to increase the “stickiness” of the Facebook experience and drive up engagement (and therefor page views). But being a late entrant into IM with an ulterior motive makes f-Chat a tough sell as anyone’s primary IM protocol.

I don’t chat with most of my Facebook friends, and for the ones whom I do, I prefer to do on a sleeker desktop/blackberry client.

Obviously opening the protocol defeats the “stickiness” strategy, but leaving it closed will make it second rate, no more than an afterthought.

Shouldn’t they have made a serious email offering instead?

Let people opt into an external @fbook.com and slowly enhance the messaging features into full-blown email? A full-blown email service tightly integrated with social networking can easily occupy a big chunk of my personal web traffic.  That’s the kind of walled garden that people can get trapped in and still like it.

From selling IP to selling a service

This article on GigaOM got me thinking about how little we hear about software piracy these days. SaaS essentially expires all issues of piracy: vendors are no longer selling pieces of IP on a shiny disc, but sell the proper execution of their software. On top of that, users don’t even have physical possession of the IP. I’d venture to guess that software piracy looses all relevance within 5 years.

Now the real trick is, could this pattern be replicated in the media industry? Can legit-IP be sold with such superior value-added-services that the experience of consuming the raw IP itself pales in comparison to the full suite?

Growing from feature to business

M&A seems to be the only way out for startups these days. Most would point to a stale stock market and Sarbanes-Oxley as the reason for the rise in M&A exits vs. IPOs. Yet, I get the sense that it’s because many web startups simply have little hope of ever generating sustainable cash flows. I see a dependence on M&A, not a shift in preference. It’s gotten to the point where integration synergies is the entire value justification for a startup, meaning that the M&A not is just a liquidation pathway, but the sole sustainability pathway.

People are building features, not businesses.

Features get bought and die a slow death buried in misaligned stock options and brain drain. Businesses bloom into the Facebook’s and Google’s. Granted, every startup began more or less as a one-trick pony, so it must be that fewer startups are able to make the critical step growing from being just a feature to a real business.

I could write more, but gosh, someone more qualified has already address it.

Standardizing more than just the webpage

Every page has a <html> <head> and <body>. We all expect <H#> to indicate headings, that <b> or <strong> means bold but no one should be using <bold>, that Javascript should live inside a <script>. This is what standardized HTML is all about and allows every computer on every OS, every browser to experience the same web page (albeit, not always the same way).

We’ve standardized how a page should be built, it’s time to extend that level of standardization to other elements on the Web.

Pages are the atom, but we need elements, and a periodic table

The web used to be a bunch of pages. A page is a chunk of free-form content from which you could expect anything. But now, a lot of pages are starting to look awfully similar. We’ve advanced beyond pages—when we browse content, we tell our selves “This is a profile, this is a blog entry, this is a video, this is a playlist.” Our awareness of content type ties to a set of expectations about what properties and structure to expect. A profile should have a picture, a name, lists a couple interests. A blog posts a date and a body, title and comment-list optional. In our heads, we’ve evolved a set of schemas for each content-type we frequently use. However, web applications still serves content largely in schema-less HTML…which one would find odd considering that the data-backend is quite rigidly structured:

Backend Data

Relational database
Rigidly structured

Content output

HTML
Completely unstructured

User conception

Content elements
Moderately structured

We already conceptualize web content as different element types, not just a dumb network inter-linked pages, now we need to make the underlying technology reflect this concept.

We’re in the dark ages of data portability

Have you seen FriendFeed? It’s quite amazing, but it only handles content from a handful of sources. Want more? The developers will need to adapt new sources manually, because there are no standard data formats for most of the items that FriendFeed is trying to aggregate.

Imagine if regular web pages were in an analogous situation. It would mean that:

  1. Different web servers use different markup languages
  2. Different content providers require access via their own browser
  3. And if I extended this analogy to mobile internet:

  4. Different content requires different browser, OS, and even hardware in order to access it

That’s the depressing state of data formats today: portability extends beyond a user rights or EULA issue because we haven’t even matured the technical capability to execute.

Surely you must be talking about microformats

Microformats are super-cool. While they’re often mentioned in tandem with the semantic web, I think the first-line impact is in data portability. But I wonder if there’s a way to crank these out faster than depending on a single standards organization. There’s been niche success in describing people and events (hCard, hCalendar) but damn…shits gotta get cranking.

Hey there, my name is Q.

I’m an econ & CS grad joining a social games startup in SF.   Before this, I did a stint in management consulting, working mostly with telcos and PE/hedge funds.