The Attention Gatekeepers

I’m seeing interesting cases where Facebook, Google or other gorillas tweak content presentation, and then some other company’s business is directly impacted.  The gorillas have increasing control (and power) over user attention.

For example, Demand Media took a huge hit after Google’s search engine updates lowered rankings for low-quality content.  (DMD is down 80%).

Zynga enjoyed spectacular early success with some of the first social games on Facebook.  But as game updates clogged feeds, Facebook made presentation changes to improve feed quality, and Zynga suffered.  (ZNGA is down 60%).  Facebook continues to tweak how feed content is selected and presented.

More recently, Google added a “Promotions” tab to Gmail, moving most marketing emails out of the main inbox view.  That directly affected Groupon, who’s trying to rely less on the daily coupon.  (GRPN down 20% so far).

And now, Gmail added a prominent “unsubscribe link” to the top of promotional emails, which will impact email marketing performance even more.  (Unsubscribe is one of many “quick action” buttons that Gmail has been rolling out.)

It’s a never-ending battle between those who want user attention, and those who manage it.

Boy, Was I Wrong About Dropbox

A few years ago, I was bearish on Dropbox.  I thought they would be an OS feature in time and that turning down a (rumored) $800m from Apple was a bad move. On Quora, I wrote:

I think “slow fade” is another probable outcome.

I’m reminded of FTP Software, which went like gang-busters selling a TCP/IP stack for Windows. Their revenues fell very quickly after Microsoft started shipping TCP/IP as part of the OS.  (The same thing happened with all of the disk-compression companies).

Wow, was I off base!  I think it’s good to evaluate big entrepreneurial and investment misses and I missed several things (at least).

First, a great product goes a long way.  Dropbox has absolutely nailed the product design and user experience in virtually every aspect.

Second, the service is inherently viral.  I routinely create new Dropbox users by sharing files with them.

Third, they covered every platform equally well.  iCloud works well on OS X, and OneDrive is great on Windows, but Dropbox surfed the whitespace between all of the platforms.  They did an excellent job on everything:  the iPad version isn’t just the iPhone version running 2X and they even support Linux.

I can’t wait to see their IPO.

Email will Be Mostly Mobile

When the Blackberry first came out, it was quickly dubbed the “crackberry” because mobile email access was so addictive.  Now with ubiquitous smart phones, we’re all email addicts to some extent.

So it’s no surprise that now over 40% of email opens are on mobile devices, and mobile is on track overtake the PC this year.  It’s pretty amazing when you consider the smartphone, as we know it, was launched less than 6 years ago.

Mobile and Web are blurring together, slowly ceasing to be distinct “things” (I’ve written before about a mobile strategy for Web sites).  This trend suggests some best practices for emails:

  • Format emails for mobile.  This is basic stuff that a lot of designers seem to mess up.  Make sure emails open and render well on mobile devices.
  • Mobile-optimize email click-through landing pages and flows.  If users are reading emails on mobile devices, they’re also clicking through links on mobile devices.  Check your Web usage stats:  you might find that a significant percentage of your site usage by mobile users is coming from email click through paths.  Nothing kills the user experience like a landing page that hasn’t been mobile formatted.

Gorilla Anti-Trust Posturing

As the big four (Google, Apple, Amazon, and Facebook) continue to wield disproportionate influence over the digital ecosystem, these gorillas are having to worry a lot more about anti-trust issues.  Nobody wants to be broken up like the Bell System.

For example, last month, Liz Gannes wrote about Facebook’s search plans:

…the fact that Facebook has finally made its search intentions known could actually be really good for Google. That’s because regulators — especially those in Europe, who are in the thick of deciding whether to settle with Google over antitrust — now have the prospect of additional search competition to consider.

Also, Google now has Gmail, Maps, and Chrome on the iPhone, where Apple had previously rejected apps that “duplicate the functionality” of built in iOS apps.  But it doesn’t look good (in anti-trust terms) for Apple to reject competitive apps, and Google’s smart to get as many apps as possible to dilute Apple’s platform influence.

