The Gong Show

Computer Science Resource Management Opportunity

When I wrote code in college, I started in C. And in C, a regular concern is memory management: malloc() and free(). The core problem is making sure my program can fit into available memory, and then there are a bunch of ancillary bugs that emerge because of manual memory management.

Later in school, higher order languages grew in popularity and these memory management issues became substantially reduced (though not non-existent). malloc() and free() were out of sight, but some of the core issues of fitting a program into a single box still exist.

When I hear problems modern data-obsessed startups face, my rookie Computer Science experience serves as a nice analogy to a real business opportunity today.  These companies are still worried about resource management, but now instead of stressing over fitting a program into the RAM on a single box, they stress about fitting an app into a cost-reasonable number of EC2 instances and low enough i/o to make S3 affordable. It’s still the resource management game, but it’s now at cloud scale. 

Building your app in such a way that its resource footprint automatically scales itself up or down to your current needs in an affordable way is a solvable problem (just like memory management on a single box program was quite solvable), but it requires a bunch of extra code and cognitive overhead for the developer.

We are in the “C” days of building software across multiple boxes in the cloud. We are making “malloc()” and “free()”-esque decisions every time we need to manually choose to spin up/down a new instance (or not).

It’s time for higher order cloud languages.  Like garbage collected languages on a single box, a higher order cloud language (or more likely, a platform) would scale cleanly to your app’s demands, and make smart decisions so that you don’t wake up to a $100K bill next week.  

Heroku started to scratch this opportunity by making scaling a web app as simple as dragging slider bars in a very well designed interface.  But it’s still all manual and still requires cognitive overhead on behalf of the developer (err… devops?). That doesn’t sound like it goes far enough to me. From what I can tell, Google App Engine is a good cut at this vision, but I think requiring developers to use their own proprietary BigTable-esque data model was a misstep. Developers want to use whatever data model and data storage tools they want, and scaling underneath those choices should happen automatically.

I’m sure there’s a field of startups already chasing this opportunity, and I don’t I’m the right investor for them because I’m clueless in infrastructure and in enterprise sales. But I know when cross-computer programming is cleanly abstracted to the point that it feels the same as garbage collected memory, there will be a wave of new developers and companies taking advantage of this fundamentally simple approach to cloud computing. This will be big.

Will You Be Missed?

When I opened my email this morning, my inbox was littered newsletters and deals. Not Spam, but “Bacn.” At first I was confused why it was such an unusual mess, and then I realized that SaneBox must be down, the tool I use to filter signal from noise in my inbox. I immediately missed SaneBox, but I also knew that with patience it would be back online shortly and would catch up on the mess that accumulated in its absence.

The fact that I missed SaneBox is a great positive signal for its product quality.

If I were filling out a customer feedback survey for SaneBox, they might ask me a question along the lines of “If SaneBox were no longer available, how much would you miss it? (Scale 1 - 5).” And I could try to answer them truthfully. But the silver lining of downtime for any startup is establishing Ground Truth on this typical feedback question, instead of just relying on self-reported survey data.

No one wants their service to go down, ever. It’s incredibly stressful. But once you’re back online, a quick scan of your customer support email or Twitter mentions will give you a good gut check on just how much you’re missed.

Public Metrics

When stalking website growth as an outsider, I’ve used some combination of Alexa, Compete and Quantcast over the past seven years.  As the FB app ecosystem emerged, I added AppData to the mix.  Now that mobile has become a primary distribution channel for many companies, I now rely on AppAnnie regularly for competitive intelligence. When looking at open source technology companies, I track GitHub Stars, Forks, and PRs.

What tools am I missing?  Anyone else have best practices they’d like to share for public metrics tracking?

Product vs Marketing Dollars Trade-offs

According to a quick scan of financial history in Google, Tesla has raised roughly $1.8BN in a combination of equity and debt over the past 4 years. The vast majority has gone to R&D, Manufacturing, Capex, etc… 

In that same time frame Ford has spent roughly $16BN on just Ads and Marketing alone.

That’s an order of magnitude larger. And I think Tesla is in a much more interesting strategic position for the next ten years than Ford is.

Sometimes, as a big company, it’s just easier to tell people you have a better product (over and over again… with a Tom Brady cameo) than it is to actually build a better product.  But this is always a short term solution.

It’s a classic trade-off that even the earliest startups face.  Every dollar you invest in marketing is a dollar you didn’t use to build a better mousetrap.  

I’m not saying, “Don’t market your product.”  Instead, I’m stressing the importance of capital efficiency in marketing. Paying for users is a drug that is very hard to ween yourself off of later.

The Mental Model of Verbs in App Design

When I talk to people that use web apps infrequently, they are often surprised by the way the “like” verb works inside Facebook.  People don’t say they are surprised explicitly… but its clear there is confusion when you tease it out via conversation.

Like in Facebook: it is intuitive that “Like” should be a statement of appreciation because that’s how we all use the verb “Like” in every day language. Here is how most people first encounter the “like” link for the first time in Facebook:

[Some Facebook News Feed post goes here]

“Like - Comment - Share“ 

