 Hi, my name is Madeline Boucher. I go by Maddie as well, and I'm here today to talk to you about platform as a product, why companies need platforms and why platforms need product managers. So overall, I'll start with a quick intro and then talk about why platforms, what even is a platform? What do they do for businesses and why are they necessary? Then I'll talk a little bit about what PMs do for platforms and why PMs are so necessary for platform product development, and then wrap up with a few quick takeaways. So first things first, a little bit about me. Like I said, I'm Maddie. I am a senior product manager at Spotify. My team is called the Music Vertical Platform, and we are within the Music Mission. So that's the side of Spotify that faces the music industry and helps creators and all the people who work for and around them to be more successful on Spotify and in their careers. So before Spotify, I worked at an online art marketplace called Artsy. I was the product manager of their platform team. And before that, I was the lead of the Art Genome Project, which is a pretty awesome little platform product and you should go look it up. I have a humanities background. I studied East Asian Studies and Art History in both undergrad and grad school. I am not a computer scientist. I do not know how to code. And so you might wonder why I ended up in this very kind of funny, niche, technical side of product management, but I'm gonna go into that today. And I live in Brooklyn with my family. So why platforms? You know, the first question to ask is, like, why did I end up in platform product management? And what is that exactly? Well, there are so many ways to be a product manager and the industry is demanding further specialization, especially as the field of product management matures. You can become a mobile PM. You can become an ML PM. You can be a B2B specialist, or a B2C specialist, or a B2B2C specialist. In your PM career, you're likely to find yourself drawn into one of these focus areas more than the others, even if you have many different kinds of experience under your belt. So why platform product? I kind of fell into this sideways, but found that it scratched a lot of my itches. I love systems level thinking. I love architecture and collaborations between product strategy and technical leadership. But most of all, the thing that attracted me is that it's about building something sustainable and embedding long-term thinking in the way that you create your products. So to figure out why you might want to pursue product management, first you have to grasp what is a platform? What's it for? Why is it uniquely powerful? So to answer these questions, I find myself going back time and time again to a text written by an engineering lead called Steve Yegge. He wrote this platform rant in 2011. And it's really hard to believe that this was written more than 10 years ago in a totally different tech landscape because it's still so relevant today. So I'm gonna read through this excerpt. So background 2002, Jeff Bezos issued a mandate that was so out there, so huge and eyeballingly plunderous that it made all of his other mandates look like unsolicited peer bonuses. And this is about working at Amazon if you haven't intuited that. So this mandate went as follows. All teams will henceforth expose their data and functionality through service interfaces. The team must plan and design to be able to expose the interface to developers in the outside world. No exceptions. Anyone who doesn't do this will be fired. You wouldn't really think that an online bookstore needs to be an extensible programmable platform, would you? And as you may have guessed, this turns out to be a very prussian insight because today is Amazon an online bookstore? Absolutely not. So these platform components take pieces of the tech stack and turn them into products that other users can interact with, build with and extend whether those users are internal teams or external developers or just somebody playing around with a public API. So extensibility is the key concept here. So Steve went on to explain, Amazon realized that the infrastructure they built for selling and shipping books and sundry could be transformed into an excellent repurposeable computing platform. And thus, AWS was born, responsible for about $6.5 billion in revenue in Q1 of 2022 and consistently responsible for about half of Amazon's operating profit in recent years. So this ends with the maxim, a product is useless without a platform or more precisely and accurately, a platformless product will always be replaced by an equivalent platformized product. The golden rule of platform says, Steve, is start with a platform and then use it for everything. You can't just bolt it on later. So I like to think of this too as the difference between the zero to one versus the one to infinity. What I mean is that the zero to one is everyone just building their features, shipping their products, moving fast and breaking things as we have been told to do. But all of a sudden, once you reach that one, nothing is quite right for that next stage of evolution. Nothing you've built extends easily further because all you thought about was solving the problem directly in front of you. So yes, you got from zero to one, but why start to get to one in the first place if you want to stop there? No one wants to stop at one. So of all the definitions out there for platforms, I like the really broad definition reusable building blocks. These building blocks are products just as much as a checkout flow or a messaging app or a notification feed. They might be harder to see, they might be harder to visualize, but they are products all the same. So just as for instance, here's some examples of platform products just within Spotify that are external facing. So keep in mind that these are the externally visible iceberg tips of services that we internally within the company use and build upon. They include the Spotify web API, SDKs that allow Sonos and in-car apps and Google Maps and all kinds of other applications to control Spotify playback through their interfaces. They include design libraries, our knowledge graph about audio creators, musicians, podcasters, producers, songwriters, personalization APIs and more. So our company truly runs on these reusable building blocks and sometimes we even expose them for external developers to use. Okay, now that we've discussed what a platform is, you might be thinking this is a really technical problem. It seems like it should be engineering led. So if you don't understand what product managers could contribute to a platform, if they're not also tech experts or engineers by training, I can just tell you that I'm a living example to the contrary. I have no coding experience. So I think the best way to illustrate this is by walking you through a case study of a project that I worked on in 2019. I'll walk you through the broad strokes. So if you know anything about the music industry, it's probably about the rights, permissions, licensing deals and various actors and how they are intertwined are very complex and difficult to model. You might also think that this is a purely technical problem, this problem of how do we evolve our products to fit the tricky permissionings and rights models of the music industry. Specifically back in 2019, we had this problem around bringing label users into our flagship product Spotify for Artists. Up until that point, label users had been accessing analytics about their catalogs in a totally separate app. We wanted everyone to be in the same app. So we were faced with this issue of label users and Spotify for Artists who needed access to the right stats based on their markets and their rights. So another way to put that is that different users need different views on the same data in the same features, depending on their permissions. The big crunch was that our data warehousing solution couldn't do it. So is that a technical problem? Yes and no. It's a product problem because if you solve this just as a technical problem, you might introduce the ability for two different users as in this illustration here to take a look at one song and see two slightly different views of the same data. But you would have missed an opportunity to ask what's the real problem here? What's the real need? So the initial solution that was kind of proposed by the engineering team was to choose and implement a new technology to enable flexible views of the same data. However, if we back up and look at the opportunity, we need to fully understand where the Spotify for Artists product is evolving in the future. And in particular, the data focus parts of Spotify for Artists in order to pick the right solution. So my job became to do some recon work, also known as user research. In investigating who the users of this new system would be, this new data warehousing system, we figured out that it was going to be data engineers and backend developers who were part of teams that were building analytics features into Spotify for Artists or other music industry-facing applications. So now that we know who those people are, we can go talk to them. It's important to understand their roadmaps and visions for the future in addition to just talking to the developers about what they need. And the reason for that is that in choosing a new technology, we're actually making a very difficult to reverse high-impact decision here. It needs to work on the timescale of years, not months. So we really have to investigate where the product is going in the future. So in this process of user research, we learned that there's a lot of common denominators that creators and their teams care about and therefore the teams who are going to be our customers cared about. So those common denominators were streams, listeners, geographic and demographic data and aggregate as well as Spotify specific things like playlists. We learned that different teams wanted to use those data points differently when they were building their features, but they were all interested in those basic pieces of information on which to draw. We learned too that teams are very eager to bring new capabilities into Spotify for Artists. In terms of data visualizations, they wanted to add the ability to have custom views, filtering, slicing and dicing, comparisons perhaps in the future. There was this whole world of possibility in terms of the ways that end users of the product could interact with the data that we were also limited based on our data warehousing solution. We wanted to open up those possibilities. Okay, so now we have some product requirements. We have something we can measure a solution against and we can start to revise our initial problem and solution statements to be a little bit more accurate. So the problem was really much more that the way that we develop with data isn't going to scale for the next generation of features and users. The solution that we were implementing was to design and implement a music consumption data platform that will enable teams building insights and analytics to make their data focused features interactive. As well as content and permissions enabled. This is the start of a classic product requirements document. We have a team of data engineers now and SREs who are gonna go out and build this new solution to who are now empowered with a clear understanding of what the goals are and what they need to achieve. So you might ask, great, now is the PM's job over? Absolutely not. Now we've gotta figure out how to implement it. We can't just tell everyone who is using the current data warehousing solution to stop what they're building and wait until we finish implementing our new data warehouse. We need a go to market plan. We need some pilot testers. We need some beta users after that. We need to phase out how we're developing. So all along the way, we also need to know how is this working? Is it doing what we need it to do? We need to measure the success of the platform. So one way to do that is to see how we start to increase the velocity of our customer teams. So all the while we're building out our platform from MVP to beta and beyond. We're adding features and increasing reliability and the performance along the way. So we're phasing things as well. We didn't build maximally. We shipped iteratively in slices, learning along the way. What does that actually look like in terms of how it impacted our customers? Well, maybe it took 12 months to get to that first delivery. It maybe put back the delivery timeline for that first feature by about six months. But within a few months after that, we're launching the next batch of features on the same platform repurposing the same data platform. And then we're getting to this cadence where we see customer shipping more frequently leveraging that data platform once every month, for instance. So what we see is that, yes, it costs us on our short term but deliverable, put back that initial timeline by about six months, but it made all the subsequent launches possible and it sped up customers as we get further along in this timeline. So those are a couple of reasons why you do very much need a PM to manage your platform. And it is a realization that a lot of businesses and teams generally come to pretty late. If you were to summarize why it's important for platforms to have PMs, it's just pretty straightforward. You have to center your user. It starts with even just using the right language to frame the thinking. We call our internal teams who rely on our platform to ship their features customers. When we add enhancements to our system, those are features. We consider evangelizing our offerings, product marketing, even just internally with like Slack and newsletters and stuff. And when we think about ways that we work together with our customers, other internal teams, we have a couple of different models. We call it partnership sometimes when there's a very close collaboration, we call it consultancy. Almost as though we're an agency internally within the company that serves other teams. So the takeaways that I want you to end with today are that platform products are really about integrating long-term thinking to reach your medium and long-term goals. So they're not about getting you to the zero to one. They may not even speed you up. They may slow you down in the zero to one phase, but they are absolutely crucial in the one to infinity phase. The other thing to take away here is that platforms are products and good platform PMs know and understand and care about their users. So what a PM does for the platform is really center the user. That's where everything begins and ends. Strategies, visions, roadmaps, launch plans, tracking success, communicating your impact. You can't do any of that until you understand your users and center their needs. PMs are uniquely good at translating that knowledge into intuition and action. And that's why they're so important to platforms. And last but not least, if you love long-term and architectural thinking, you should consider a career in platform product management. Platform was unexpectedly perfect for me personally, despite the fact that I don't have a tech background. I think that is probably because I'm not that interested in short-term optimization. I can't get that motivated by just trying to increase MAUs or break a quarterly sales record. Those things are very necessary. They're just not for me. Somebody needs to think about them and zero to one is really fun. But platform is the home for me because I like making study progress towards a big vision. And there's a lot of ways that you can be surprised all along the way there. So thanks for listening today. I would love questions, thoughts and anything else you might have to say and you can find me on LinkedIn. Thanks again for listening.