I think it’s net-good for consumers, as it increases the chances that more of our devices and systems will interoperate.  But what we really need are some new gorillas.

Why You Can’t Find Any Mobile Developers

In case you haven’t noticed, it’s impossible to find mobile developers. People ask me all the time if I “know anyone”, and I’ve all but given up helping with referrals.

The reason is “self-publishing” is now a reasonable option.  The app store ecosystem has removed most friction from the system, provided a clean and easy business model (70/30 revenue split), and eliminated almost all barriers to entry.  If you have talent, a laptop, and a coffee shop wifi connection, you have a chance at writing the next great app hit.

As a result, many good developers have (or believe they have) a better chance at doing their own thing vs working for someone else for salary or an hourly rate.

Patents and Software Startups

Occasionally, I hear from a software entrepreneur with a “patented” or “patent pending” idea.  Many people view patents in a almost glamorous way:  “Get a patent, and you can control your idea“.  I’ve done a lot of patent work (15 issued, including two of the most cited patents in US history), and it’s never that simple.  Patents are very tricky.

For startups, patents make the most sense in industries with (a) relatively long development times and (b) significant R&D budgets.  The PTO doesn’t move quickly:  for some art units, it can take 2-3 years (or more) to get a patent issued.  That’s fine for a biotech company bringing a new drug to market, but is much too long for a software company launching a product in six months.

Also, patents can be very expensive.  For a $750,000 seed round, it may not make sense to spend ~5% of that (or more) on getting US patents filed.  International?  Budget six figures.

Finally, fundraising entrepreneurs frequently overplay the value of patents, missing the other elements needed to make a successful business and making themselves look naïve.  For example, “provisional patents” don’t exist:  it’s a provisional application that gives an option to file for a utility patent later (and it’s just that, an application).  “Patented” means patent issued and in force, “patent pending” means a patent filed but not issued.

If you don’t have an issued patent, it’s a long and expensive journey:  claims are often rejected entirely or issued very narrowly.  It’s nearly impossible to know what a patent is worth until it issues.

A “Starter” Mobile Strategy

You have to be living under a rock to miss the shift in Web usage from “traditional” devices (desktop and laptop) to mobile devices (phones and tablets).  For example, in India, mobile phones now account for nearly 50% of consumer Internet usage, and mobile usage is growing rapidly world-wide.

As Web site operators watch mobile usage grow, the next thought is usually:  “let’s build a mobile app!”  It’s a good instinct, but I think it’s also a great way to waste a lot of time and money.  Leaping in without any insight on mobile usage is a good way to build the wrong app.  Also, it’s easy to end up with something that only partially replicates Web site functionality, frustrating users and creating two different UIs to maintain in parallel.

For a better strategy, Facebook is a good example to study.  They took way too long to focus on mobile, but their sequencing is a good place to start.  (Note:  this advice is really for existing Web sites).

Following their example, here’s a “starter” mobile plan:

Step #1:  Mobile-enable your Web site.  Remember m.facebook.com?  You can get pretty far these days with just HTML5.  Use your mobile usage data to figure out what areas to prioritize (Google Analytics will break out mobile usage).  Consider both tablet and phone cases:  depending on your application, you may want to deal with them separately.

Step #2:  Develop a native app, with generous use of embedded browser widgets.  Consider which app elements must to be native for the best experience, and do the rest using embedded browser widgets (e.g. WebKit).  Most of your app will actually be HTML5 served from your servers, and you can change content on the fly without having to do an approval cycle with Apple (which can take weeks).

You should be able to leverage the HTML5 work you did in step 1.  Use your existing mobile usage data to prioritize Android vs iPhone and phone vs tablet.

Step #3:  Go 100% native.  (If needed)  At this point, you should have a good sense of the most important use cases, platforms, and form factors.

Edit to taste!

It’s Not the Wild West Anymore

A recent Facebook post by David Sacks is worth reading.  He said:

