A Product Story: Three Lessons We Learned from Developing the Mobile App

TL;DR Remember what life was like before smartphones? Remember manually having to sync your computer’s playlists with your iPod every time you added a few songs? One of Spotify’s core products, our mobile app, was designed specifically to leave all of that busywork in the past, changing how we travel with our music forever.

In Episode 02 of our podcast series, Spotify: A Product Story, host and Chief R&D Officer Gustav Söderström chats with the engineers, executives, and other Spotifiers who helped make the mobile streaming revolution possible. Why was it so difficult to create Spotify for mobile even after we created the desktop app? Why were Spotify’s licensing deals such a game changer for us? Keep reading to find out the answers, and don’t forget to listen to the podcast itself to learn even more.

What’s user research really for?

When we first released the Spotify desktop app in Sweden in 2008, the idea of creating an on-the-go version of that same experience seemed out of the question. After all, Spotify didn’t have access to iPods or the other dedicated digital music players, and besides, at the time, most phones were equipped with only enough memory to hold a handful of songs.

Then something happened. Smartphones happened. The iPhone happened. Suddenly the idea of creating a piece of software that people could carry around with them everywhere didn’t seem so far-fetched.

Though it was theoretically possible to create a mobile edition of Spotify, there was still one major issue. A free, offline music app, one that could truly compete with the already-offline MP3 players, just wasn’t in the cards. First off, it couldn’t be free — you can’t click on ads without an internet connection — so it would have to be a paid service. Plus, our listeners already had access to all the music they wanted through piracy. So, once again, we had to ask ourselves something: Why would anyone pay for Spotify? How do you charge for nothing? 

And indeed, when we surveyed our users, we discovered that $10 per month — the number we settled on after months of licensing negotiations with labels (more on those in a bit) — was a number literally no one said they would pay.

Well, at least they said that. See, user research is great, but you have to know what it’s really there for. That was our first lesson: user research is for understanding what people think they will do, not what they will actually do.

There’s a reason for that, as Gustav points out.

Gustav: Humans are not very good at predicting our own future behavior, especially when it comes to what we are prepared to pay for something like convenience. We just can’t imagine our future selves being that lazy.

Countless research studies have shown that humans are not very good at predicting their future behavior, particularly when it is unrelated to their past behavior. Survey respondents in 2009 would have had little understanding of what a mobile version of Spotify would actually be like and how it could fit into their lives. 

So in retrospect, it’s not so surprising that our survey respondents were misguided. This brings us to our first lesson: we don’t have research methods that can see into an unrealized future. We have surveys that can help us understand people’s attitudes and opinions. More broadly, we have user research which illuminates people’s needs and current behaviors. This set of research methods can help us develop innovations that can be valuable to our users and improve their experiences

We had seen our desktop users value the convenience of the desktop app and we believed that the mobile app would deliver substantially more convenience. Of course people don’t think they would pay for something they were already getting for free — but they just might if it’s a lot more convenient than what they’re using. 

At least, that’s what we were betting on. We just needed to find another magic trick.

Beware your optimization bias

That was easier said than done, though. Setting aside the business side of things, actually building a mobile experience convenient enough to convert music pirates was a tall order, one without an obvious solution.

Back then, in the early days of Spotify, the desktop app may have technically been able to run on the iPhone, but that didn’t mean it was built for it. When Gustav asked Mattias Arrelid, one of Spotify’s early Mac developers, what the challenges were in translating the desktop app into a great mobile product, two things sprang immediately to Mattias’ mind:

1. “One [challenge] is that … a phone doesn’t have a constant power supply. For example, it doesn’t have a constant high-bandwidth network connection. Spotify was, at that time, at least leveraging peer to peer … If you do that on the phone, you basically force it to keep the radio on quite a bit. And that is draining in terms of battery.”

2. “The other one is data. [When] you had Spotify running on the desktop, you relied on some kind of data connection that [you] don’t really need to care about … On the phone, you had many contracts that had limited bandwidth included in the monthly allowance. So you really wanted to be careful about your consumption of that.”

It turns out by developing the desktop app to be as efficient as possible, we were actually developing something that was only efficient as a desktop app. Concerns like bandwidth and power consumption never factored into the equation, since you don’t need to worry about them when you’re a desktop user. And that’s where the second lesson comes in: whether you realize it or not, you’re always optimizing for something. This isn’t always a bad thing — after all, you’re still optimizing — but you are unwittingly creating blind spots for you and your product, ones that can hamper your growth down the road.

One of the solutions Mattias and the engineering team came up with to improve battery performance involved changing up the codec we used to encode audio. (Dive into the full episode to hear all the details about why.) But changing up our codec didn’t just have technical ramifications — it had business implications as well, implications that dovetail nicely with our final lesson.

Your tech is only half of the story

Spotify didn’t invent streaming, and it was only a matter of time until other companies could start to pull off a service similar to what we were offering. What we needed, in other words, was a breakthrough in our business strategy as well.

Enter licensing. Contrary to what you may expect, there isn’t a one-size-fits-all codec license for streaming songs. Different licenses are required for almost every use case — say, streaming on desktop versus streaming on mobile. This meant that hammering out licensing deals with record labels could end up being a lengthy, complex process. Rather than dealing with these complications, we saw plenty of other companies kick that sort of nitty-gritty work down the road, focusing instead on shipping code and getting to market quicker.

But to us, this wasn’t a sustainable strategy. So rather than take the same route, Spotify slowed things down, sweating the details in the negotiations for months on end, making sure that we had licenses that no one else had. That way, we could guarantee that we hit the ground running when we introduced a paid mobile tier. Here’s Spotify’s first general counsel, Petra Hansson, on the matter:

Petra: We spent a lot of time getting those licenses right. Because, you know, back in the day, the norm was more to just sign any licenses and then, you know, try and flip the companies, so it became someone else’s problem or companies would go belly up. So we were sort of hell-bent. And that’s one of the reasons why I joined [Spotify], because what I really liked about the company was that [co-founder and CEO Daniel Ek]’s vision was always to build something long-term and sustainable.

As it so happens, truly great product development is more than just a cool new feature or even a breakthrough new technology. Our third lesson is that truly great product development, in short, almost always combines technological innovation with business innovation.

That’s another three lessons down, but there are plenty more to go. The podcast series Spotify: A Product Story shares all these stories and dozens more, filled with insider insight and product strategy lessons from the employees, collaborators, and musicians who made Spotify what it is today. Join podcast host and Chief R&D Officer Gustav Söderström, and check out all the episodes right here.

Tags: engineering leadership