Archive for the 'Software' Category

Repeat After Me: “Location” is a Feature, not a Product

Two years ago, Daniel Cozza and I spent a lot of time looking at location-based apps.  We brainstormed tons of ideas and prototyped one.  But we ultimately decided not to pursue it; the space (and the iPhone app space, generally), was starting to feel really crowded.

Later, it also became clear that many of our ideas were really nice features on existing platforms, not new products.  For example, Twitter and Google have been steadily adding new location features.  And a few days ago, Facebook finally launched their check-in feature, Facebook Places, as (presumably) a first step to making Facebook much more location-aware.

Facebook’s news is interesting from a number of angles, some I’ve written about before:

  • Gorillas rule. Facebook watched the app evolution closely, then made their move.  They won’t let anyone get big enough to threaten them in any one area, and if they do, they’ll (a) use their policies to control things (as they’re attempting with Zynga and payments), or (b) take over the functionality (as they’re doing here).
  • APIs are a great way to seed an ecosystem. Foursquare’s original integration with Facebook was a huge part of their growth.  A continuous stream of check-ins in the news feed is a great way to acquire users.  Now, Foursquare’s integrating with Facebook’s new location API.  Foursquare PR spin aside, make no bones:  Facebook just grabbed a huge chunk of strategic functionality from Foursquare.  (My bet is that Foursquare devolves over time to a location-based game, or set of games).

For users, this is all great news — having Facebook be more “location aware” is hugely useful.  I can’t wait to see what new features become available.  For entrepreneurs and ecosystem players, it’s a bit more tricky:  how can you play here without having Facebook stomp you when you get too big?

The Internet Used to be Flat

The Internet used to be a lot “flatter”.

Last decade, there really weren’t any major points of control.  If you had an idea for a new app or content site, it was pretty much a level playing field, and you could largely control your destiny.  The browser was a major point of control, but that was very “horizontal” — few Internet companies worried about bumping into Netscape or Microsoft as a competitor.

Now, the world is quite different.

Google emerged as the first gorilla, becoming the “starting point” for many Web sessions.  Most Internet companies are now hugely dependent on Google, directly or indirectly.   SEO-dependent companies can find their fortunes change overnight, and Google’s “quality score” manipulations can materially affect an SEM budget (and usually not in the favorable direction).

Facebook is the next gorilla, especially with their recently announced strategy to own the social fabric for the Internet.  They’re a major “attention point” for many users, and it’s hard to consider a new Internet idea without a Facebook strategy.

Twitter is a gorilla-wannabe, but it’s not clear if they’ll win (long-term) over Facebook status updates.  But the Twitter ecosystem got a splash of cold water with the news of Tweetie’s acquisition.  Many app developers are now wondering if they’ll end up competing with Twitter.

And finally, Apple is emerging as a gorilla wildcard.  They don’t have leading market share overall, but their mobile devices (iPhone, iPod, and now the iPad) are dominating and defining their categories.  The App Store is a huge improvement over the carrier’s closed systems, but it’s hardly open.  Apps are approved at Apple’s pleasure, and can be un-approved at any time, without reason or notice.

The Internet’s Darwinian era seems to be over.

Your on-line presence is more than your Web site

Five or ten years ago, your Web site was your entire on-line presence, simply because there wasn’t any other place to deploy content and functionality.

Today, that’s not the case at all: with the proliferation of platforms (Google, Yahoo, Amazon, Facebook, MySpace, Twitter, etc.), embeddable content, widgets (video, Flash, etc.) and access methods (desktop, mobile, game system, large screens) your on-line presence is much more than just what’s on the Web site. In extreme cases, there’s no site at all: a company’s presence may be entirely embodied in a Facebook app, for example.

Moral: don’t think of the Web site as the only place to focus development efforts. Treat the off-site stuff as first-class features and prioritize them against the Web site investments. Specifically consider:

  • Widgets
  • iPhone app (or an iPhone version of your site)
  • Google widget
  • Facebook & MySpace app
  • Twitter integration

Hulu Desktop & Boxee: Temporary Solutions

Hulu Desktop just came out:  it’s a client-app (Mac and Windows) that provides a “lean back” UI for Hulu video content.  It integrates remote control inputs, so it works well for folks plugging computers into the living room TV.

I’ve written before about the evolution of Internet TV:  Hulu Desktop and Boxee, as client apps, are just temporary, intermediate points.  There are few reasons (soon, no reasons) why these UIs can’t be provided through existing browser technologies, with no client install.