I think silicon valley as we know it may be coming to an end. In order to create a successful new company, you have to find an idea that (1) has escaped the attention of the major Internet companies, which are better run than ever before; (2) is capable of being launched and proven out for ~$5M, the typical seed plus series A investment; and (3) is protectable from the onslaught of those big companies once they figure out what you’re onto. How many ideas like that are left?

As you might expect, his note sparked a fierce debate in the comments (and a TechCrunch article).

I think he’s more right than not:  the unbounded “wild west” days of the Internet are winding down.   I’ve written before about the GAAF ecosystem, and how much of the Internet is now controlled by Google, Apple, Amazon and Facebook.  Those gorilla incumbents have taken a lot of friction out of the system, but they also tax, manipulate, control, and limit success at the upper-bound.  You’re not going to build the next Facebook on Facebook.

(The incumbents will get replaced, but it will be a LONG timeframe — they’re too deeply entrenched.)

However, the Facebook discussion suggests a nice framework for evaluating opportunities.  Ideas within the incumbent ecosystem (especially pure Internet software ideas) will be limited.  But stepping outside that ecosystem makes things much, much more interesting.  Uber (mentioned in one comment) is a great example:  they solve a messy, real-world problem — they’re a lot more than just a app.

Markets are smart:  Silicon Valley will figure it out, but it might take a while.

The CPU Free Lunch is Over

Back in the late 70s, my dad ordered a Heathkit H-89 computer.  It had a 2 Mhz 8-bit Z-80 processor, took months to arrive, cost $1600 (in 1980 dollars!) and we had to put it together.  Now, you can go to the nearest Best Buy and walk out with a ~3Ghz system for a few hundred dollars.  While that’s a staggering increase in price performance, you may not have noticed:  we haven’t seen anything much faster than 3-4 Ghz for a few years.

That’s because we’ve “hit the wall” for single-processor CPU performance, and we’re at the limit for CMOS processes, circuit performance, and instruction level parallelism (ILP).  New processors from Intel and AMD are “spreading sideways”, implementing multiple CPU cores (2, 4 or even 8 processors).  Future processors will have even more cores, and you can “rent” as many additional processors as you need, in the cloud, on the fly.

This is a fundamental change in CPU performance architecture, and it’s forcing software developers to think differently.  For decades, you could speed up your software by just waiting for the next (faster) CPU.  Now, that’s no longer the case.

This leaves us with many large, complicated legacy code bases (e.g. database engines, solid modeling kernels, etc.) that need to be completely redesigned to take full advantage of multiple cores.  That, in turn, will create new opportunities — someone will step in to build multi-core scalable implementations of this stuff.

The Subtle Power of Git

Unless you’re a software developer, you’ve probably never heard of Git. If I told you it’s a source code version control system, you’re might then think, “who cares?”

Occasionally, a tool comes along that quietly but powerfully changes the way things are done. Git is one of those tools. Developed out of necessity by Linus Torvalds in 2005 to host the Linux kernel, it’s recently exploded in popularity.

For all of its features, Git’s real power is enabling distributed, non-linear development. Because branches are effectively “free”, everything’s done in branches. Developers typically work in their own branches. If a developer is fixing a bug, she might make a new branch, fix, test and commit, then merge that back into a working branch (or the main one).

In contrast, with systems like Subversion, there tends to be much less branching. Developers end up “huddling” around branches, and having to spend much more time coordinating commits. The usual result is that commits are larger and less frequent, which makes merging significantly more difficult.

With Git, developers make small, frequent commits to their own working branches, then they merge that branch into the main one. Often, the merging can be automated: the merger has a much better chance of success with 10 small commits than one big one. Also, Git enables ad hoc sub-projects: two developers working in the same area can merge between themselves, then when done, offer up the combined branch to merge into the main project.

But it’s not enough to just start using Git — if your team uses Git like they use Subversion, you won’t be getting the benefit. You’ve also got to change your development workflows.

Why aren’t you using Git for your project?