 All right, let's get started. Thank you all for joining today. This talk is about the internal platform product manager. This is a type of PM that is really gaining a lot in popularity across tech companies, a PM that's building platforms or internal products for your company's internal users. Now, let's learn more about why this is such an in-demand goal at the moment. My name is Lambrus. I am a PM working at Weiss in London in Platform. I've been working in the Platform as a product space, let's say, for the last five or six years in Seattle and the US before, and I'm from Germany originally. So yeah, happy to be here today. Let's dig into it. First topic is what actually is an internal platform. So if we want to learn more about the role, we have to understand the products first. Secondly, we want to understand why we need a PM for internal platforms. Spoiler that not every company actually has a PM on those platform products. And lastly, we look at what it takes to be successful in this role. Now, for this last point, I actually interviewed about 16 platform PMs in the industry and asked them for the experience. All right, starting with the first point. Now, what is an internal platform? So when I say platform in this talk, what I mean is this and this and this, and you get the point. There are various kinds of internal platforms. I would say some of those terms on here are probably synonyms. Some are a bit more distinct. Now, what do they all have in common? Well, in common is the user. All of those platforms are built for the internal user, typically that gets your company's engineers. And those engineers have the job to generate value for your end customers. So the engineers, they are building features, evolving your product, running your product, and so on, and generating value for your customers. Now, in today's worlds, there's actually a lot on the engineers plate. If you know the DevOps model especially, engineers have a lot to do. They have to plan their work. They have to implement features, code. They have to test, release. They have to maintain, remove security issues. They are 24-7 on call. Have to make sure it's always running and healthy. That's a lot that they have to take care of. Besides this, you also have more and more complexity coming from the ecosystem and more and more pressure from the business and from end customers. So you have pressure to reduce time to market. We have to get our features fast, learn quickly. We also have to build highly available products. So you cannot be unavailable. If you're Amazon or Facebook, it has to be always available. You also have to have highly-performant products. So you're talking about milliseconds of response and not multiple seconds. You also have to be very aware of regulations, compliance, security risks that you have to own as engineers. And lastly, you have to do all of this, being very mindful about costs and not waste money, and have to build the product in a scalable way so costs don't explode if you generate one more traffic and one more customers. Now, you don't have only one engineer. You typically have hundreds, maybe 1,000 engineers. You have maybe hundreds of engineering teams in your company. And all of those teams have to do all of those tasks. And they have to do all of this while meeting all of those requirements that we mentioned earlier. Now, let us all log to take care of. Now, internal platforms really have been built as a response to that. Platform products are providing value to the internal users. So they're helping the internal users generate value faster. And they have been built to abstract away complexity and make jobs to be done for the engineers much easier. So we're not saying that we are going to plan or code on test for the engineers. This is still their job. But we are providing all of those as internal capabilities or products and making this much easier. So we're providing testing as a product, releasing as a product, and so on. And they can then use this to get their job done faster and generate value faster. Now, if I talk about customers in here, what I mean as a platform PM is the internal users, typically the engineers. The product is the internal platform. And the outcome is, yes, it's going to be revenue and so on of the company, ultimately. But that's more secondary. The immediate outcome that we care about is time to market, availability, performance, and so on. Risk, cost. We're trying to help engineers to achieve all of this. And we're trying to enable them. There's also one more thing that's important is that we try to provide a great developer experience to our engineers, the internal customers. This is not just a nice to have in these days. Well, you have to have a great experience for developers. Otherwise, you won't keep the best people. And yeah, you're going to lose talent. That is also a massive trend right now in the industry. So this is a product talk, not platform talk. So but I have to go kind of one step further here. Now, this is how platforms typically look when you kind of look a bit more internally into how they're built, right? So typically what you have is that your products, your company's product, right, is running somewhere, typically in the clouds, Amazon, or Google, or whatever. And the cloud provider provides the fundamental storage, compute, networking, and so on to run your application. Now, typically what you have as the first layer of internal platform team are core infrastructure or foundational platform teams. Now, those teams provide the cloud providers, if you want those services in a very tailored way towards your customers, the company's needs, right? So they provide access management, governance, maybe Terraform scripts to generate resources in the cloud. And they also ask questions like, do we have to have a center in Ireland, Frankfurt, and so on based on your company's needs? Now, on top of this, you're gonna have platform teams that are more developer enabling and helping much more with the day-to-day work of developers. So here may be things like delivery tooling, how do developers get a change out from local machine to production, right? Might be things like reliability engineering, how do we help engineers to build, rely on the services? And you also have things like data platforms, data products, machine learning, analytics, and so on, helping teams to build models, monitor models, and so on. Now, all of those platforms are provided as a compelling internal product to our engineers, data scientists, analysts, and so on. We are services, tools, knowledge, support, and so on. Okay, now why do you care about this? Well, it turns out that what we mentioned earlier, like time to market, liability, and so on. Now, those are all very important properties to have today in today's time as a company. And investing in those capabilities, such as delivery of software, operational performance, and so on generates a competitive advantage for your company. So Gartner, here's a quote, says that, well, most companies are going to establish a platform team or internal platform by 26, let's say here. And there's a nice read here, state of DevOps report where they explain how those capabilities that we mentioned earlier help your company be more successful. So there's strong correlation between software performance and reliability, and so on, and your company's success. All right, so now we know what the platform is, what the product is. Now, why a PM for it? Well, maybe a third of what works before, that's a company that works with many other companies and tries to help them, give guidance, consult them, and so on, and they publish a tech radar, I think twice a year or so, where they share with us what they have seen working at other companies and what they recommend us to look at, adopt, trial, assess, and so on. Now, this is the one from April 23, and the number one thing they tell you to adopt is applying product management to internal platforms. Okay, so this is working as model and a lot of companies out there. But we don't want to just listen to fireworks, we also want to think for ourselves a little bit, right? So if you think about an internal platform, what you have is a product that we provide to customers to achieve an outcome, right? If you're a PM, that should sound familiar to you, right? There is, of course, a few differences here to traditional PM, let's say, right? So your customers are your colleagues. So they're internal users. You have also a captive customer base. Well, they can't go anywhere. There's no expansion or anything like that, right? And lastly, customers typically are also engineers and they have some opinions about the product themselves and how you should build it and so on. Now, the product, the platform itself can be a bit hard to define. If you think about the engineer's job to deliver features, now this may include multiple tools in the developer journey, right? Now what's the product? It's the product, the tool, it's the product, the journey. So it's not as obvious. Also, those internal platforms are not always optional to use. Sometimes they have to be used, right? If there's only, let's say, if there's Kubernetes, for instance, well, it might not be reasonable to use something else. So if it's not optional, then is it still a product? That's the question, right? And they're also often emission critical, meaning that, well, if the foundational layers are not available, your whole company will stop working, really. Now the outcome here is, of course, much more indirect. Ask yourself, if we improve our developer experience and what's the impact of this on revenue? If we improve developer happiness, how will this help us generate more revenue? It is not as easy to link this together. It's also hard to quantify platform outcome in financial measures. And you also have a delayed return that means that you invest in infrastructure or tooling, but you have to get adoption first and so on before you see a real return of that. But if you think about the, if you are building an internal platform, what are some things you may wanna ask yourself? We saw earlier that this is a massive competitive advantage. If you don't invest in internal platforms, you're risking to fall back with time to market, with reliability, really with your end customers' expectations, and you really have to invest to stay competitive. That means that is an important thing to think about, right? So if you're building the internal platform, you may wanna understand, well, how do we know that what we are building is actually having an impact? How do we know that, right? Also, how do we know that our customers, the engineers are actually productive and what we're building is usable and they're happy, right? Typically, you also have, as always, right? You have more ideas than you have time. So the question might be, so what should we build first? Should we invest in reliability or in delivery speed? Not obvious, this question, right? This answer. Also, you may wanna ask yourself, how can we as platform teams best support our company's mission or strategy at this current point in time, right? Also, how are we doing? Are we having a good product? Are we having great tools, right? What are others doing out there? Now, all of those questions are really product questions. I'm not saying that, well, this can't be answered by engineers or leaders, but to answer those questions, now, this is really a full-time job and probably it's a full-time job, the platform team. So you might as well have a PM, right? That has methods, frameworks in place to answer those questions really structured and scientifically. Now, what are some insights in KPIs that we look at as platform PMs or platform as a product? Well, I said earlier, right? Time to market, delivery speed and so on. So one of the big outcomes for us is our engineering productivity. How fast can we onboard new engineers? How fast can we deliver new features? How happy our developers, right? So we rely a lot on surveys, interviews, and so on to generate insights and then make improvements. Stability, risk, cost, all different kinds of KPIs we look at. There's a nice book post here you can read that tells you a bit more about how wise is doing this. So lastly, let's look at if you are a platform PM or want to become one, right? What it takes to be a good PM and to succeed in this role. So for this last point, as I said earlier, I talked to 16 platform PMs in the industry from the US, Europe, UK, and so on, Spotify, Wise, BBC, Just Eat and so on, a lot of companies. And I asked them three questions. Well, what do you think makes this job challenging? Maybe different than another PM role. What do you like most about it? What do you enjoy most? And what does it take to succeed? Now what's the ideal person for this role? So starting with the challenges. Now this was probably the single most point that kind of was brought up in interviews. One of your biggest challenges as a PM is to measure the impact of your work. It is not obvious how to measure impact and product success. Defining KPIs for things like Kubernetes or Terraform or even like delivery tooling like CI CD and so on. It is not an obvious thing to do. So that's a big challenge in our domain. It's also hard to quantify whatever we do in platform in financial terms, in pounds. How do you translate develop experience into pounds? That is not straightforward. And lastly, a lot of your work will be explaining platform value to non-technical stakeholders. So you have to constantly be mindful that a lot of people in the company won't understand what you're really doing. So you have to invest a lot and explaining the value and make the business case for platform investments. All right, second point mentioned was kind of being a bit isolated and lack of support. So I said earlier, this is kind of an emerging role. It's becoming very popular in the industry at the moment but there are a lot of things that we don't know about it yet. It's a bit of uncharted crown. So as a PM in this role, you have to explore a lot yourself. Now, what are PM methods I can use? How about user research? What makes engineers different as customers? So a lot of things that we haven't figured out yet, right? So you're a lot on your own you have to figure out and pave the path. You also have to work a lot on creating trust for the PM role. A lot of platform teams that you work with, you might be their first PM, right? So you know what a PM is and they may also be critical about the role. You also have to do a lot of evangelizing around product thinking within platform teams to get that mindset out there, discovery, user research, question assumptions and so on, right? You don't typically have a lot of supporting functions as a PM in platform. So typically what you have in PM roles is UX, design, research, analytics and so on, right? If you're a PM platform, you don't have that, right? You typically have to be full stack. So you have to design yourself, you have to do interviews, research, analytics. It's a lot that you have on your plate as a platform PM. You also have a lack of data to understand your customers behavior. That means that we don't have kind of nice funnels that we can use or understand how engineers are, you don't wanna be the big brother, right? So you rely a lot on interviews and surveys to get your insights. And lastly, it can feel a bit disconnected from the product work because even a lot of PMs don't know what you're doing. It's platform PM, right? So you have to approach them in a way. You have to explain them what the PM does in this role and yeah. So on this last point actually, it's interesting that I asked those 16 platform PMs, tell me your reporting line. Do you report into the CTO or the CPO? Well, it turns out that most platform PMs report into the CTO, right? So it is very much rolled in between the two worlds. You are a PM, but you're very engineering focused. Last challenge that was brought up or the last biggest one, the top three here only, right? Is it is a technical domain, right? And it is really difficult to understand your products and your users. We're talking about like building a highly available system, you know, database systems. It is about like service mesh. It is a lot of things that are technical and you have to understand it's a very steep learning curve. Also your engineers are your customers, technical user base. It is very difficult to keep up with the ecosystem. So here you have a picture of the cloud native landscape zooming in on databases only, right? Now all of those are infrastructure, tools, and so on that you can use in your company as part of your internal platform offering. But how do you know which of them is relevant for you, right? You have to really keep up with the industry which is incredibly difficult because a lot is changing in the ecosystem. And you are not an expert of your own product. Now that sounds a bit stupid, but it is actually true, right? You have to accept in a way that your platform engineers that you work with and your engineers, your customers may know your products and how it works internally better than you, right? You bring much more the insights and user interviews, quantifying impact, thinking about sizing and so on to the table. And lastly, you have a lot of context switching in this role. You, this is actually a nice bit of, I guess, an insider joke. You have Dora. Dora stands for multiple things these days. It stands for Dora metrics, DevOps research assessment metrics, such as mentioned earlier the KPIs like lead time, time to come back from incidents and so on. Those are very engineering focused metrics, but you also have Dora, meaning operational resilience act, right? So compliance regulation that we have to comply to show that we are resilient. Now you as platform PM have to understand both. You have to understand engineers and their metrics and compliance risk regulations. So it is an incredibly broad scope that you have to take care of. So now the happy side of things. What do people enjoy most about the role? What do you like about this? The number one thing mentioned here was autonomy and freedom. So because you're a bit decoupled from the David customer company, you know, revenue, you have almost no direction from the overall company strategy, right? So you can really figure out everything yourself. You have a lot of freedom and autonomy to define your strategy, vision, objectives and figure out how to shape those so you achieve the company's mission. You also have a lot more freedom to think longterm. So typically in platform, we don't think quarterly, right? We think about year, two year, three year, five year horizon. How can we enable our company's growth? What's coming up? What are the big trends in the industry, right? So much more freedom there as well. And there's less scrutiny on go-to-market. Now obviously if you're delivering products for internal users, well, legal marketing might not care about this that much, right? So you have much more freedom to kind of try out things and release stuff. And yeah, this one also a big benefit is you have your customers sitting next to you visually in the office, right? So the customer proximity was a big benefit that was brought up from interviews. People really liked that. There was one quote here from somebody who said, you can do as much research as you have capacity. I think that's really much, very much true. And you can also feel your impact. So if you improve developers' lives can literally see their smile, right? You can literally see them being happier or thank you for it in the office. I think it's actually really nice. And your customers are the engineers. That means that typically your customers are very smart. They're really great to work with and people love that about the job. And lastly, you have this really broad set of stakeholders. So you would platform PM talk to, head of risk, CISO, CTO, CPO. So you have a really, really wide set of people you interact with in the company because you have such a foundational offering. And lastly, people also like this a lot about the job. It is its novelty and also the difficulty really comes with the job, right? And people will be like that you understand how things work under the hood. The US platform PM really understand how your product is built from the crawled up, right? From infrastructure to architecture and so on, right? So the whole picture, you understand how it works. Also, you have to constantly learn new things. You said earlier, right? There was the cloud-based landscape. So you have to learn about knowledge, ecosystem but also what compliance, risk. So it's a challenge, but it's also really, really rewarding to just stay in touch and keep on top of all those changes that are happening right now. This was also put up as a challenge, but it's also people also really like this part, the uncharted grounds, right? So a lot is yet to be figured out as platform PM, quantifying impact, right? Researching and so on, comparing companies, a lot of things we don't know about yet and we have to explore ourselves. And lastly, yes, it is complex, but if you understand it, you're gonna have a massive impact, right? So you can use technology and have a huge compounding effect. If you can just save, let's say, five minutes per developer per week, if you do the math over here, you're gonna have a massive impact and help the company, right? Accelerate their roadmap, for instance. All right, and then lastly, summarize more or less what it takes in this talk. Something I get often asked in this role is do you have to be technical? Typically, I would say that platform PMs have that title, technical PM. So I asked those 16 people that I interviewed about their background and well, turns out that actually most of them said no, technical background, some said a third said, kind of ish and a third said yes. So I would say that to get the job, not a requirement, but you have to, of course, on the job be willing and be motivated to learn about, you know, technology and upscale and learn very fast about your product. So summarizing it, what does it take? Well, you have to have an intrinsic motivation, right? In this job, you have to really love what you're doing without getting constant feedback and rewards, right? I think somebody said here, you can't always be a striker. You have to be really curious about the tank and how things work internally. And you have to be a strong storyteller and communicator. So you have to understand the business and engineering, translate engineering problems and impact into business and the other way around, right? You have to love to work with engineers, your customers and love learning new things all the time. And lastly, you have to be re-humble and have to have a thick skin. I can confirm that one, right? It can be tough in the role, a platform, PM is a new role, people don't maybe know the PM value needs of evangelizing. So you might get setbacks and so on, you have to be really, you know, you have to have a thick skin and be humble as a PM in that form. I think someone from the people I talked to said this, it is really for a PM that wants a challenge. Okay, that's it. Thank you so much for being here. I wanna thank the people that talked to me to prepare for this talk. Thank you so much for making the time. And yeah, if you want to find me on LinkedIn, here's my profile, happy to connect. Thank you so much.