We saw this movie with Web browsers in the mid-90s.  As the Web took off, many groups talked themselves into a need to “control the client” by having their own Web browser.  In some cases, there were good technical reasons:  browsers were pretty limited, and adding small capabilities could enable big things.  In many cases, it was just flawed strategic thinking.

The Web became part of the operating system (or even has become the OS iteslf) and with increased capabilities, subsumed a lot of apps that would otherwise be client-deployed.  These client-side TV apps feel like the last vestige of stuff to get absorbed into the browser.

Inflexible Process meets Immovable Software

Devdutt Yellurkar (at CRV) and I were comparing enterprise software war stories and notes on SaaS opportunities (he did CRV’s recent investment in ZenDesk).

The enterprise software business model is a tough one.  Large organizations frequently need custom features, and with project investments of millions or tens of millions of dollars, companies expect the solution to fit their operations and processes.  As a result, many enterprise software companies were more like professional services businesses that happened to have some software, than the other way around.

But there’s an interesting angle for SaaS:  the lower price points make organizations more willing to accept the feature set “as-is”, and adapt their business to the software.   If the hosted software costs (say) $10k/year, it’s hard to justify $500k of customization work.

This drives another effect:  SaaS offerings can focus on the core features that actually get used.  Many enterprise software solutions turn into bloatware:  the feature set evolves to an aggregated super-set of all possible customer features.   Worse, after the purchase decision, many customers end up using a sub-set of what they originally thought they needed.   This is why the product manager’s job is hell:   the product has 100 features, only 40 matter to any given customer in the sales process, and only 10 get actually used.

Browser-Powered Television

