Stay Hungry

Recommendation Fail

There’s been a lot of noise about recommendations and relevance as of late.  Recommendation-fail happens in two major ways.  Your “Filter Bubble” - pioneered and explained well by Eli Pariser (founder moveon.org) in his TED talk - is algorithmically created by the services you use, tailoring what you see and preventing you from even knowing what you’re missing.  But your Filter Bubble only let’s through what it naively deems “relevant” without promoting different, challenging or uncomfortable ideas.

The second big recommendation-fail is social recommendations.  This is the kind of failure that keeps happening again and again, as they intuitively make sense.  But there is a fundamental issue with many social recommendations: we’re not necessarily all that similar to our social network-friends.  There’s a good, deeper discussion on quora but suffice it to say, your taste graph probably doesn’t look much like your social graph.

Illustrations of each come to mind in the music sphere: Pandora and Turntable.fm.  Pandora, which just IPO’d to a chorus of scrutiny, sets out explicitly to create a Filter Bubble.  It does a great job, but sometimes it’s too good and I have to put it significant effort to change it up.  Turntable.fm, on the other hand, leans towards social recommendations.  Sure, I can hang out in a random room, but it’s more fun with my friends, and their musical taste is very much unlike mine.  The DJ’ing aspect helps a bit when people try to keep a good trend/theme going.

Better Recommendations

Mixing the two approaches (algorithmic relevance & social recommendation) can provide a huge improvement, but it’s incomplete.  How do you provide significant variety of content and serendipitous recommendations with these givens?  Add a Noise Dial.  Don’t take away social recommendations, they’re useful (I can’t think of many TV shows I currently watch that weren’t first recommended by a friend).  And don’t make the algorithms too “smart” (aka sterile).  

Give your user a Noise Dial (balancing transparency with added complexity), whereby they can expand the horizon of algorithmic recommendations, and the tools to maintain that expanded horizon (i.e. one-way follow, like Twitter).  Their expanded social graph then serves as the base for the next iteration of recommendations.  This produces an exploratory feedback loop where the user naturally acts as their own damper, accomplishing our goals without the recommendations becoming annoying and/or irrelevant.

—

p.s. We’re building a Noise Dial into the core of Shelby.tv’s collaborative filter.  And our noise dial goes to 11.

@nevspins and I are heading down to VA for her cousins graduation today.  So I woke up at 5am to get in a run and get some shit done before hitting the road for 7 hours.  Getting out of the shower after my run I heard Nev playing Angry Birds in the other room.  This got me thinking how much I miss the sounds of *actual* birds chirping.

Then I discovered that she was still asleep.  I was hearing real birds chirping.  That’s when it me even harder that I need to get more nature into my life.  As a kid I loved vacationing with my family in Lake George, NY.  We went up almost every summer, and many winters.  My parents also took us up to East Branch, NY where my Uncle owns some land in the middle of mountains, valleys and rivers (i.e. nowhere).  Mountain climbing, swimming in ice cold rivers, frisbee, lawn darts, wiffle ball, bicycle riding; you name it, we did it.

I can’t thank my parents enough for giving me those opportunities as I grew up.  I love NYC; it’s the capital of the world and a beautiful testament to the abilities of man.  But I don’t think I’m meant to live in these conditions, at least not forever.

Products are tangible, testable, fun to build and fun to break.  This is what drew me, and I’m sure many others, to the world of computer engineering (I find “computer engineers” to be a good more-encompassing term for all those who build executable digital products).  So we naturally build products for others and build companies around those products to keep them alive and growing.  Can a company based on a product survive in the long run?  Does that even matter?

My ideas on this subject are still baking, but a leader in 11 June’s The Economist on IBM’s centenary, The Test of Time (page 20 in the paper edition, that’s how I roll) considers the longevity of a handful of companies and really got me thinking about my own company.  The Economist argues that IBM has survived by packaging technology for business, that Apple will thrive based on the idea of elegantly and simply packing the latest technology to sell at a premium price, that Amazon will live by making it easy for people to buy stuff, and that Facebook will survive making it easy for people to share stuff.  They argue that product-based firms won’t survive; Dell only makes PC’s, Cisco is just routers, and Microsoft relies on Windows software for PC’s.

As interesting as some of the arguments would be, I’m not interested in diving into the specifics of the above companies.  I’m more interested in your company, and my company.  I’m building a startup right now.  By definition, that means we’re still trying to discover what exactly we should be building!  We are focused on the product, the product-market fit, the business model, the culture and the brand of the company.  While it is possible to define the bigger idea powering our company, doing so is only productive insofar as that process makes us think deeply and strategically about our business.  The animating idea of our company is sure to change as our understanding of the business evolves.

