Gustav Söderström

What we've found, which I don't think is very contrarian at all, I think this is the case in most companies, is around the VP level. So if you have Daniel, then you have the C level, myself and others, then you have the VP level, that is a good mix of instead of having one person in the company think, so only Daniel then and the rest just do, you have on the VP level in the company this many tens to maybe hundreds of people that have a lot of autonomy to think.

The problem with that is if you put autonomy very far towards the leaves of the organization, and also if you combine that with having a very junior organization, which we did back then, there's a fair chance that you're just going to produce heat. You're going to have a hundred squads with a hundred strategies running in a hundred directions.

The quality of your machine learning, if you're going to have a single play button, needs to be literally 100% or zero prediction error, and that's never the case. So let's say that you have a one in five hits, four out of five things are done, then you need a UI that probably at least shows five things at the same time on screen. So you have a one in five of something being relevant on screen.

The idea with autonomy is very reasonable and the right one, which is we work and we are hiring the smartest people we can find and we pay high salaries for that. So if you're hiring smart people, one way to think about it is you're renting brain power. So if you're renting all of this expensive brain power and then you give them no room to think for themselves, that doesn't sound smart, then you should actually hire less smart people and keep your costs down or something.

I think there are two fundamentally different types of product development. One is designing a new feature. It is hard, but it's voluntary for people to use. So you do the AI DJ. Some people love it, that's fine. If you don't like it, it didn't make it worse for you. But when you redesign, it is much more tricky because it's not voluntary to participate in the redesign.

You have to believe in things 100% until the data says no and then you believe in something else 100%. That sounds easy. It's very hard to do, to the extent that people get upset when you do it because, for some reason, people don't like when people change their minds.

The internet started with curation, often user curation. So you took something, some good like people or books or music, and you digitize it and you put it online and then you ask users to curate it. And that was your Facebook, Spotify, and so forth. And then after a while, the world switched from curation to recommendation, where instead of people doing that work, you had algorithms. And that was a big change that required us and others to actually rethink the entire user experience and sometimes the business model as well. And I think what we're entering now is we're going from your curation to recommendation to generation.

As you grow the company, scaling in increments of seven engineers just creates a ton of overhead. So, obviously, our teams now tend to be much bigger, maybe two, three times that at least per manager to maybe have 14 or something instead of seven and just less overhead roles.

When we tested some of them on Home, we switched it from 90/10 to 10/90. So 10% recall, 90% discovery. And while people want discovery, they probably don't want 90% discovery, instead of 90% recall.

What we hear from users again and again, though, is that they say that they get trapped in a taste bubble. So I love my Spotify, I love this, but I'm a little bit bored with EDM now and Spotify's not suggesting something completely new. And if you think about that problem, it may sound similar to the recommendation problem, it's just another recommendation problem, but it's actually fundamentally different because when you're recommending another EDM track inside the EDM playlist, you have a lot of signal from that user that they like EDM. But if you're going to recommend a completely new genre, by definition, you have no idea.

I think to your question of principles around that, there are a few pretty distinct principles that we've learned. One that I really like that is not my principle at all, I think it is straight from Chris Dixon, is the principle of fault-tolerant user interfaces. So I can't say how many times during the early machine learning era when we said we're moving from curation to recommendation. I saw a design sketch that was a single big play button because clearly that is the simplest user interface you can do, but if you don't understand the performance of your machine learning, you can't design for it.