Why Software Platforms Should Be More Like Pandora

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

For many years after the de facto industry standardization on the MP3 format, the primary problem remained music acquisition. There were exceptions, of course: serious Napster addicts, participants in private online file trading or even underemployed office workers who used their company LAN to pool their collective music assets. All of these likely had more music than they knew what to do with. But for the most part, the average listener maintained a modestly sized music catalog; modest enough that millions of buyers could fit the entirety of their music on the entry level first generation iPod, which came with a capacity of 5 GB. Even at smaller, borderline-lossy compression levels – which weren’t worth using – that’s just over a thousand songs.

These days, however, more and more consumers are opting into platforms with theoretically unlimited libraries behind them. From iTunes Radio to Pandora to Play’s All Access to Rdio to Spotify, listeners have gone from being limited by the constraints of their individual music collection to having virtually no limits at all. Gone are the days when one needed to purchase a newly released album, or even more worse, drive to a store to buy it. Instead, more often than not, it’s playable right now – legally, even.

The interesting thing about music lovers getting what they always wanted – frictionless online access to music – was that it created an entirely new set of problems. Analysis paralysis, the paradox of choice, call it what you will: it’s become exponentially harder to choose what to listen to.

Which is why those who would continue to sell music are turning to data to do so. Consider iTunes Genius, for example, introduced in 2008. It essentially compares the composition of your music library and any ratings you might have applied to the library and ratings of every other Genius user. From the dataset created from the combined libraries, it automatically generates a suggested playlist based on a seed track. While it seems like magic, because curating playlists manually can be tedious, it’s really nothing more than an algorithmic scoring problem on the backend. Pandora takes an even more direct route, because it has real-time visibility into both what you’re listening to as well as metadata about that experience: did you rate it thumbs up or down, did you finish listening to it, did you even listen to it at all, are there other similar bands you wish played in the channel? All of this is then fed right back into the algorithms which do the best they can to pick out music that you, and thousands of other users similar to you, might like.

While the approaches of these and other services may differ, what they have in common is simple: a critical mass of listeners who are all voluntarily – whether they know it or not – building an ever larger, and ideally ever smarter, dataset of musical preferences on behalf of the vendor they’re buying from.

This is one of the examples that software companies should be learning from, although that should be “non-music” software companies, since just about every important new music company, including the examples above, is a software company first, music company second. Like the music companies, software companies should increasingly not be focused merely on the asset they wish to sell – software, in most cases – but data they might be in a position to collect that can be used to sell that software. Or as a saleable asset in and of itself.

For example, consider the case of a PaaS platform vendor. While the intial generation of platforms – GAE, Force.com, etc – were very opinionated in that they dictated runtime, database, schema and so on, the majority of players today offer multiple choices. Database options might include MongoDB, MySQL and Postgres, while runtimes might range from Java to JavaScript to PHP to Python to Ruby.

Many incoming customers, of course, may already know what technologies they prefer; they may even be locked into those choices. But those who haven’t made choices, and even some of those who have, would appreciate more detailed information on usage across the platform. What if, for example, you have real-time or near real-time numbers for the adoption of MongoDB, for example, which indicate exploding traction amongst other users of the platform? Or a spike in JavaScript runtime consumption? Even more interesting, how are the databases trending broadly versus for customers of a given size? Every choice a customer makes – to use Java, to deploy a MySQL instance – is the equivalent of a Pandora “Like” signal. But you have to capture these.

Like music services, most technology platforms – particularly those that are run in a service context – are generating valuable data that can be used to inform customer choices. To date, however, very few platform providers are even thinking about this data in a systematized fashion let alone exposing it back to their customers in meaningful ways. We know this because we ask about it in every briefing.

Those customers that embrace a software plus data approach, therefore, are likely to have a competitive advantage over their peers. And importantly, it’s the rare competitive advantage that becomes a larger barrier to entry – a data moat, if you will – over time.

One comment

  1. The problem is to avoid becoming lost in analysis of meaningless data about software so that you don’t see the big picture. Take MongoDB for instance: early versions of Mongo had a bad habit of randomly losing user data due to the fact there was no journal. You don’t need much in the way of stats to see that problem had to be fixed to have a useful product. It is doubtful that such analysis can be automated for software in anything like the way that Pandora does for songs. It’s an entirely different class of optimization problem.

Leave a Reply

Your email address will not be published.