That simple three-link “bar” is affixed below all updates in the Facebook news feed is where most people first encounter “Like”.  They fact that these three links are juxtaposed implies that they do materially different thinks from each other.  Intuitively, if I want to share this post with my friends, I would click “Share”, and if I only want to show appreciation, I’d click “Like”.

But, a quick scan of your news feed (assuming you have enough active Facebook friends), shows you page after page of things people have “liked”.  So if you tie this “liked” verb back to the “Like” action previously seen, then you start to unpack just what “Like”ing something does.  It sends the content to your friends’ news feeds.

So, “Like” starts to take on a new meaning.  It means now, I appreciate this, but I also want to send it to all my friends too.  If you’ve arrived at this mental model, you now understand how the “Like” verb works in the news feed.  But wait… there’s another “Like” elsewhere: 

Go to any fan page. How about this one from Dove. The call to action on the page is to “Like” it.  So, using our newly acquired mental model of “Like,” this means I will be both showing appreciation and sending it to my friends. But, this “Like” on a fan page is now going to do a third thing: it’s going to sign me up for a subscription to all of Dove’s updates in my news feed.  Again, not intuitive… until you do it once and hopefully when you see Dove updates in your news feed, you then mentally tie it back to the action of liking the page.  

So now we have three meanings: A) sign of appreciation B) send this to my friends and C) subscribe me to future updates (but only if I’m on a fan page).  

In Other Apps: The various meanings of “Like” are made less intuitive in the social web in general because they vary between different social apps. In Twitter, the “heart” was ambiguous for years because some users used “heart” to bookmark items for themselves later. It used to be that when you “heart”ed a Twitter update that contained a link, you could get other Read Later apps to suck it up. But then Twitter flipped a switch so you could see when other users hit “heart” on your tweets, and suddenly “heart” became the “signal of appreciation” it always should have been.  

Perhaps the best (worst?) verb choice of all was Last.fm, who was doing quite new, innovative stuff in the primordial days of the social web. They invented a verb to cover their key behavior: scrobble. As far as I’m aware, that one never made it into the OED.

Other Verbs in Facebook: For a brief period in Facebook about a year ago, other verbs were even trickier.  ”Watch”ing a video or “Read”ing an article would syndicate it to all your friends’ news feeds… and they would not involving clicking a link.  It was all implicit sharing.  This is how Viddy and Socialcam blew up a year ago… and then came back down to earth when Facebook realized that implicit sharing from app-defined verbs like “Watch” or “Read” was causing users to inadvertently share things they didn’t want to share… which is a bad user experience.

The moral is this. If you’re building a web app, choose your verbs carefully.  They bring prior meaning… both from how they work on other apps and how they are used in common language.  To Facebook, the fact that the word “Like” implies “appreciation” but doesn’t imply “share this with my friends” is probably a feature not a bug… because it leads to more sharing, intentional or otherwise.  But be careful about walking this slightly spammy line in your own app.  Facebook gets to do things other apps can’t because of their sheer scale and network effect.

Hard Tech Challenges Are Great, But Not Necessary

I met a set of founders recently that were solving a real problem for a known market. So far so good.

The solution the team implemented was technically trivial. It was a simple CRUD app that, if built on top of a web framework like Rails or Django, could probably be implemented in 7-10 days by a developer and designer paired up. And it probably was.

The solution was effective. Initial user testing showed that the solution addressed the problem well, and the customers were providing enthusiastic feedback.

I think the Andrew from 6 or 7 years ago would get really hung up on the trivial technical challenge. “This is so simple… Won’t 5 clone competitors popup overnight?” I might have said.

This is a classic pitfall that engineers often stumble into, myself included. But the triviality is irrelevant to product-market-fit, and that fit is paramount early on in a startup.

I love it when engineers push the boundaries of what’s possible with technology. Elegant hacks to difficult engineering challenges are inherently sexy. But, they are neither necessary nor sufficient to build a big company.

Innovators Patent Agreement

I love the Innovators Patent Agreement (IPA). I think it perfectly captures the spirit of how intellectual property should work in today’s era. Rather than butcher the description with my own short hand, here’s a concise description right from the GitHub page where the IPA is hosted:

The Innovators Patent Agreement (IPA) is a new way to do patent assignment that keeps control in the hands of engineers and designers. It is a commitment from a company to its employees that patents can only be used for defensive purposes. The company will not use the patents in offensive litigation without the permission of the inventors. This control flows with the patents, so if the company sells the patents to others, the assignee can only use the patents as the inventor intended.

I’m delighted that four Spark Capital portfolio companies have already embraced the IPA: Lift, Jelly, Stack Exchange, and Twitter. If I were an engineer considering multiple job offers, I know the IPA would factor in my decision-making. I’ve seen countless inventors embarrassed by how their patents have been used offensively without their permission, absurdly long after their date of invention and leaving their company.  

While I hope more Spark portfolio companies will follow, that’s up to the companies to make that decision, and, along the same lines, please don’t confuse the musing on my own blog with Spark’s official stance.  I sweep the floors there.

I feel strongly that offensive usage of patents is net-innovation-destructive. It’s not a position i’ve come to lightly; I’ve arrived over 5-7 years of consideration and internal debate.