Can a company based on a product survive in the long run?  Yes, but probably not by staying focused on that product.  Indeed, you can make very strong arguments that Apple (formerly Apple Computer), IBM (acronym for International Business Machines) and Facebook (fucking Facebook) all evolved successfully and drastically away from their original product-heavy days into successful idea-based companies.  And I highly doubt they could have predicted their evolutionary path on day 1.  But on the flip side, not every company has to live forever!  Companies *should* die.  Sometimes it’s better to burn out than to fade away.  My takeaway: don’t worry about it (thinking about it is okay).

Does that even matter?  Does the survival (or lack thereof) of product-based companies matter to you, the builder of a company?   No, not necessarily.  The world wants products.  I personally want a motorcycle, quadro-copter with video camera, and a new MacBook Pro (in that order).  And I don’t generally care if the company that makes them gets subsumed by a bigger company, lives to be 100, or dies in 10 years (so long as it doesn’t affect my enjoyment of the product).

Keep building great things, things that people want, and things that challenge the status quo.  I would like to invest in those companies.

Tech Crunch Disrupt was another success this year.  Sadly, I didn’t get to go.  Myles, Henry and myself entered the TCDisrupt Hackathon last weekend, hoping to crank out something brand new, present it, and get some free tickets.  That didn’t happen.  There are a few good reasons why we didn’t present.  That was my first hackathon, and these are my learnings…

Don’t Learn New Technologies

We built our project on Rails 3.1 beta 1.  There are some great new features (better asset management via sprockets, SASS, CoffeeScript) I was excited about.  We already use SASS, and decided to skip CoffeeScript, but it still took almost an hour to work through the bugs with sprockets and get Rails 3.1 working on all of our machines for the first time.  While it was a good learning experience, it would have been much more efficient to stick with Rails 3.0.5 that we all already had running on our machines, VMs and servers.

APIs love hackers love APIs

It’s no coincidence API vendors dominate hackathons: leveraging API’s is an incredibly powerful way to build on an already existing user base and deliver impressive results in little time.  If you’ve already hacked with a given API that’s another huge plus.  But even if you haven’t, the good ones have great docs.  Use APIs, you’ll be standing on the shoulders of giants!  We didn’t use any API’s.  While this didn’t hinder us, it also didn’t help.

Get Started Early

Hackers are generally moral and fair creatures.  So, if it’s a 24 hour hack from start to demo, we probably won’t start coding _on this hack_ beforehand.  But if you have some libraries or code you’ve written for other purposes that can be incorporated, there’s nothing wrong with that.  It’s also a good idea to really think through your hack - the architecture, the problems that may arrise, the difficult bits, how to split up work, what to names things* - and plan it all out.  Although no plan survives contact with the enemy, there is great value in the act of planning.  Do it, and start it early.  We rushed this phase of the hack, and combined with overconfidence (a requirement of both hackers and entrepreneurs), that really came back to bite us.

Physically Stay There

Even though you’ll be mentally checked out at times, plan on “sleeping” there.  Don’t be a bitch.  <Arnold>Stop whining.</Arnold>  And don’t leave after 5 hours on day one to drive an hour away, go out and drink, drive back, sleep, and return on the final day for 3 more hours (a slight mistake made by yours truly).  This also relates to my next lesson learned…

Understand The Working Hours

As hacker-friendly as the NYC startup community has become, there’s nothing like setting your inner nerd loose without any concern of judgement when you’re in a hanger filled with a few hundred other hackers (most of whom stank worse than you, or so it seems).  Be prepared to talk shop.  Then there’s also all the “hello”s, the pretending to remember you “what’s up buddy”s, the “of course we’ll use your API if you give us free junk”, tweeting at folks who are across the room from you, checking in, hashable’ing, instagramming, and color’ing (haha, nope!).  Bottom line is, you don’t have as much time to code as you think.  Especially not during the first couple of hours.

Have a Strong Team

We actually got this part right.  The three of us work really well together and communicate smoothly.  It may have been cool to join up with more folks, but they’d have to fit into the puzzle correctly.  Flying into a hackathon solo is difficult, and less likely to result in something with legs.

For us, although we didn’t get our hack to a demo-able point, we definitely consider the weekend a success.  We learned about some great new libraries and frameworks, and thought through some fairly difficult technical challenges.  It was also a fun time hanging around with other hackers coding their asses off and just being a part of the community.  We’re certainly stronger after that workout.

* There are only three difficult problems in computer science: 1) Naming stuff.  2) Off-by-one errors.