Spotify transitioned from the old Spotify way of working to a model with a PM and an engineering manager. Rob explains in detail the product organisation at Spotify and how he managed his own transition from engineering to management.
- We will cover:
- Rob’s journey from Canada to Linkedin in Mountain View and then to Spotify in Stockholm
- The rationale behind his decision to move into a technical product manager role
- His tips on how to communicate effectively with developers, stakeholders and leadership
- Which traps to avoid when you move from software development to product management
- The product org structure at Spotify
- How at Spotify, the duties of the engineering manager and product manager are divided
- How remote work is organized
Hi Robert, can you tell us how your professional career started?
Sure! I made my first experiences through the cooperative programme at the University of Waterloo in Canada, where we did six internships throughout our degree. My first one was at a bank. Then I built HR systems for a big-time nuclear engineering firm in Canada. I moved to Silicon Valley, where I did an internship for IMVU, which is known for its Lean Startup Methodology. Then I did an internship at LinkedIn, where I got hired full time when I graduated.
So I moved to Mountain View in 2013 and started working as an infrastructure engineer, building the graph database. As I always wanted to work and live in Europe, I started looking for opportunities overseas. In 2016 I moved to Stockholm to work at Spotify.
Where you shifted from software development to product management.
When I joined Spotify, I was still an infrastructure engineer. But I was very inspired by our product manager. He was the equivalent of a product lead of our tribe, and he was involved in a lot of bigger projects than just our team. I liked how he would think about how our team’s expertise could be used to level up how Spotify was using data.
And rather than actually solving these problems himself, he would pitch the right problems to solve with his brilliant pitch decks and presentations. He was really digging into the why, and I thought this was the missing piece of the puzzle that I didn’t see at LinkedIn. When he changed teams, I applied for his job, which I got.
So how does your team look like right now at Spotify?
My team is called Voxel and consists of seven developers, mainly mobile but also for the web, the engineering manager, the product manager, and our user experience designer who works across teams and cares more about the workflow. Our product is called „the user behaviour instrumentation framework,“ which the feature developers in Spotify use to capture what people are doing in the app. So if you navigate from one page to another, we need to understand that.
So the developers can use the libraries of the product to produce datasets that can easily be used for recommendations, for example.
How do you work together with the engineering manager? What is your role?
My responsibility is to work with the stakeholders, understand the users, go to user interviews with our UX designer, and develop this high-level strategy for the team and some larger, long-term goals.
I mean, it gets more detailed than that when I have to consider what other teams are asking us to do. Then the engineering manager and I will discuss how we should approach trying to achieve these goals.
So I would say I significantly influence what we are trying to accomplish in six months or a year and how we choose between the different routes to take.
Do you write tickets for the backlog?
That’s mainly the engineering manager. I provide context and answer questions rather than figuring out how we do it. I write more like what we call epics. Maybe several sprints explain a unit of customer impact that we’re hoping to have one step down. And this is the way to split the responsibilities between the product manager and the engineering manager.
Is this the way all teams work at Spotify?
There are many differences between the teams, and this setup with a product and engineering manager is reasonably new.
Three years ago, we transitioned from the old Spotify way of working to this setup. For example, we don’t have chapter leads anymore. I mean, that model was very popular in 2014. And we have scaled quite a bit since then. The trick was how to take the same sort of principles and scale it up to many, many more teams.
This transition is not something that happens overnight. And the way that I’ve seen it done in most teams I’ve talked to is that it is up to the two of them to figure out how it is best to work together and cover all the basics.
What did you learn when you transitioned from your developer role to the product manager role?
In the beginning, I was still writing stories. Eventually, I realised that that was a bit more prescriptive than I probably should have been. It worked at the beginning when I had all the context and understood how to do everything. But that quickly stopped being the case.
So I learned that it was best to delegate those to the engineers. I found that if the engineers understand the problem very well, they’ll do a good job. So the biggest tip is:
Spend time writing about the problem that a particular epic is supposed to solve, rather than actually how you might think about solving it.
I am always amazed if I have an idea of how things could be done by what the developers are doing. It might be totally different and works just as well, but very likely better. So I am constantly reminded that that’s the way to do it.
Is there a structure or a certain way you write stories at Spotify?
We’ve taken the format to make sure that there is a good, reasonable definition of done and acceptance criteria. We break it down how we might accomplish it in bi-weekly grooming sessions. And sometimes we realise that this problem is actually much larger. In which case, it requires more thought.
How do you like the job as a product manager? Was it the right decision?
One of the things I was very curious about after my experience at LinkedIn was how to solve problems that are larger than one team.
At LinkedIn, we were building a database, and our team was about 25 people. Building databases is complex, and it is a lot of software and moving pieces. So it made sense to me that we needed a big team. But working in a team with 25 people is incredibly difficult. And I saw a lot of ways for it not to work.
I guess one thing I enjoy is seeing these big problems that we can collaborate across different teams to solve. So maybe we have a problem that we are trying to solve which falls neatly between my domain and your domain. And our teams are going to work together on it.
This leads us to the overall product organisation. How does it look like at Spotify, and how big is it?
I don’t know the exact number, but we have hundreds of product managers. We are not organised as one horizontal product team. Spotify itself is divided into different business units, and I am in the consumer business unit. There is also the finance business and creator business.
Each of these units has its sets of missions and tribes, and within those tribes, we have product organisations. The hierarchy is business unit, then a mission, tribe, and within the tribe there are the squads. I am part of the platform mission, which means we support all of Spotify’s technology in the data and insights tribe. Because we are a very large tribe we actually break it down even further into different product areas. I am in the data collection product area, where we have four teams. Each team has its own product manager, and we also have one product lead for our product area. Other product areas are experimentation, machine learning, insights and data foundations.
And how are those product areas orchestrated, and how do you prepare your roadmap, let’s say, for next year?
We do have a product lead who is responsible for the overall direction of the teams. It’s done differently every time we do it, but we start with a high-level strategy. What are the problems that we see, and what steps could we take towards making a difference?
Within our four teams in the product area, we all have certain subdomains. My team is about collecting data from the clients. So we would think about how we actually capture the signals such that the data is good, whereas there is another area that is more focused on user privacy. Another one is more about the underlying infrastructure. We would all contribute to this overall strategy, and our product lead would decide about the product strategy for our whole area.
After that, we are more or less autonomous in the teams. It is a bit more complicated because we also have to be aligned with company strategies that change often.
Do you use OKRs at Spotify?
Yes, exactly. Once we have decided what the directions are, we set the OKRs. Within platforms, they are maybe more milestones than the way OKRs are described, and they are not set for each team but for all four teams. The next step is for the engineering manager, a senior developer, and I to think about what we need to do to achieve them.
Coming back to your role: What are the biggest learnings in being a product manager?
I realized what I was doing wrong was trying to have all the answers. Especially when I switched over to being a product manager, I tried to make sure that I could understand all the different aspects of our product. All the different ways the platform is supposed to work, all the use cases, current and future. I thought I was supposed to answer all the questions from the stakeholder, the team and the company.
I realised that occasionally I would get these questions which would stop me a little bit.
Trying to have all the answers and trying to give answers rather than listening was a mistake that I made quite often when I was newer.
So it is important to have strong opinions. But have strong opinions that are weakly held.
What does that mean?
It’s a funny paradox because, at the beginning of your role, you are learning, learning and learning and then all of a sudden, you say, „OK, I’ve learned everything.“ Then you stop listening and dictate. But it should be more iterative. Because when you stop listening, you miss things that might be important.
Another learning I made is actually writing down the strategy rather than just talking about it. It’s really important because that gives people something they can refer to. Give engineers something they can read over and over again to try to understand the why.
And the third tip I can give is: Try not to be too busy. It is very easy to accept all the meetings and spend your time in syncs and be very reactive. But that probably means you are not spending enough deep time on actually important things. Every product manager I met has fallen into the trap and has varying success levels getting out of it.
How do you write down the product strategy?
I haven’t found any good templates yet. But the way I’ve done it is to start with a little bit of a story about how we got to where we are. And then it explains my diagnosis of what I think the problem is, and why I think we have this problem. Then I describe the principles that we should operate to solve this. It might have about seven pages.
What tools do you use?
The team uses Asana for the sprints, and we have confluence for documentation, but it’s used quite sporadically. Most of what we do is just Google Docs. We also have something homegrown, which is called Backstage. So a lot of docs are organised with Backstage.
Can you elaborate a bit more about product vision, product strategy and product execution?
So the product vision is like the future perfect state of the problem. In our case, it is the user behaviour instrumentation framework perfectly integrated. The way it is built is that feature developers have no burden with the framework, that it is easy to use for machine learning. This is the north star goal.
Product strategy represents the prioritised routes along the way to get there.
From the execution point of view, I don’t know how close we are doing Scrum by the book. But we have a sprint planning every two weeks. On the off weeks, we would have a grooming session to groom the different epics on the roadmap. And at the end of the sprint, we have a retro.
What do you think is more difficult: to communicate to stakeholders or to developers?
There are definitely those two parts of the job. The part that I don’t particularly enjoy is the project management reporting aspect of it. That can be just not exciting. Who is really listening to these reports? So making sure that the way we do reporting and how we bubble information upwards is one thing that I’ve been trying to think about.
Another aspect of communication that I found is pitching and influencing different problems that I think we should be solving. And this is a way more significant part of the job than I had thought when I started.
To finish up this interview, one last question. There was an announcement that everybody can work fully remote now at Spotify. Can you explain how it is actually done at Spotify?
So previously, you needed to be located in Stockholm or New York. We had smaller offices in Gothenburg, in Boston and London. But now, and I can only speak for my business unit, you can choose to relocate to any country in Europe where Spotify is a corporate entity. Or you can go where we have an office or a coworking space. So my team, for example, just hired somebody in Milan. And we also have somebody in Hamburg.
I was astonished by how well my team did during the Corona pandemic. We have already been distributed before. And suddenly, everybody went home, and it levelled the playing field for how we were working with people in New York, which was previously a lot harder. But these were teams that knew each other. I am a lot more apprehensive about seeing the next stage when we start having teams that have never met each other in person.
Dear Robert, thank you very much for the interview and all the best to your team.
This Interview was held remotely by Stefan Vosskoetter and edited by Thomas Riedel. Photos by Martin Wichartd.
