 Hello, everyone. How are we feeling after lunch? Do we have energy? Do we need to stand up, do a little dance? Anything? OK, I'll just get started then. So Kristen's talk was an amazing lead up to this talk, I think, because we share the same love of user centricity and product thinking. And that is what I'm going to be talking to you all today. I'm really excited to be here in Paris. I'm going to be operating my slides, so I need to do that. Oh, you know what? It's fine. I will be behind here. It's all good. Yeah, yeah, it's fine. OK, so my name's Samantha Kaufman, and I am a senior product manager for Spotify Plugins for Backstage. I've been at Spotify for about two years before Spotify was at Hello Fresh doing the same thing, platform product engineering. And I am very passionate about empowering platform product teams. Raise your hand if you've read the book Empowered by Marty Kagan. Oh, lovely. You guys are going to love this talk, the people that raise their hands. So I'm all about empowering the platform product team to work like a truly empowered product team. So questions, if you're in my team, that you might hear me say often, see my EM in the audience. So he's heard this question many times. That's an interesting idea, but what problem does it solve? OK, but what about the customer? So these are questions I'm obsessed with, and you'll learn more about what empowered platform product means. So what you can expect from this talk, like I said, I'll talk about what a platform product is. Generally, you all know this very well, I'm sure. I'll talk about the nuance of it at Spotify and how we think about platform product. And then I will go into where I think product fits and dispel basically some myths I've seen working on the backstage product, talking to our adopters, dispel some myths about what platform product really means in practice, and then share some best practices that I've seen work at both HelloFresh and Spotify. So I'm sure everyone's seen this book, Team Topologies, and it's basically showing you how you can organize for Team Flow, and it introduced this concept of platform product. And I love the definition of a platform as a curated experience for engineers, the customers of the platform. I think this really helped give us platform product people at the time, like, yes, like a voice, this is a thing. And really excited because platform was truly being treated as a product, and engineers started to be treated as real customers of that product. So this is the definition I like to orient myself to. But at Spotify, and you'll see at your own companies, as you start to scale platform product, the users get a bit more complicated, and the context they exist in get a bit more complicated, and they have very specific needs, wants, motivations. So in this example, we have an end user experience for many of our apps that we support and products that we support. So the feature engineering teams are working on Spotify for artists, or they're working on Spotify mobile apps or podcasting tools. Then you have in blue the layer, the developer experience layer, which is where backstage sits. You have the product that's helping these feature engineering teams be more productive, get time to market down, like, deliver value to our end customers. But then even deeper than that, you can also have core info developer experience, which we do have at Spotify. We have a team focused on the core info developer experience. So as you scale out your company, you need to think about who you're solving for, what contacts they're actually in, and what's motivating them. So what teams are they building for? And I'll get into this a bit more just to show that this can definitely get more complicated as you scale. So I'm just gonna share what I've seen from my interviews with adopters of backstage and what I've seen not work when they've adopted platform as a product mindset. And I want you to just clear your minds and imagine that everything I tell you today is very much going to be a shift in mindset. And I really believe that platform as a product mindset will really help supercharge your teams to reaching the desired outcomes. So stay with me as I take you along this journey because I really believe that this is going to be a major shift in how you attack your developer portals in your internal products. So you can see Bowie here. Who knows Bowie? Who knows backstage? All the hands should be up, okay? So maybe your team says, okay, we've found the need to adopt an IDP. And so you've adopted the IDP. Hopefully you've chosen backstage. However, you're finding in your teams that there's this massive mountain to climb. You have all these outcomes that your boss is like, we need to standardize software. We need to maintain clear ownership of software. We need to increase collaboration. And your team is like, how do I climb this mountain? I have no idea. What do I do next? And this is where product centricity can really help you because product centricity is all about orienting around the desired outcomes and building iterative continuous value to reach these outcomes. And ThoughtWorks agrees they published in their tech radar in 2023 that they're seeing team structures orient themselves around this thinking of, okay, we have a PM, we have an EM, we even have user research involved in this platform product team. But they saw that you also need to apply product centric working practices within the team. It's not enough to just hire the PM and say, okay, go prioritize the backlog. You also need to introduce the product centricity within the entire team. So to wrap it all up, product centricity ensures successful outcomes by looking at the value of what problems you're solving, what outcomes are you trying to achieve, and the viability. Who are your customers? Will they use it? How will you get it to them? I say go to market strategy internally because I truly believe that you want to convince your buyer whoever that is inside the company. Maybe it's an EM that incentivizes their engineers to try something. Thinking about this go to market strategy can seem kind of weird because you're like, I'm inside my company, but it's so valuable to think about how will we market this to them? So this type of product centricity thinking is what I'm advocating for. So now to dispel some myths and share some best practices. So the first myth, and this one might be controversial. So I'm open to questions at the end, but the first thing I hear a lot is that product's job in a team, in a platform product team is to prioritize solutions or features. So what doesn't work about this, of this way of thinking about it, is you might have a customer interview and Kristen actually said this perfectly in her talk and someone says, gives the feedback, I really want to try this new technology and you've talked to your customer, they've given you that feedback. But the problem is you've already jumped into solution mode. So you haven't really oriented yourself around the problem that's happening. Either the problem could be happening in one part of the customer journey and you've completely missed that. What I see a lot with adopter organizations that we talk to is they jump into solution mode too quickly. And I'm advocating that you step back and really orient yourself around the problem that's happening before jumping into solution mode. So to dispel the myth, an empower platform product person works together with engineering and design to solve customer problems. And in Empowered, I'm highly recommend this book if you're interested in just the product craft in general. The ideal product person that's working in an empowered way is sitting between user experience, tech and the business needs. And they're thinking about the intersection of all of those. And so what I'm advocating for is that an empowered platform product team could look something like this. So the customer sits at the center of everything that you're all doing together. You're all talking to customers. You're all understanding what context they're in. What is the true consequence of the complaint they're making? Like, oh, they're spending 10 hours in meetings a week just based on incidents. Okay, well that's a complaint. That's a problem or that's a complaint. But how do we translate that into a problem? So asking those types of questions like what is the impact to the business of this person being in meetings 10 hours a week because of an incident. That becomes a problem that you can actually rally the team around. So that's what product's doing. Engineering's looking at feasibility. Like, how can we feasibly solve this given our current landscape? Obviously engineers have such organic empathy for the problems that are being solved because they're also engineers. Design and research, I don't even need to explain this one because again, Kristen, I loved your talk. And she explained this perfectly why it's so valuable to understand where your solution is meeting the user. You cannot show up with a solution and be like, hey, let's shove this into their journey. You need to understand how to meet them where they already are, which is why this is, I think, the ideal, I guess, topology of working as an empowered product team. And then one thing I really like to think about too is just deploying empathy and the nuance is you should be talking to your customers often. Everyone in the team should be talking to customers and understanding the challenges. But you should be listening in those customer calls and then thinking later about what the opportunity is, not in the customer call jumping into solution mode. So in the same example with incidents, you might be listening to them talk about how they were pulled into a meeting. They actually weren't needed because they didn't own the service that went down and they just felt like they wasted two hours. That's a complaint that's very valid and the consequence of that could be maybe we're hindering productivity because our incidents have too big of a blast radius. That's an opportunity that you can tangibly solve in collaboration with design, research, and engineering, and you do that together. You think about those solutions together. So this is an improved journey to reaching the outcomes you're trying to achieve with an IDP. So you build iterative value continuously to reach the business outcome or the goal you're trying to achieve and these outcomes you're measuring along the way. So you might start with, okay, first thing we need to do, we need to standardize software development practices. Orient yourself around that problem and then build value on top of that. Okay, now that we've standardized software development practices, we wanna do this. We wanna do this. So you build the value iteratively and this is what I've seen adopter organizations be very successful with something like Backstage when they do it this way. Okay, myth number two, and I talked about this before, your customers will tell you what you should build, just ask them. Definitely talk to your customers, talk to them all the time, but what I see happen, and I mentioned this, is you get feedback. The way we handle incidents at this company is awful, we need a new solution. And if you're in that meeting, you might think, oh, we need to go rush and figure out what's on the market. What is the latest new thing that we can buy or build into our existing space that will help us solve incidents? Incidents isn't a problem, right? This isn't even a problem. Customers can tell you what's painful, but you as the PM or the team need to uncover the consequence of that pain point. So the problem could actually be, and fun fact, this is happening at Spotify, so this was analysis we did internally, that when an incident happens, engineers are disrupted and have to context switch, and devs involved in incidents spend 20% more time in ad hoc meetings. That's a tangible business problem that we can now go figure out how to solve, and what makes this really great is when you have the problem framed this way from the beginning, it makes measuring if you've reached the outcome so much easier, because you have the metric, you have success right here. Success might be, engineers are not spending 20% more time in meetings, we're only pinging the necessary people involved in an incident, and no more people, and no less, because we wanna resolve it, we want high quality, but we don't wanna disrupt people's day-to-day work, so it becomes very easy to then figure out, okay, what does success look like if we were to solve this problem? So this is my favorite problem statement framing. This is taken from design thinking, so I think about today when users want to do a desired activity, they have to do the current solution, this is unacceptable because of, and then you state the shortcomings of current solutions, and you might find that some problems that you think are problems are not actually problems, because it's suitable, and there's not actually a shortcoming to it, and maybe it's not worth solving, and then the second part, so the first part's the problem statement, the second part is we envision a world where shortcomings resolved, and we are bringing this world about through your high-level approach to your vision for how you'll solve that, and if you present this problem statement to the entire team, engineering, design, research, if that's being presented, it's so much easier to figure out what to do next, because you're all oriented around the same context, and you all have the same problem in your mind, and you can visualize it, you can feel it, you've been there, you have that empathy, you know what that situation feels like, it's frustrating, makes it a lot easier to figure out what to do next. I know you all know this, but this is a myth that all engineers, know the same and want the same thing. Again, I know you all know this, but what I mean in this context is that engineers have different contexts and incentives and needs, and the incentives one I find gets missed sometimes, so I talked about the with scale users and needs become more complex, but I also noticed that the incentives part is missed, so the end user, the engineer, maybe they get pinged during an incident when their team wasn't involved, or own any of the services they're actually down. Who's the buyer in this situation? So they have a job, they have a manager, their engineering manager is probably sharing with them, hey, we need to get this incident resolved, but we also don't want to too much disrupt the team. It's important to understand these incentives because it's going to motivate the engineer, and it's important to understand what motivates that person. And then the engineering manager, depending on the size of the organization, there might be a lead, a decision maker involved, or maybe it goes up to the CTO, and they care about other things, which is incentivizing the engineering manager. So this is this whole idea of deploying empathy, understanding the full context and the full picture, because then you're able to deliver your solution in a way that helps meet all the needs of the decision maker, who has to be bought into this decision to move to a new solution, the engineering manager who's the buyer who's going to be incentivizing the end user, hey, we need to do this, and then obviously the end user, you need to solve their problem. It has to work for them. That is everything. So I will take questions. I think I have some time. I think it was too fast. Ask me a million questions, please. I think I got a question. Cool. Any questions for Samantha? Oh, yeah. Hello, I had a question around when you're framing the IDP as a product, have you seen success in naming it, or like having a brand so that you can actually show that to the org? Do you have any thoughts on that, or if you should or shouldn't do it? Yeah, so I've seen, I mean, I can share personally at HelloFresh, we call it HelloDev, called it HelloDev. It's one example. I'm sure you've heard Expedia, Tom, correct me if I'm wrong here, but Runway, I think it was called. So I think there's a lot of value in branding your IDP. Like I mentioned before, you want to make sure that you have brand awareness around your product, like any product out in the market, and you want to ensure that people can rally around it, and it's still playful and fun. Branding, stickers, logos, all for that, yeah. So thanks for a very good presentation. My question is when you're talking about empowered product person in a team, do you mean only like product manager in the team or also every engineer and every other person of the team? And also continuing on that is how much should be engineers of the team involved in like this product work, understanding the problem, coming up with a solution, not only engineering and building things? Yeah, so I'll give you just a quick anecdote. I'm obviously out this week from my team, and I'm gonna be out next week, I'm traveling. I wouldn't be doing my job well if I left and all chaos ensued. So I think being an empowered, I just created a new word, in product. Empowered product person means that the whole team is rallied around the problem statement or the problem that we're solving, and has been in the customer calls with me or has watched the video and has the same empathy that I have. It's my job to articulate the value of solving that problem and help bring the problems to them and ensure the customer interviews are set up and we're talking to the right people. Is it the right problem to solve? Is it worth solving costs for its benefit of solving the problem? But by no means is the product person the only one that's, it's not like a throw over, hey, go solve this problem. Everyone should be involved, in my opinion, in the whole thing. One of the reasons why I say empowered product team sometimes is I recognize that not everyone has a product manager in their platform team. Like, that's okay. So the reason why I'm making this applicable as just an empowered platform product team is I believe anyone can be product centric. I don't think you just need a product title and anyone can do it. I've seen incredible adopter organizations where the staff engineer is acting as the product manager in the team and are doing an incredible job just advocating that it's a different hat and it's a different frame of mind when you approach the problems. So I think that we can all sort of apply the practices no matter what our job role is. But, yeah, I did that answer your question. Yeah. Any other questions for Samantha? Hello. Hello. Well, basically, first of all, a very nice speech. Thank you very much for sharing it. And my question is how has been the evolution of in the Spotify, you know, there are mainly different kind of offices that are focused on solving specific issues like DevOps, DevSecOps, SRE. Do you still manage these kind of concepts or are all of them now integrated in the platform engineering idea? Yeah, I think we, I would say, we're pretty far on the platform maturity journey of like moving towards thinking about platform as a product and Spotify, I would say I feel very lucky to work there right now because they've really adopted this product thinking in the platform teams where every surface that an engineer is working with is treated as a product, even if it's an IDE. So we are really thinking about it from how you would treat products externally. So for me, there's no difference, but I recognize that there's different levels of maturity on that journey and not everyone has gotten to that yet, which I don't know if this answers your question. So we don't have those specific type of team roles or teams oriented, it's really oriented around, like I mentioned, who is the user? Like what type of engineer are they? What are the problems they're solving? And it's more oriented around the problems than I guess like the tech stack or the discipline per se. Does that help? It does, thank you very much. Welcome. Thank you for the presentation, Bakul. I'm not sure how to frame it. To me, a platform is a set of components probably coming from different teams. How do you scale this product thinking to multiple teams within an organization to have a current user experience, current product basically that is built by multiple teams in parallel? How would you build the product thinking into the teams just to play it back to you? Yeah, and have a coherent result. And have a, sorry, repeat the last one. How can it be coherent? Like a coherent result, like an end-to-end experience. That's a good question. I'm not gonna lie to you, I don't have the answer. I think what I would do is I would, as much as possible, empower design to think, if you have a design function, to think about the end-to-end experience because it's one level that you have different solutions for every problem across the company. But then once you start talking about, okay, we want people to be able to work cross-functionally, like across those solutions, then you might just have 20 multiple solutions and they don't make sense together, right? So I would have a designer think across all of those domains and think about how can we bring these journeys together? Or if you want to, you could even orient yourself about around just jobs to be done and think about, okay, people need to write and test code. Rather thinking about it by the domain, what would the experience look like for every type of engineer we have at our company? So you orient yourself around the jobs to be done and you work really closely with designers and user researchers around how can we build an experience that works for everyone? Similar to what Christian mentioned, it's a big project because you have users that like every segment, early in career, new to the discipline, advanced in the discipline, early in the career, all the way to like super advanced, have really advanced use cases. So I think, I don't know if anyone solved this perfectly yet, like I think we're still, that's why I said I don't know the answer, but one way you could approach it is just by thinking, okay, we just want to focus on jobs to be done and we want to be disciplined and agnostic because we want to start from, we just want everyone to be able to do this one thing this way and we're gonna design it so well for every type of discipline, but that might mean you have to support like hundreds of use cases. So I'm not sure, I don't have the answer, but that's how I would think about it and then I would just as much as possible have a designer that's looking after the entire flow, like the entire user experience or I've worked with amazing service designers that can just like visualize the whole end to end flow and then you can see where there's bottlenecks or where there are friction points, even across domains, which is really valuable, but I also recognize that not every platform team has all these resources, so I want to make this approachable for everyone, but that's how I would think about it. Hope that's helpful. I think that a lot of platform teams, infrastructure teams, whatever label a lot of people use, have a very operations mindset on some engineers and if you are talking about being like product centric with engineering teams as a whole, not just product managers, how do you kind of break this operations mindset and like go into a product focused mindset? I think, I mean, like I said, I've been doing internal platform product for like four or five years now, so I've been in a lot of those meetings where I'm like, ooh, I'm not really welcome here and you have to build a lot of trust with the team and you have to show one that you really care about the problems that they're working on because I mean, I do, I really care about the space, but I think if you're trying to advocate for something that's a bit different, you need to meet people where they're at and how they're thinking about it. So I think like, again, this isn't the best answer, but it depends. I think it takes time. It depends who also your leadership is, like how do the leadership think about where I guess product fits and where how product centricity is thought of in platform teams. I think that matters. And also just building trust, slowly introducing these concepts. I think if there's a space in which you can showcase how it could be more impactful if you do it the more product centric way to actually showcase the results, that could be another way. I'm still learning. I don't know. I will let you know if I find a silver bullet, but like I've built a lot of trust over time. Even given these talks, I feel like, ah, is this still a thing? It's what I'm saying. This is, do I back this? So it's like, I'm not fully there yet. And I think most people in this space feel that that it's a process and it's like an adoption curve and there will be early adopters and laggards and you sort of just have to meet everyone where they're at because everyone's coming with the best intention. They want to build great products. They want to build great developer experiences. So everyone has the same goal at the end of the day. So just orient yourself around that mission that you all share. That's what I would do, I think. Is that helpful? Did I answer? Great, okay. Okay, thank you very much, Samantha. Give her a big round of applause.