[A longer than usual blog post, summarizing some strategy ideas I've been working on.]

In the early 90s at DEC, I had a colleague that worked with the cable industry.  I tried (unsuccessfully) to convince him that TCP/IP would be the winning network infrastructure for the fancy interactive TV services everyone was talking about.  In the end, “adequate general purpose” solutions always win.  Proprietary solutions can’t compete with economies of scale.

Moving up-stack, I’ve been thinking about how TV content delivery is going to play out.  We started with over-the-air broadcast, then shifted to cable (first analog, then digital), and now we’ve suffered through a decade or two of crappy set-top-box user interfaces fed from proprietary cable networks.  Along the way, our TVs have evolved from tiny, fuzzy CRTs to large, crisp 1920 x 1080 color monitors.

As household bandwidths have increased, we’ve got options that end-run cable companies to get content on the screen:  Apple TV, Roku/Hulu, Tivo, network-enabled DVD players, game consoles, etc..  But these are still closed & proprietary:   I can’t deploy my own apps (or even content, in some cases) without a lot of permission from other people.

On the bleeding edge, users are plugging their large-screen TVs into computers (the Mac Mini is a popular option), sometimes installing software like Boxee to provide a “couch-friendly” UI.  I like Boxee, but it’s only an intermediate step and feels like a response to the past.  Users don’t want “set top boxes” (STB) or “media centers” or “electronic program guides”; they want unrestricted access to apps and content.

And a general-purpose delivery mechanism already exists:  Web browsers.  As Apple demonstrated with the iPhone, HTML+JavaScript is an excellent way to get content on-screen, because it leverages a deep existing technology infrastructure.  (And adding Flash makes it even more compelling).

I’m betting the same will happen with TV:  HTML (and related technologies) will become the new “broadcast standard”.  I’m not talking about seeing Firefox’s File/Edit/View menu bar on your TV; I’m saying that content will be rendered by a full-screen browser engine using HTML+JavaScript+Java+Canvas+Flash+Quicktime+etc technologies.   Users will access any app or content they want by navigating to the appropriate URL.  (Innovators will adapt browser navigation to the TV screen & remote control, just like Apple adapted Safari for the iPhone.)

Here’s the test:  how hard is it to write Boxee’s UI or any STB UI as a full-screen JavaScript or Flash app?  Apart from accessing LAN content, it’s relatively easy.

I’m pretty certain this is how things are going to play out.  Now the entrepreneurial question is:  what to do about it?

When Disruptive Value is Sponged up by the Incumbents

Charles Teague and I were riffiing today on entrepreneurial opportunities around the iPhone, location-based services, and other areas.   A recurring discussion theme was:  sometimes technology disruptions don’t lead to NewCo opportunities.  Why?

Consider the hype around Web Services from years ago.  There were dozens (perhaps hundreds) of companies funded, but today, can you name a single durable, sustainable, profitable, value-creating Web Services company?

Web Services is clearly an important disruptive technology, but the value created was entirely absorbed by existing companies:  Amazon, Google, eBay, Yahoo, etc. and the hundreds/thousands of other Internet technology companies.  In other words, it wasn’t disruptive enough.

True disruption comes when a new technology is so different, existing companies have difficulty processing it, and that “processing delay” lets a NewCo move in.  The Internet was the last major example:  Amazon was off to the races while Barnes and Noble was still parsing the implications.

Many disruptions really aren’t truly disruptive.  Take location-based services — it seems clear that most of the benefit is going to be absorbed by existing apps and companies.  It’s not to say that location-based services can’t be a component of a successful app, but I have a hard time believing that the location-based companies (e.g. Loopt, Where.com, etc.) will be successful without major strategy changes.

Flash is the New Client-Side Java

Remember Sun’s vision for Java:  client-side applets, downloaded on the fly, running in/alongside the browser?  It was a great vision, but Microsoft moved to block browser adoption and Sun botched it.  After nearly 15 years, client-side Java never really hit critical mass.

Instead, the original vision has quietly been realized by Adobe Flash.

What happened?  Video.

Site operators (notably, Youtube in 2005) discovered Flash was the best way to get in-browser video.  The growth of Internet video cemented Flash’s position as a ubiquitous browser-plug in.  Then, Adobe started adding Java-like features, notably ActionScript 3, a fairly efficient virtual machine, and a decent set of libraries.

Most of my developer friends reject Flash as “an animation system, with a crappy scripting language“.   They were probably right 3-4 years ago, but not any more.  With the latest Flash players, Adobe’s moved away from the animation-centric design to much more a generalized, programmatic system (that happens to have great animation support).

Just like Java, except with >98% market adoption.

Microsoft’s Ain’t the Gorilla No More

I was surprised at Microsoft’s recent layoff news:  (a) this is their first major layoff, and (b) they’re only laying off 5%.  The financial analysts are calling this the indicator of general technology/software woes.

The technology sector is definitely challenged, but Microsoft’s problems are quite unique. They’re an old-line software company with a market structure and core business changing out from under them:

  • Most high-volume, general purpose software components (e.g. OS, productivity, etc.) will be free or pseudo-free (ad supported).    Key exceptions:   games, and small apps (e.g. $1 iPhone apps).
  • Most apps will be delivered as on-line services, with subscription or ad-based revenue models.   Exceptions:   apps needing heavy client-side interactivity, computation or data manipulation (e.g. PhotoShop).
  • Many software companies won’t sell software at all, they’ll sell the value the software generates (e.g. Google, Kayak.com, etc.)

Microsoft has cash and a huge installed base, so they’re not going away anytime soon.  But market structure changes are the toughest transitions for any company to navigate, and Microsoft hasn’t yet done a great job showing they’re up to the task.  Witness:  botched discussions with Yahoo, and I’m still amazed that Microsoft hasn’t jumped on a app store for Windows that makes it ridiculously easy to find, buy and install small-dollar applets.

My bet:  without bold moves, they gradually fade to an “inertia existence” (e.g. IBM, Sun), without the margins typically enjoyed by the gorilla.

“We’re smart” is no longer a barrier to entry

Over creamed chipped beef this morning, I subjected my friend Antonio to my latest rants on challenges and opportunities in the software business.  He helped me crisp up a major theme:  being smart is no longer a barrier to entry.

Software used to be really really hard:  there weren’t a lot of developers (and few that were superstars), languages were primitive, tools were primitive (and expensive), the stack was expensive and buggy, and servers cost real money.  Dev cycles of 12-18 months weren’t crazy, because it sometimes took that long to build something meaningful.  Sometimes merely having shipping software was enough of a barrier.

Today, things are much easier:  dynamic languages are hugely productive, the tools+stack are free, free code libraries are everywhere, and fast servers can be rented by the hour.  Smart developers abound (they may not want to work at your company, but they’re out there competing with you).  Useful functionality can be built in days, weeks or a few months.

So what does this mean?  It means that software efforts doing things that are easy and plentiful generally aren’t going to be worth that much — it’s supply and demand.

For the effort to be truly valuable, it needs some barrier element beyond “we have really smart people with a clever idea”.   There are LOTS of smart people out there that can re-implement your idea, or cherry-pick the essential parts.  If you only spent 2-3 months building it, you don’t have much of a head start.

The key is to attach the software to some non-replicable element.