 All right. Did you know that just as there are things as immutable laws of physics and laws of thermodynamics, there are fundamental laws of software development? The first law is this. You never have enough resources ever. OK, so let's test this out. By a show of hands, how many of you feel you have enough engineers, designers, product managers, data analysts, program managers to do everything that customers are asking for, sales is asking for, execs are asking for. Anyone? Show of hands. OK, I see one hand. No? OK, zero hands. I would argue that in addition to all the things that you're learning here, and of course, ruthless prioritization, delivering efficiently and effectively with the scarce resources you have available is dependent, especially in today's day and age, on a performant, reliable, scalable platform and infrastructure foundation. OK, one more quiz. By a show of hands, how many of you have been blocked by a back-end team or a platform team blocked or delayed by a back-end team, infrastructure team, platform team? My goodness, the hands are coming. OK, OK, settle down, settle down. Hands down. OK, there must be a better way. OK, in this session, I'm going to talk about how product managers can play an important role in driving competitive advantage via extensible and scalable platforms. In fact, today we live in a world where competitive advantage is dependent on our ability to execute quickly and at scale. This means not only launching features with speed, but also scaling quickly and efficiently once we find something that sticks. And we need to be able to experiment quickly, even spinning up new business lines adjacent to our core strategy. This all requires infrastructure and platforms that can anticipate needs and is always one step ahead of the game. OK, a little bit about me before we begin. I've spent the majority of my career leading product management on platform and infrastructure teams. At Vimeo, where I'm at today, I am the product lead for the product platform product area. This includes payments, trust and safety, accounts, and permissions. Previously, I was on Amazon for almost 12 years on a variety of teams, including AWS billing, Amazon advertising, and Audible. And that picture in the background is of me touring a farm back when I was with Amazon Fresh. OK, so what exactly do we mean by platform and infrastructure? Is this just back end services? So we can broadly group platform and infrastructure into three sometimes overlapping buckets. The first are platforms on which other engineers build stuff. So one model has you have multiple feature teams building on top of services from a central platform team. At Audible, for example, we had core engineering organized with a team owning the services that powered the audiobook player. We had a team owning services that powered the library, and so on and so forth. And then we also had a number of teams building on top of those services. So for example, we had an iOS team, we had an Android team, and we even had new business models like Audible Originals that would build all on top of those services. So the key here is each of these what I call feature teams, they don't each of those teams, they don't have to reinvent the playback wheel each time. They simply depended on our centralized set of playback services. The second bucket includes payments that fully owned end-to-end components of the customer experience, like payments. So this is what my team owns at Vimeo today. We own certain customer experiences such as the checkout page, in addition to overall payments performance and payments fraud and chargeback management. But we also work closely with peers on the modernization team and the growth team as they dream up ways to cater to customers with solutions that they own, but are built on top of our transactions infrastructure. And the final bucket are platforms that either are or can become part of a company's offerings. I think AWS is the best example of this. So years ago, Amazon built cloud technology on which they built their e-commerce website. So this, they eventually turned into a business that we all know today as AWS. So I think this answers the question, does platform and infrastructure, are we just talking about back-end? And the answer is no. OK, platform and infrastructure teams frequently do not have dedicated product managers. So I'm arguing that this is a mistake. The key here is that product managers, engineers, engineering managers, by definition they have different skills and strengths that contribute to the output of the team. So teams without product managers would have engineers and engineering managers doing things like establishing business cases, mediating conflicts among stakeholders, internally selling infrastructure projects, or aligning efforts with company business objectives like OKRs. Product managers are frequently better positioned to handle these and other tasks more efficiently than engineers and engineering managers, just as an engineer and engineering manager is better positioned to come up with a technical architecture design, for example. All right, so on this slide, I'm going to do a quick recap of product management. And I'm going to call out differences between product management for a feature team and product management for an infrastructure and platform team. So first, product management for customer facing products and features. So as a product manager on those teams, you'll do things like understanding your customer, developing a product vision, building out a roadmap, delivering results, delivering solutions. OK, product management for platforms and infrastructure. So you do things like understanding your customer, developing a product vision, building out a roadmap, and delivering solutions. It's the same. So you start with your customer and you work backwards from there. So one of the biggest myths out there is that infrastructure and platform teams do not have customers or that they are not customer facing. So this is false. Your direct customers could be engineers, developers, product managers, but the premise is the same. You would still talk to them about their needs and then distill into a product strategy that drives the most value for the business. So it's very important when you're having these conversations that you also develop a point of view on the end customer or end user for the ultimate end customer, end user for your company. In many ways, understanding your customer and problems they are trying to solve is easier on platform teams. You just walk over and talk to them directly. And they mostly speak the same jargon and in ways you would understand as you're all part of the same company. So I want to emphasize just how important it will be to establish a strong and coherent product vision on these platform teams. So there's a tendency on these teams to just take orders and respond to requests as they come in. So you don't want to do that. So if you can imagine a sales led organization or product and engineering is scrambling to meet each and every request that comes in for any sales lead or prospect and the teams will just scramble to get that stuff done, no matter how much it diverts from an overall vision or product direction. So you end up with a hot mess with one customization for one customer and another customization for another customer and so on. So this is the difference between building and maintaining a whole bunch of custom software implementations, which you don't want, or building once and selling the same product many times over. So this is where you want to be. So let's talk about what makes an exceptional product manager on these platform and infrastructure teams. So the second myth is that you need to know how to code in order to be a product manager on these teams. The truth is that while it's helpful, it's not necessary. So I myself do not know how to code. The most important thing is to have what's called system level thinking. This is important on feature teams as well, but I would argue it's more important on these teams. So system level thinking is a way of making sense of complexity by looking at it in terms of holes and relationships rather than splitting it down into parts. Other qualities that make a product manager good on feature teams also make for good product managers here. This includes things like communication skills, analytics, tenacity, stakeholder management, and so on. So in many instances, you could be the first product manager on a team. So you must focus on building trust initially before you can tackle things like product vision and strategy. So don't go in with the I am product manager hear me roar approach. It doesn't work. So there are a few ways to build trust. Focus on quick wins, leverage your strengths, take on things no one else wants to do. You can also work on things like a project intake process, backlog management, and so on. So I'd like to share an example when I first joined a platform team a few years ago. So the engineers on this particular team, they had been wanting to do this piece of tech that work for a very long time. So they had called it the resource type consolidation project, because that's what it was. And it kept getting deprioritized. So around the time that I joined the team, I happened to be part of conversations where we were noting customer complaints about the lag time between when a purchase was made and when a piece of content appeared in a customer's library. So I realized there was a connection here. So I renamed the project. So I added one or two things to this particular piece of tech that work. I renamed it microsecond fulfillment. And the inside joke was that I didn't specify the number of microseconds. Anyway, it got approved in the very next review meeting. And the engineering team was very appreciative that we finally, finally, finally, finally was able to get this piece of tech that work to bed. And that started me on the path of gaining their trust and taking on more and more on this particular team. So here are the results. You improve productivity on a team as the engineers are spending more time coding and less time in meetings. And the important one is that you're driving higher return on investment for your company as the team works on the most impactful initiatives rather than only the ones coming from the loudest voices. So in another example, I joined a team inundated with inbound dependency requests from across feature teams. There was no way to get everything done. And we had zero capacity to also work on pressing infrastructure improvement projects we desperately needed to do. Operational load was high, ticket load was high, no one was happy, we were seeing high burnout, and so on. So I developed a project intake process whereby incomplete requests to our team would be politely and nicely rejected and redirected back to the requester for more information. So for example, I have instances where the requesting team would simply send over a one line request to our team, which was a link to their overall product page. And so the expectation was that we would wade through all of that documentation to decipher the one change that was needed on this one service that we owned. So there's no semblance of business impact communicated and the team prior to the introduction of product managers had historically just dropped what they were doing to handle the next urgent request. So the first quarter that our intake process was in place, we had sent back so many requests as being incomplete that we were able to actually handle all of the critical priorities and do some of the things that we wanted to do as well in terms of paying down tech debt. The key lesson here is that sometimes a feature team would send us a request for a half baked idea that they were just exploring and they sometimes even end up abandoning by focusing on just the fully fleshed out and defined work. We avoided wasting time on projects that were only in the initial idea phase. That made us far more efficient. And once we got things moving, we noticed the blocked by platform or delayed by platform. We started to not hear that as often in other team status updates. So that's a good thing. Okay, so the final point I wanna make here is that product managing a platform and infrastructure team can be rewarding on so many levels. So while working on customer facing products can be fun and interesting and solving problems for the end customer, you want to be aware of the dark side where you find yourself trying to eke out basis points of signups or purchases in fighting the temptation and the pressure to hide actions or to steer customers to places they may not really wanna go. So working on platform teams is tough, but it's highly rewarding and it's a lot of fun. So you work with some of the smartest engineers on the planet working on difficult engineering problems. So you could literally be solving problems that haven't been solved before. Like when I was on AWS billing, our metering systems were hitting up against the limits of available technology. So we were solving computer science problems of the highest order. It's kind of a unique skill set, skill set combination. So you've got the product management skills such as analytics, communication, stakeholder management, but you also need the system level thinking and technical aptitude. So it's a valued skill set as well that can pay better. So for example, at Amazon, there are actually three flavors of product managers. There's a generic product manager, there's product managers technical and there's product managers technical external services. So if you go to the Amazon job board, they've started posting the base salary ranges and for just a generic senior product manager, base pay ranges up to $206,000. Senior product managers technical, the base pay is up to $235,000 and I couldn't find any openings for senior product managers technical external services but they pay more. Okay, so in summary, there are four main takeaways from this session. The first one is infrastructure and platform engineering is more and more important in this competitive world. The second is product managers can play an important role in making these teams as effective as possible. Third, great product managers on feature teams would make great managers, product managers on infrastructure and platform engineering teams. Classic product management principles apply to both. Start with the customer and work backwards from there. And fourth, if there's anything to take away from this session, it's this last one. Don't just be an order taker, develop and drive a compelling vision and strategy. Okay, thank you.