S2 E7: Set up for Success with Stripe

[MUSIC] >> Hi. Welcome to season two of ProductOps podcast, or pop as I like to call it, with me, Jureisha Nadiraju. This season is focused on scaling product ops. I'll be talking to product ops teams at well known and fast growing tech companies across the world. We'll find out how they've set up their product ops teams for success and explore practical examples of value-adding work. Given that the product ops is a significant driver of product-led growth, I'm excited to once again partner on this podcast with the fantastic people at the product-led alliance. For the last episode of season two of pop, I'm absolutely thrilled to be joined by one of the pioneers of product ops in the industry, Blake Samic, as well as two members of his fantastic product ops team at Stripe, Alexandra Lipinski-Wolson and Dan Barber. Stripe is a financial infrastructure platform for businesses, millions of companies from the world's largest enterprises to the most ambitious startups use Stripe to accept payments, grow their revenue and accelerate new business opportunities. Headquartered in San Francisco and Dublin, the company aims to increase the GDP of the internet. On this episode, we find out how Stripe's product ops team is set up for success. Building on the learnings Blake had from setting up product ops at Uber, we unpack how the team is organized between embedded product ops and more centralized product ops programs. Dan and Alexandra deep dive on why the structure works so well with some great practical examples, including the Stripe Terminal Global Ranch and the top asks from users' program. Get ready for non-stop insights into how one of the best product ops teams in the industry accelerates Stripe's ability to deliver more value to more users. Blake, Alexandra Dan, welcome and thanks for joining us on the product ops podcast today. How are you all doing? Thank you for having us. Great. Nice to meet you, Dresha. Thanks. Excited to be here. Awesome. I am so excited for this episode. Blake, I think I read about product ops at Stripe. It was one of the first resources that I looked at. When I was starting product ops myself, it was in like a Pindo e-book or something. The rise of product ops and I like latched onto it because there wasn't much else out there. So this is pretty cool to be chatting to you and the team today. Where are you all joining us from, by the way? I'm joining from Berkeley, California. This is Blake. I'm Alexandra and I'm in the Bay Area also currently living in Napa. And this is Dan Barber also joining from the Bay Area. I live just north of the city in Marin. Nice. Very cool. And I guess to get started, Blake, Alexandra Dan, could you each give us an intro about yourselves? You know, tell us about what you're currently doing and also a bit of information about how you got into product ops. Sure. I can start with that. I'm Blake Samick. I am the head of product ops at Stripe and I've been with the company now about four years. Prior to Stripe, I was the head of product ops at Uber. And it's just been a really amazing experience to really build this function from the ground up twice. And I've been very fortunate to work with exceptional team members in both places like Alexandra and Dan. I'm really glad they could join us today. I got into product operations via product management. Actually, I was starting a product management with a product manager and I started up for many years and one place, you know, right place, right time at Uber when some of these problems started to emerge that we wanted to really solve with product operations. And, you know, I was tapped to lead that when I was already the company. So it was an exciting, very new thing at the time, but I've been on that path now for about eight years. Great. I can go next. I'm Alexandra Lipinski-Wolson. I joined Stripe about three years ago and have been in product ops the entire time at Stripe. I came also from a product management background. I worked at Apple in their retail division, most recently before joining Stripe. And when I was doing job exploration about my next opportunity or path, what I discovered in talking to Blake here at Stripe was that the pieces of the PM role I loved the most at Apple actually were part of the product ops remit at Stripe. I also recruited for product management roles as well and learned that product ops was gaining a lot of traction as a new burgeon function, was working really closely and cross functionally the pieces that I really enjoyed. Also working directly with users, which I really feel energized by and took a little bit of a risk taking on a new function I'd never been exposed to before, but have found a real home on product ops started as an individual contributor with our billing team, although recurring business products at Stripe, like subscriptions, and then move into a manager role and have since been expanding scope to work with lots of different product teams at Stripe and feel really lucky for that experience. Right now I support embedded product ops in a number of teams that you might be familiar with at Stripe like Connect, Terminal, also some of our payments products actually recently. And so I'm continuing to learn about new parts of Stripe, which I really enjoy. Awesome. And my name is Dan Barber. I lead the product ops program function where we try to manage processes and programs across all of the tech work at Stripe. And yeah, my background is a little bit different than Alexandra and Blake's. I come from mostly managing field teams on the support and kind of customer success side, mostly at larger or sorry smaller startups. And so really kind of saw a lot of the kind of experience across cross functional teams in my first 10 years in tech and really feel like I built the empathy and the product ops function was my like nights in weekends job where although I was responsible for PNL and business outcomes, the thing I love to do was synthesize kind of what we were hearing from the field and really influencing the product roadmap. And so kind of feel like I became a little bit of an expert in that. The company I was at most recently was this ed tech company called Alps School where we were so obsessed with user feedback that we actually built our own network of schools. And after six and a half years doing that, we got introduced to Blake and Stripe. And that's when we really outlined kind of what a central program could be for the product ops function here at Stripe. And in some ways, building that operating system for the teachers and schools that we ended up rated has really helped with a lot of the work we do. Actually building processes, programs and tools for our internal teams here at Stripe. So that's been a really fun but surprising kind of translation to our work we're doing today. Yeah, thank you for sharing that. Some really interesting, I guess, backgrounds and like I was listening to some of the things you're saying and obviously Blake, you've been doing this for I think you said like eight years. So set it up at Uber and now at Stripe. And so I guess for a lot of people, product ops is sort of still an emerging and nascent and new thing and then you've obviously been doing it for a while. So I'm sure people are going to be excited to listen to what you have to say there. I loved you sort of saying right place, right time because I think a lot of people end up sort of not stumbling into product ops, but it comes from these problems in a business. And if you happen to be there and the person who's, I don't know, curious or interested in trying to solve them, you end up getting closer to it. And then sort of running running with product ops is what I've seen. And I like Sandra. I also love what you were saying that like you actually identified maybe what product ops was actually doing with the bits that you were interested in. Which I think for a lot of people I've seen that too, where it's like, oh, okay, there is actually this function that gathers together the things that I'm actually interested in looking at. And Dan, yeah, I also have seen quite a few people come from that like customer mindset to understanding what's going on with the customer and bringing that through to product ops because you sort of mentioned it. And I think that's such an important skill is empathy. So like, especially if you've been product ops not just for the customer, but you deal with so many stakeholders. It's so cross-functional that you have to be able to like put yourself in, you know, other people's shoes. So great mix of like backgrounds coming together. So my next question to all of you would be, you know, how is product ops defined in the context of Stripe? And I guess Blake, if we could kick it off with you. Yeah, well, let me give it just a little bit of an overview of Stripe, where folks that may not be familiar. Stripe is a payments infrastructure company building for the internet. And really our overall mission is to grow the GDP of the internet. We offer a fully integrated suite of payments products, bringing together everything that's required to build websites and apps that accept payments and send payments globally. So, you know, this is things like powering online and in-person retailers, subscription businesses, marketplaces, SaaS products, really everything in between. We also help companies beat fraud, send-in voices, issue virtual and physical cards, get financing and manage business spend and much more. Couple quick stats, you know, collectively businesses on Stripe processed more than $640 billion in payments in 2021. There were 1,400 new companies joining Stripe each day last year. And this really includes companies of all sizes, startups to 4 to 500. And we now have more than 7,000 people working for Stripe across 23 countries. Internally, our first operating principle is actually users first. And so from the super early days of Stripe, it has been very important to talk directly to users that co-founders Patrick and Jerry. John, I always talk about this and there's some great early stories of them sitting right next to the early customers and just iterating with them. And it's super inspiring. But it's a great place to do product operations because of that, because like that's such a big part of what we do. And so I'll just talk a little bit about how we define product apps in the context of Stripe. Really, we see our overarching mission is to really accelerate Stripe's ability to deliver more value to more users. And we break that down into three really evergreen objectives that we're constantly talking about. One is deepening understanding of our user needs through Type V back loops. Two, we want to deliver high quality products to market with efficient cross functional coordination. And three, we want to really build connect to Tissue across Stripe with streamlined operating protocols and information channels. Our team broadly is organized into two groups and it's awesome to have Alexander and Dan here kind of representing both sides of that. The first one is called Embedded Product Operations. These folks are Embedded Product Operations Managers. They partner directly with one of our product areas and they go really deep with that product area. They get to know those products really well, the specific users really well, and they really embed it with those product teams. We also have what's called product operations programs. And that's a team that focuses centrally establishing and running these ongoing programs and the associated tooling with them that really all product teams plug into. So this is about streamlining communication and coordination across functional teams and product teams themselves. The Embedded Group that I mentioned, they really run high priority data and launches with Type V back groups. And they also improve the ongoing operations of that product area as a whole, often leveraging some of those central programs that be established. And they tailor the solutions to those areas because one size is definitely not good all. And we want to recognize that for sure. I do think it's such a powerful combination though, to have both of these groups working really closely together. On one hand, the central group is defining those protocols and tools that scale across all product teams and working really hard with those cross functional teams to figure out what's going to make sense for them in general across all these product teams. And then on the Embedded side, you have them working really closely with that. They're often the users of a lot of those central programs themselves. So there's a lot of Type V back coming back because they want those programs and tools to improve as well. We are now approaching about 50 people in product operations. It's right. We're spread across the US, Europe, Asia, Latin America. We are embedded basically wherever product teams are. And we have product teams all over the world. That's right. Most of the folks in that number are on the Embedded side of the house within our team. Where we fit within the broader org, just for some context, we are within the engineering organization. And we do work super closely with product management and engineering both, the leadership of both teams. I think collectively we talk about the tech work. It's right being a combination of product management, engineering, design, technical programs, product operations. There's lots of lots of within that. But we work really closely with the leaders kind of of all of those. Cool. I was just scribbling down stuff as you were chatting. And I'll probably just pray that back to you to make sure I understood it. But it sounds-- I mean, it sounds like you have a very clear mission. The way you're structured is to optimize for that. So it's definitely-- it feels like a team that is quite mature and has scaled up. So I guess what you were saying first and foremost, like I guess in line with Stripes mission or what they want to do is you are trying to make sure that you're delivering more value to more users. So really honing in on that. And then you do this by focusing on three kind of pillars, which are, I think, the first one is around user-- understanding the user's needs and creating like tight feedback loops. The second was around-- I guess it's all about maybe shipping products to go to market almost. And how do you coordinate that cross functionally with maybe internally also? And then the third point of understood it correctly was around sort of streamlining operating protocols. So I guess how do you potentially make the teams more efficient and think about a centralized approach to things. And in order to deliver on those three, you not decided that the best model to do this is using the same bedded and sort of centralized approach. It's a mix of the two. Where embedded really understands what's going on on the ground with the teams and is working with them. And then they almost feed back to the central team to who then create sort of maybe processes and things that they give to the people on the ground. But it's like a constant feedback loop. Because I also like what you said around one size does not fit all because that is really true. So when you're trying to do centralized processes or programs, it's hard to tailor to everybody. So the way you're structured means that you kind of work hand in hand. Did I get that right, by the way? Yeah, I think that was a great playback. I think that's awesome. And you know, one thing I'll just say on the central processes and programs piece, one thing we talk about a lot is finding this line between chaos and bureaucracy and just really trying to help everyone move faster. And one thing we just really conscious about is really just what actually needs to be centralized or what actually needs to be done in a certain way versus what should teams have like total power to define how they do things. And I think Dan will talk a little bit more about this. But for me, it's kind of like once you have those connections between teams, that's when that starts to get interesting. Like you want to kind of have that happening in a consistent way, have this communication channels happening in a consistent way, such that all sales people, for example, can see everything on the roadmap in a consistent way as opposed to having it be in very different ways in different teams. I got it. Yeah, and I get that. I think one of the things I'm thinking about at the moment is like, which things-- what's the minimum viable process or like the minimum thing you need to make consistent? And then what's the other stuff the teams can just like DIY do it yourself because you don't want to be too prescriptive and then tell them to do everything a certain way. For sure. That makes a lot of sense. And I guess just also you mentioned that the teams like 50 people. So that's like how many in product ops and most of them are embedded. And you sit within the tech side of the business or engineering. But it's sort of you work with product tech design and work really closely with them. Correct. Yeah. OK. That was really helpful. I guess Alexandra Dan, anything to add in on the product ops team at Stripe and How It Structured? Yeah. One thing I'll add from the embedded perspective that I think is a real strength of our team. There's really two things. One is, especially because product ops is a more versioning function, we are able to pull and attract people from really diverse backgrounds, people who have come from product or even sales, other user facing functions, program management. We've had a really diverse background. And that feeds into my second point, which is we have this amazing brain trust within the product ops team within embedded where individuals might be maybe the only products person embedded in a particular product space. And they have that group as kind of their second strike family. But they have their core products team members that they can go to when they're looking to adapt programs, maybe central programs for their product area, or they're taking on a beta for the first time. And they have this place to come and ask questions and feel supported and share best practices with one another. That's something that's been really exciting for me as a manager is to see more of those organic connection points happening. And we do a lot also to foster that. But something I really appreciate as well when I was an individual is being able to tap into that brain trust and share resources across teams. Yeah, that's very cool. And also, I guess, it prevents it like siloed mentality if you're embedded. Yeah, that's the idea. And I'll just add from a central program perspective, when we actually kind of identify a problem and maybe even have solved it for a pocket of stripe but then want to kind of prove it over time or begin to scale it across the org, having the arms and legs of our embedded team members that all collaborate so closely, know each other so well, are on weekly meetings together is just invaluable for us to really be thinking about how do you manifest that change across the company? And so obviously kind of staffing model instructor can't always be the same in companies and even kind of how roles are funded. But this embedded model where it really is driven by the PNLs and kind of business units, but they centrally report into a small group of managers that really are cohesive and aligned and have clarity of what the remit is. They get to partner with this kind of centrally funded program team, has been a really powerful combination for us. Awesome. I guess leading on to that, it would be great to potentially deep dive a bit more on some of the things you sort of touched on here. And I guess a sense of how product ops is delivering value within Stripe, given how fast you're scaling and the size of the team. Maybe with some practical examples, if you could share some of your learnings, that would be awesome. So I guess Blake, if we could start off with you. Sure, yeah, so I'll talk to a few of the things that I thought about differently coming into [BLANK_AUDIO] versus Uber. And of course, these are super different companies, different business models, different users, different cultures, things like that. So there's a number of differences, but there are a number of things that are very similar with scaling to that companies and kind of the problems that can emerge, the disconnects that can emerge between the folks, building the products, the folks that are talking to users kind of all day, every day. I'd say one major difference that I thought about coming and described was to have this deeper investment earlier, very early, in this central programs group. And so making a higher of Dan in this case to come in and really lead that group and kind of build out that team was a pretty powerful differentiator and like let us do a lot of things that had a lot more scale and connect across all these different embedded teams. Whereas at Uber, we were doing a lot of those things, but we were doing it really with 10 to 20% time of each embedded person to kind of work on some of those programs, which is great. It's better than nothing. You could do some really scrappy things like that. But once you hit on something that really resonates with the organization and you need to do it in a way that is actually very functional and scalable and is going to be repeating, which is like the stuff that we do, it's super helpful to have that central group that you'll focus on that. I'd say another thing that we've done differently here. And I think Alexandra mentioned kind of the diversity of experience on our team, which is so great. At Uber, actually in product ops, we had almost, it was pretty much a rule where you had to come from inside the company. You had to actually work in an Uber city team for at least a year before you came on to product ops with the product team sitting at HQ or in other areas. And I think that was actually really great in the beginning because you had those people coming in that had a ton of empathy for what it's like to be in a city. They had a really good understanding of what it's like to run the business on the ground and to be potentially pretty far away geographically from where the product was being built, a lot of those disconnects. And having that coming in was super helpful. But now I think coming into strike, I really wanted to make sure we had a good mix of folks who did come from within strike because you can still get a lot of really great stuff who come from other areas like customer support or sales and talking users, but also bring in a lot of these awesome experts from other companies and big tech companies and startups that have done product operations before or roles that are similar. And so I think it's great to have that mix. And I think those are some two key differences that I think have worked super well in the context. Yeah, that's really interesting. I can definitely identify-- I guess with that, because I'm doing setting up product ops, I guess, from scratch for the second time. And the first time I did it, we also used an embedded model mainly because that was the problems that we're trying to solve and land itself to having somebody in those teams working with them. And exactly what you were saying around the team naturally was working with product managers and engineers to solve team problems. But they were also spotting these almost like process style or things that needed to be solved for the whole-- not just their squad, but across the whole team. And it ended up being a thing where they were then doing main focus was on helping the team. But then, like you were saying, 20% or 10% of their time was now trying to do these central things. And we almost made them quarterly goals and each person had something to do. But it became increasingly difficult as it was more like pressure on the team to actually deliver. And these things kind of dropped. And then you didn't have somebody who was looking at the overall thing. That actually then ended up being me. But when you were also managing and doing that, it's hard to tie everything together. So this time around going into the company I'm at, although it's just me at the moment, I am planning on setting it up as a centralized function, almost to start off with, and then having some people embedded or a mix. Because I think there's so much of value in having one person who looks at those things. And if you've ever had to implement a process or a program that benefits the team, I think you also know that it never ends. You constantly have to own it and iterate it and figure out twig it. And so you do need somebody who looks at that. So that's a great observation. And Jareesh, I think it's interesting to also think about or to share how that evolution has happened for us in the team. Because over the three years, it didn't start like that. So Blake made the bet bring me on board as a central function, not embedded. But we still used 20% time. And a lot of my energy was how are we prioritizing and creating clear frameworks and ways that we can measure success of those. But we're still using 20% time of the embedded folks to really actually execute some of those. And as we started to get more momentum, it was a much clearer kind of story of why we needed to invest in central team members. And really the first folks that joined the team were embedded team members that were invested and excited about this. And they were able to really have a lot of high value initially. And so that has also evolved for our team. And I think that kind of understanding what that art could look like and being patient that it probably takes to in a half years to really kind of manifest it. But now we have a team that has a pretty clear remit and that the org really kind of relies on to help establish central processes. Yeah, that's a great observation that like, yeah, you can't, you've got to see how it evolves to. Blake, I guess on the embedded and centralized, does every team have an embedded product ops person in it, or does it kind of depend on the needs of the team? And so it's sort of team dependent. It's team dependent. And I think when we just in broad strokes, how we think about the tech work, you kind of have a number of individual product that engineering teams that are working together to ship product. And then within, or excuse me, there's an umbrella over those that are kind of a product area. And we have product operations people that are within every area at this point, but not every single team will have that. And so we do look at things, signals like how many customer facing beta is this team going to be shipping soon? How many actual users are on that? And to what degree, what volume of feedback is kind of coming in from things that we're hearing from sales and customer support and other users themselves. These kinds of signals help us identify where we most need it there, but we're always kind of trailing that pretty much intentionally, where we don't necessarily want to need to be within every single team. We want to look pretty thoughtfully about those needs across those areas and find those highest impact areas to embed. OK, got it. And then on the, I guess, mix of people. So I guess I do agree. Obviously, you've got somebody internally who has context and understands how things run. And also maybe they're coming from the customer point of view. That's really helpful. But you said you also sort of like hired in people. Was there something in particular like did you find that people had to the product ops backgrounds when you were looking to hire people or what kind of skill set or job titles were you looking for if you could share? Yeah, sure. I'd say, if I just think briefly about the Uber experience versus now, we're a few years later, of course. And there were surprisingly more people than I thought that did have that title. So it was popping up even when we were starting the team. So that is certainly an area that we looked at as people who are in roles called product operation manager. But we also looked like Alexandra came from a product manager position. I think program manager can be a role that comes in, same with business operations. I think in the cases where those folks have really worked super closely with product and engineering. And they really understand how products are built. They understand some of the challenges with that. And look how to communicate that. And it's not just arms-length. They really work deeply with those teams. I think those can be other roles that fit nicely with what we do. OK. I guess is there anything else you wanted to share there, Blake, about Uber versus Stripe? Those were the two main ones. Yeah. Well, so I guess one thing would be-- I think just culturally, when we started product ops at Uber, it was really started because there was this emerging disconnect between all of these city teams around the world that were running like individual startups. With their own general manager, really running that city as best as possible at that time, a very central product team that was all in San Francisco. And there were just so many instances of people not knowing what was on the roadmap or not feeling like their voice was heard or the actual realities of the on the ground in that city not being taken into accounts. Maybe they were sitting in India. And it was a totally different situation where the mapping wasn't working as well. And Cellular Network wasn't working as well. But the latest products were working great on the latest iPhone. These kinds of things were emerging there. And it really led to just disconnect between those groups. And so there, it was even more building empathy on both sides, like really helping both sides working work more closely together, whereas I think coming into Stripe, there wasn't that much of that problem. I think teams were largely able to work well with each other. They just needed a lot of help to do that in a slightly more organized way and just help give some grease to that collaboration. And so I think that's a bit different. I think the one more thing I'll say is I think the information shared internally. We had much more of a black box problem at Uber, where teams often had no idea what was coming on the roadmap the case. product teams were not sharing that very, very openly. And I think at Stripe, kind of famously, we have a pretty open, very open culture inside the company. And there's lots you can read about what any team is doing. And I think the problem that we've had to solve here is much more of signal through the noise and organizing that and making it accessible so that it's easier to find, it's easier to rock what teams are doing. Yeah, that's super helpful. And I guess it also, the context or the reasoning, the problems that are driving the need for product ops will determine how you shape it, right, and how you structure it. So you had a very different context, Nuba and Stripe is different. And so you tweaked the way you set up the team and what you were optimizing for accordingly. Yeah, I think different contexts in slightly different positioning. Internally, when you're setting up the team, largely these big problem areas that we focus on are pretty much the same. To be honest, though, it's user feedback coming in effectively into the product teams and in a thoughtful way. It's shipping products out in a way that is not disruptive to users or those teams that are talking to users, just doing it more collaboratively across the board. And I think that's true in both cases. Cool. Blake, did the way you thought about product ops change as maybe the product organization matured more, like over the years that you were there, product teams or organizations move along the product maturity lifecycle. So did you have to adapt the team for that or was that not something that came to play? - Yeah, absolutely. I think the major adaptations there are along two lines. I think one was how we set up management within the team. As product teams grow and change in different leadership changes, and they're organized differently, I've really found it to be very helpful to have a manager from our team on a leader that can partner super closely with the leaders that are across many product teams on their side. Like Alexandra, for example, works with a leader across many, many product teams in a product area. And it's great for this person to have a partner in product ops to just think about product ops kind of for that area. And I think you really have to start thinking about that as you have more and more teams. And then one that we already talked about was those central programs that can just have so much leverage, the bigger you get. It's not as big of a deal to know all the things on the roadmap or all the user asks when you have a small team, because everyone can kind of see that. But once you have many user-facing teams, many product teams, it's helpful to have structured data about that kind of stuff in a single place. - Yeah, that makes a lot of sense. - Yeah, well, thank you for that. That was awesome insight into, I guess, how you launch it, given having done it before and what you would change going into it the second time. And I guess if we maybe moved on to the next example, Alexandra, would you like to take this one? - Sure, I can share kind of an overarching example from within one of our embedded product ops teams. And feel free to probe with questions or follow-ups as well. I'll fold in some insights about our team, things that we've learned as well throughout this example. And this one specific to our product called Stripe Terminal. I'll give a little background in case folks aren't familiar. Stripe Terminal enables users to build their own in-person checkout and accept payments in the physical world. So it's really a suite of SDKs, APIs, and pre-certified card readers that power in-person payments. So chances are that you and maybe readers or listeners here have interacted with a Stripe Terminal POS system in the world. Users include platform users like Shopify who have outpost everywhere. And internet first real-tailers like Glossier and Warby Parker, those are just a couple. So I'm using this example as well because in-person payments is something that all of us interact with you get your morning coffee, you go grab a sandwich, hopefully it's something familiar for folks listening in. So Terminal as a product began as US only for Stripe in 2018. And as of November 2021, Terminal is available in Ireland, France, Germany, the UK, and the Netherlands for a total within the year of 2021, expanded to nine additional countries and four continents. So I thought this also fit into our theme of scaling. There are obviously a lot of interesting nuance challenges that come with opening of any product into new markets. And we had really strong product support to make this happen. Some things that make Terminal unique and hence make our product role unique in that space is that it's hardware and software together, which is pretty new for Stripe, if you think about the length of time we've been offering software solutions for payments. Hardware really is its own world in many ways. It adds additional partners and stakeholders into the product ops network. Plus the hardware devices are then live in the field. And obviously they don't persist forever. And there's a lot of logistical pieces to that puzzle as well. What did product ops do in order to empower this expansion? So first they defined and drove the right operating cadence within the Terminal team to power global launches. This includes weekly stakeholder meetings, powering launch readiness, and plugging into some of those larger-scale central programs that Dan will go into more detail on too. Also building enablement materials for user facing teams who are on the front line with users directly. And also our team members directly engaged with large users to gather feedback and help troubleshoot issues. This is a real superpower of folks on our team. They understand users needs and can go really deep with them for their specific use case, wherever they are in the world. Also setting up a scaled strategy for user support. Users might be calling in or contacting support with hardware issues, connectivity, software, integration, all different kinds of challenges. And we needed a scaled support strategy to enable that. And lastly, they secured in-region product marketing support and partnership, which is really crucial again to ensure communications were targeted by region and included any region-specific detail. This is also kind of an example where you can have a general approach to shipping a terminal product. We also need to make sure we're being nuanced in individual GOs. Just the last piece I'll kind of fold in here are some of those central programs and doing last mile adoption for the great work that Dan's team does. Our embedded products drove all the launch readiness elements, which we have certain approvals that we want to make sure we're logging when we launch large ships like this across many different cross-functional teams within Stripe. Also, one of our team members in this space that have a scaled feedback loop process, utilizing some of the tools and information and structure that Dan's team had built within central programs. And lastly, we also do a voice of the user series that's really comprehensive in the terminal space and has had really great feedback from the team. This ties in top asks from user-facing teams within Stripe. And I know Dan will go into more detail about this program. This really boosts awareness of all the great work that central programs does to help us hone in on the top asks from users and synthesize those insights. So that's kind of an overview, as you can tell, I'm really excited about the work that's been done in this space and really proud of our team to help power all this expansion. Yeah, that was a great example. Thanks, Alexandra. I do-- I currently work for a company that does payments in the UK and is using hardware and software. So I am aware of the terminal being an actual hardware item that people are using. There's a lot of new challenges that come with that. One of the questions I had around that is, it seems like, obviously, product opposite Stripe focuses in embedded is you're focusing a lot on actually speaking to users or the customer and getting that information and being very close to them and doing that. Do you find in any way-- because one of the things I've found is that oftentimes, product managers want to be getting really close to the customers and doing that and being the person who goes to speak to them. So is there any overlap or friction or how do you divide that work? Do product managers go with you or how does that work? Yeah, that's a great question. And something that's really core to the philosophy Blake mentioned across all of Stripe is that we want everyone to feel empowered to speak with users regularly. This is very important to both Patrick and John and that culture really starts at the top at Stripe. And so where we see our value add is, we can help set up more scalable processes within our embedded teams so that other team members who want to talk to users and want to feel a bit supported in that endeavor can plug in. So for example, we have a couple of team members in different products faces that run very skilled, very frankly mature programs where they'll maybe rotate how many engineers or product managers or designers are on the calls with them with certain users. This is more of an evergreen program that they run versus doing a specific beta or alpha feedback endeavor. And this has landed really well so far with our product and end partners. Because we don't ever want to be seen as the gatekeepers. We don't want anyone to have to go through a lot of red tape to talk to users who want to make it that much easier for anyone on the team to engage. And also sharing those insights more regularly, recurring review sessions for feedback, involving lots of folks on the team really helps with that collaboration too. - Got it. And then I guess you also saw some of the things you mentioned was around like helping with the operating cadence. So I guess putting in place maybe, should we be having weekly syncs for this or. a stakeholder meeting or getting the team into a rhythm to make sure that they can share information and do stuff efficiently. And then you spoke about another thing I got down here was around user support or thinking about the strategy that you would then have for user support. And then you spoke also about maybe to do a product marketing and in regional specific stuff. And I was also thinking, you know, oftentimes you have a customer support team in a company or maybe a representative on the team. And then you also have product marketing. So is there are you working closely with those teams when you're doing this and helping them to give them input or the strategy or is this something that like product ops owns within the team? It's definitely a collaboration. And one of the real strengths I see of our sort of flavor of product ops is that we're strategic thought partners with product and end when even the development and shaping phases are underway. So we're very close in our embedded work to understanding and utilizing user feedback to help shape the roadmap as well. And during those early conversations, that's a strength that we can bring in is flagging that this will have user ops or customer support impact. And then making sure we utilize the connection points we have into user ops to bring the right folks into the conversation, plug them in effectively with product and end. And the same goes for product marketing where we might engage with partners to help shape the overall messaging up front. And we do have swimlings between those roles, but we definitely see value in being able to bring those partners together early on in the development life cycle, helping them feel really connected because also chances are in a lean organization, they might be supporting multiple products at the same time or multiple shifts. So product ops can serve as that really central point of contact and collaborator. >> Okay. And the last point I think, well, I took down was around sort of launch readiness. And I guess my head I'm imagining like a checklist or something where, you know, before something launches, you kind of need to check these things off. Is that something that product ops makes sure is sort of done before something goes out through the door or how does that? >> Yeah. >> I can share from the embedded perspective and would love to chime into because this team has done a ton of work here. >> Okay. >> When we think about launch readiness as a concept for product and engineering teams, everyone at Stripe in my experience wants to ship great products for users that will really meet their needs. Product ops can help them understand maybe pocket that they might not know they need to pursue, like a legal review or compliance or thinking about how the right steps to roll out a product might be starting with a small alpha based on the shape of the product or what they're looking to learn. And so everyone has this really high ambition and intentionality which I really appreciate and then product ops and help guide. Okay. These are some steps maybe you haven't considered before in a structured way. And we also want to make sure we're not being overly prescriptive that every single launch of every size and shape needs to do the following run down of items. If they're not applicable, we need to be flexible. We give our team members a lot of autonomy to adapt and understand the unique needs of the product spaces they're embedded in. That's a skill capability that we look for often when we're hiring. Dan, would you like to share a little bit about some of the central launch readiness work? >> Yeah, happy to jump in. So we think of launch readiness as really an issue that's fun up last year to bring some structure and really thought of those kind of three core user groups thinking of the launch teams and how they have the right intention but may not know exactly what steps they need to complete. And then if you think of those cross-functional partners, they have a similar problem. They are responsible for making sure every launch is compliant, but they have no way of knowing who's launching what and making sure they're giving them the support that they want. And then finally, you have the business leads or kind of general managers, GMs in each business unit that are accountable to every product that's launching in their area, but they have no idea what compliance or regulatory requirements may be for each of those. So we really kind of started with those three user groups and thinking through how do we create a tool but also a set of kind of protocols across teams that everyone can agree to that help us connect the right cross-functional partners with the right product launches at the right times. And so just since I know we're on a podcast here, we can't share visuals or walk through, just describe super quickly. We basically built a tool on top of the launch calendar tool that we had been managing that first asks you eight questions about your product launch that basically recommend which cross-functional teams need to be involved. And then we ask you kind of what tier and what availability phase. And based on those kind of three factors, we kind of recommend which reviews you need to kick off at which stage in development and enable you to kind of kick off those reviews from the tool and have kind of central tracking of little bits that get flipped by those cross-functional partners. And so they're not kind of hard dates in the sense that like you could kind of push out a feature or kind of release code without necessarily kind of going through this process, but it really clarifies kind of accountability lines. And as we said, we really assume positive intent across all teams. And so started from this place of like, well, let's just arm people with the information and kind of transparency for how they can go through a happy path. Let's make that really clear. And let's use structured data which you heard right, say a few times. It's definitely a theme on our central program side. It's not that we use tools and kind of processes to give us structured information. Now let's get smart about it. So if we solve that problem, then like how do we look for outliers? And then we look for really great examples, but also how do we find examples where something got delayed and dive into that to make sure that we improve the process from there. So say the tool kind of both provides a little bit of clarity, but also that kind of observability that's really helpful. That is, that's really cool. And also highly relevant to what I'm looking at at the moment, which is trying to improve the sort of product launch process. And I like what you said, because one of my taglines is the right product info to write people at the right time. Because there's so many stakeholders to engage, but you've got to engage them at different points in the thing instead of bringing everybody in at the same time. See, one of the things I started off doing was looking at even just giving them a sort of like stakeholder guide, depending on what type of product you're doing. And then making sure we have all the functions there and you actually know who you should be looping in. Yes or no. And who in the business you should be going to because oftentimes in the large business it's even hard to know that. So that was kind of a starting point. But I love the question idea and I'm totally going to take that into the work that I'm doing. So thanks for that. Yeah, we called it Compass initially and honestly I was a little skeptical that it was going to be really great. But we in our last quarter, we've been over 90% accurate with no false positives or negatives which we've been tracking or with 10% of false positive negatives. So we continue to tweak, but have actually been really pleasantly surprised with kind of how you can kind of get down to what are the core attributes that would mean you should engage with these teams. Yeah, awesome. And Alexandra, I guess just going back to Stripe Terminal and the example you gave, was there any like challenges with the work that you were trying to do as product ops that you wanted to highlight or you know how you kind of dealt with that in getting to this really positive point of launching and doing all that great work? Yeah, I think in general it kind of goes back to the theme I was sharing that. Each product space is really different and not just the product itself, the phase of maturity it's in also of the team. How familiar the team is with product ops as a function. Has there been a lot of turn or turnover within the product and the leadership? All of those elements can kind of show up as different challenges or nuances with different groups. With Terminal, we were really lucky in that there's been incredibly high engagement and consistent positive sort of brand recognition of products in that space. We've had embedded product ops, I think since 2019 on Terminal and they're very invested in that partnership and make every team member really feel like they're part of the terminal family. One of the challenges though is that teams that were embedded in their needs change over time and their phase of maturity shifts. So Terminal, when we started was much smaller of course, Stripe has been growing and the Terminal team overall has just as high ambitions as every other part of Stripe and is expanding within their own teams, multiple new sub teams, thinking about how we as product ops can best support the highest priority projects within even one product space. So Terminal might seem like it's one product area but there are multiple sub teams within and it's a heavy prioritization exercise every single time to make sure we're looking at the right product and features to support. So while this was going on, there were also a lot of software and SDK improvements that were not geo expansion related. There were also new leaders joining operating cadence changes and central programs to roll out also new sales team members to spin up. So always kind of just the prioritization challenge, I felt this within Terminal as someone supporting embedded folks there. We also had a second Terminal embedded team member join in November right as this was happening. So we had more expansion support but also scaling up a new person was a great opportunity within our team too. Those are some things I would highlight in that we were successful navigating all those different elements and we need to do that in a nuanced way with every product team. Got it. I mean, I guess that's the nature of being embedded right to you. You got to make it fruitful for each of those teams. And as there was anything else you wanted to add on that Alexandra, I was going to move on to Dan. So was it? Yeah, I just kind of lasted it would be that some of the things I think made this particular example a strong one to share were some capabilities that really shine through from our embedded team members. One really big one we see that's successful across all product areas is leading without direct authority, being able to influence a large stakeholder network, a large constellation of user facing teams towards a North Star towards one, you know, singular goal that everyone can agree on, maybe running the right forums as a result, but really, you know, positioning yourself with high trust in those teams and also program management. We see those skills coming through really strongly as well when you're looking at a large scale program that might be running across multiple months like Geo Expansion is. This is one piece of a larger expansion strategy. Being able to provide feedback and influence teams is really important. And this was just a great example of all of a lot of those things. Cool. And then I guess onto you and your example. Yeah, sounds good. So we talked Alexander talked a little bit about our top asks program that really thinks about product feedback loops. And I guess as a way of introduction, I just want to kind of frame a little bit of kind of how we think of the programs overall and kind of dive into them more evergreen objective that this kind of this program really helps to address. So we really think of the programs across inputs, outputs and operations of our product teams and try to think of those domains as something that every SaaS company kind of has to reason with that are going to be perpetual problems for us to solve. And that also helps define why our team adds unique value. But so for this one on the inputs to product team side, we manage a couple feedback loop programs. And the one I'd love to dive into today is called top asks, which funny enough, I know Blake got into the kind of pivots from Uber to to stripe. This is a program that has some roots in his time at Uber when they were trying to get alignment across teams. He even branded as top asks internally. And if it's not broke, don't fix it. We use the same kind of moniker here as we spun up the program. And it's third year. I know it's evolved a ton in the three years we've been running it. So I'm sure it looks pretty drastically different from it did at Uber. But I think the concept of saying, how do we understand what our asks are? And then by saying top, you're kind of implying that there's some methodology to kind of distill signal from noise or some way to kind of stack rank or organize that. And actually over time, we kind of have this fun graphic internally that says top kind of blink asks. And you can just slice it by any of the structured data. You can say top amea asks, top 10 asks, top lingering asks, top, by any of those kind of structured fields that we try to keep for these packet to feedback. Now it's certainly not all rainbows and butterflies. And I think with these evergreen programs, one of the key things to reason about is that this will never be perfect, right? Your doves never kind of done. And so I think when you kind of prompted the challenges and specifically what are the challenges with scale, I think top asks are really interesting surface area to kind of talk to them. So as a small central team, we really kind of dive into a few things and then Durey Shob please jump in and ask and clarify questions. So first of all, like when we think of these programs, we really look for patterns across teams where there's inefficiency or duplicative effort. And as Alexander said, we've grown so much over the last three years that I've been here that there were pockets of really great collaboration between go to market and product teams. But that as we hire a thousand folks that are out in the field talking to users every day, they can't possibly like jump into each individual team Slack channel or go read their digest emails of kind of what the roadmap is going to be or really need to kind of synthesize what their user call was in their own kind of bespoke way. And so really trying to think through, okay, what can we do to kind of bring some common rails to those. Now a couple of other things that aren't challenges at Stripe that I bet some of our listeners are kind of struggling with is user interest is not a challenge at Stripe. So we're not trying to like change motivation or behavior or just trying to change behavior, right? Everyone is wanting to talk to users and if anything, as Alexander called out, like we actually a constraint of our program is that we don't get in the way of that, right? That we're actually like not obfuscating or making it harder or not important for you to talk to users. In fact, like the core success criteria is can we make it easier for you to talk to the right users. And then, and then, you know, I would just share one stat that really kind of drove the motivation for starting the program, which was that when we surveyed the go-to-market folks about where to submit feedback, there really only 25% of the field team that knew where to go to submit feedback. And so just thinking of that inefficiency of we have these internal experts across Stripe that are spending, you know, 30 hours a week talking to users and we're not leveraging that information in like a reasonable way, clearly kind of identified the problem space. Okay, so now, like what role should we play as a central team? And so I mentioned kind of motivation is in our problem. Being users first is so core to Stripe that we really need to be thoughtful about kind of how we can do it. So, the, you know, the worst case kind of dysfunction that happens when you don't have a program like this is that the loudest, most persuasive kind of CLC member is the one that's describing the roadmap. And there's a recency bias and we're not actually using the kind of business outcomes or kind of surfacing all of the options on the table when we're making product decisions. And so I think that was one that we really specifically thought about was saying how can we capture feedback throughout a half, but then have this moment and really actually go for as many pools of feedback that we can find. And if our team does that on behalf of the product teams and we go look at CSAT survey responses and the social data that a team is looking at from Twitter and then we go look at support volume drivers and we go look at lost reasons and sales force. If we can kind of do that on the product team's behalf and kind of make sense of it, we're again, not getting in the way of them talking to users, but we're actually kind of bubbling up the users they may want to talk to you missed. Second, we've talked a lot about structured data, but I just think like the way we think about that in our team often starts in spreadsheets is if this row is a packet of feedback, well, what regions is applicable to what specific users, who has told us about it and just how do we start to get any of the slices of information that we want to hear about it or be able to kind of pull later and make those structured data fields. And then of course, you have to kind of figure out the ROI of the cost of capturing that data with the benefit you get from it. And so kind of start with one thing. And as people ask you for more slices of the information, add that as a structured field, right? And then it takes kind of one exercise across the top 100 asks to add that as a new kind of data field. And now you have it. So the next time someone asks for a report of, well, which of these were shipped in the last last half, we can add a launch Cal ID field. And now, forever forward, we can kind of print out a report of every top asks that's had a launch associated with it. And then so the third thing that we really thought about what role we should be playing here is kind of understanding the team's inherent motivations. Because as we said, this kind of tension between go to market folks that are kind of out in the field and trying to influence the roadmap and product team, so many different pieces of information coming to them about what they could build. How do you actually help know that those are inherent to their roles, right? The org structure is actually asking sales to advocate for us to change our plan with the new information they have. That's a core responsibility of them. And the product teams are having the kind of reason about that and make their planning process. And so we really thought about kind of how do we help lean into that kind of incentive structure, motivation structure, and just give them the surface area to surface the best information and then try to clarify kind of who's making the decisions. So we kind of landed on some of those problem spaces that we thought our team could add some pretty unique value, which then gives you to like, well, what are the kind of highest ROI time that our team can spend and just thought I would kind of touch on three things. And then we can go wherever you think is most applicable to the listeners. And the first is, you know, we think about when rolling out these programs, I often think how do we make them more incremental so that we can kind of prove value before rolling out or expecting everyone to take something on. And so sometimes this can mean starting with the particular product team. So Alexandra talked about terminal. They're like early adopters, great advocates of the product feedback group programs. So they would be an amazing place for us to like start an increment. program or exchange program knowing that they'll skate ahead and do some testing for us internally. But you could also be more incremental by focusing on user segment. Maybe it's enterprise or sold users that have dedicated account teams. So we have a bunch of expertise internally versus kind of self-serve users or folks that don't have managed accounts. Or even just specific time horizon. And I think this was the really key critical part for top asks. Was it really focused on planning season and when product was most interested in seeing feedback in this structure. And you know, the right answer is not let's do this once a year. But the right answer is also not let's do this once a month. And so landing on, okay, well, product teams are planning twice a year. Can we back into that planning process and give them something that would really be high leverage. And that is worth us investing in the central process. It's worth the go-to-market team, spending their time and energy to both kind of capture the feedback throughout, but also to kind of add their anecdotes or kind of post-processing on top of that during planning time. But then it's really easy for us to kind of align with product teams and what the commitment kind of agreement is for the program overall. The other two that I'll just call out, which are a little bit quicker. One is kind of stack ranking methodology. I mentioned that we had kind of a way to distill kind of what are the top 10, what are the top 50. And so really we kind of thought through revenue and kind of cost drivers and then user kind of reach as the two primary factors. And the whole program is really anchoring on specific user examples as the primary driver of that kind of stack rank because we can pull a bunch of information about that user. So if you give us a user example, we can go into the kind of internal system and we can understand, well, what segment are the end? What region are the end? What's the potential payment volume implication? Like how do we really think about what that user is? And so the quickest way to kind of move, ask up in the stack rank is to list out the users that you know that would like that thing. And again, this like leaning on those inherent motivations, well, like solves so many product team problems, right? Because now when I'm building a feature, it's so much easier for me to say yes, when I know what my first 15 beta users are going to be or when I can kind of understand what segment is most applicable. And then the last kind of thing that we thought would have a ton of ROI and been kind of investing in is just making it super simple for user facing teams to enter those user examples really anywhere. So from our launch calendar, if you see something coming up, you can like click a link and add your user example from another tool our team runs called the coverage tracker. It just like even shows you, you mentioned your impayments like this currency country kind of functionality pairing can actually be super complicated. So we want to run a program that kind of helps make sense of that. And from anywhere in there, you can just like add a user example to an upcoming feature. And then again, during this top-bask process, kind of sharing in a more of a map, simple view for all of the kind of key strategic accounts to say, make sure that you mark whether your user is interested in these. And just again, making that super simple and low left for teams has been one of the things that I think has like helped us figure out what role we should play and how we can kind of help bring signal to all of the noise of user feedback. Wow. That, first of all, that sounds like a dream like tool system that you have there, which is so helpful and amazing where I guess in my head, I'm imagining that you kind of like, you know, your product manager or you're thinking about what you want to build or you, you know, you want to test it or whatever it is, but you want to figure out like, how do you understand your users better and how are you getting the right information about those users and you would go in and then you would, or you would find out like what are people asking or do they want this or it helps you maybe validate your problem statement or your hypothesis or I don't know, it just seems like there's so much of information in them. It just sounds like a really cool search engine that you basically create that internally and striped. Is that right? Is that sort of how people are using it and what they're doing? Yeah, yeah, I would say like on its best days or its best use cases, it is that. And I think like in the top 50 we invest more. So again, when I think of like how to do this more incrementally, our team spends way more time on the top 50 than we do on the long tail, right? And I think for those top 50 we like do a better job of kind of grooming and analyzing that. But I would say it doesn't, you know, it's not the silver bullet. It's like clear tooling and framework for us to kind of promote collaboration, but we aren't managing the packets, right? It's only going to be as good as the inputs that go to market gives us and kind of the thoughtfulness that they give us. So, you know, the some packets come from the team that have, you know, linked to competitor documentation or like super specific examples. And I think those are much easier for product to engage with. So yeah, I would say it's not kind of without the common dysfunction with any of these, right? There's like 10,000 of these packets of feedback for lack of a kind of specific term. And, you know, those can really easily go stale. They can really easily kind of fall off the radar. So I'd say we try to have kind of some self grooming, but otherwise we kind of rely on the two sides to this because our kind of small central team can't touch each one or kind of manage. So we're trying to just make it a collaboration tool, really. But you're sort of giving it a home and you're kind of synthesizing what would be a lot of data for people to I guess go and like manually try and figure out where everything is to build up the picture and you kind of, you know, giving that or allowing them to have a tool where they can sort of pull that stuff together. Yeah, yeah, I think I think one of the reasons why I thought this was a fun example for what a central program is is because it wouldn't make any sense for an embedded team to do. It wouldn't make any sense for one product team to take this on. But as soon as you have two or even three or five product teams, I think it makes a ton of sense for a central team to actually like manage and invest in something like this. And how are you measuring the success of this down? Like is there something or metric or I don't know, a survey data or like how do you tell whether this is successful? Yeah, yeah, good question. So for all of our programs, we have, you know, you got to have some framework or thing to kind of hang them on. So we have reach, engagement and impact measures. And so that's the specific answer is that we have metrics that are kind of leading and lagging in each of those for all of our mature programs. Now, a little bit more abstractly, we do try to think of our central programs as almost like their own little SaaS products because we don't get much kind of top down mandate at Stripe for folks to adopt something. And so we truly look at adoption of the tool and look at like exactly who is using it, which screens are they going to and who is in charge of sales on our team? What are their relationships across teams? Have we like had a QBR with Alexandra and her business leader to understand kind of what she needs to see from the program for this to be great for her? And how do we use that to prioritize our own roadmap of kind of tooling our program changes? So yeah, I think it's an interesting question and challenge, but we've tried to really kind of again lean into those kind of motivations and dynamics across teams to say Stripe's almost like hired our team to do this thing to like consolidate feedback for teams that had a planning. How do we make sure that they would renew their contract every planning cycle? What are the things that like went well, what are the things we need to do better and how do we recent about that? That is an awesome takeaway and I guess a way of looking at how do you deal with programs or process or introducing things in the company. It's almost like to treat it like your own product. That's very cool. Anything else you'd like to add on that down or Blake or Alexandra if you want to chip in or jump in on that? I'll add one bit that's related to top-ass. I think again with this connection with embedded folks, there's like a really powerful thing that can happen with a program like top-ass where if someone just looks at a whole list, it's like gets informative to see like what's top across the company, but then it gets for certain people in certain roles. It's great to see what are the top-ass for this particular product or this particular segment and like what's the the broader narrative around the list? And so it's super helpful to have folks who are really close to the product areas, they understand what those teams are dealing with, they understand where the teams are likely to discuss this kind of thing and to kind of do some last mile tailoring of the information, like in a bit of more of a narrative say let me talk about the top things we're seeing for this product area in particular and those kinds of things can just like help that stuff just land way better for those teams than just simply having a central thing that they all look at. That's one thing I would say. I'd say earlier we were talking about product managers talking to users directly and like absolutely we want that to happen into Alexander's great point we want to make that easier and I think one thing I just call out is that even with these programs centrally The expectation is that those VMs and engineers are talking to users, but it remains the truth that they cannot talk to users in every region all the time. We have lots of people that are and we can really augment their understanding with a lot of extra information and good entry points to go talk to other specific users and things like that. So it's super helpful for them to get that additional context. But this does not mean they should stop talking to users at all. That is something that we think is super important for those roles. Got it. Okay, thank you so much for sharing those practical examples with me and sort of your learnings and insights. I think, I mean, for me personally, I'm taking away a lot of points here going into my own job and things that I'll be implementing. And I'm sure that the listeners have also found lots of insights in this. So thank you so much. I guess to end it, my last question to you would be, you know, what one piece of advice would you give to product ops professionals who are scaling this function? I can take it first. I think what I would say is really in the early days, take the time to identify who are the likely stakeholders of this function, talk to them, try to understand the problems that are there. Try to understand what those other roles do. Because I think that can be slightly nuanced in different, different companies. I really take the time to have that conversation and identify what you want to be core about product ops and the role. Because you can very quickly, given the capabilities of the people that you hire into this role, which are fast, I think you can very quickly get into a Jack or Jill of all trades kind of situation with different teams. And it's just super helpful to identify what is really core. Like what do we want people to focus on the most in those areas? And it's okay if they stretch outside of that in certain cases and things like that. But it's just really helpful for hiring. It's helpful for cross functional stakeholder conversations and just like setting expectations and just like aligning on something. It's a bit more of a simpler crisp list. And related to that, I would just say if you're setting this up brand new, ideally I think you try to have somebody come in that has some experience in this that can really help set those foundations and just bring, it brings a little more immediate credibility to the role, which is so important as you're trying to like build it up across many different teams. Yeah, you can share to plus one on all the things Blake mentioned. For me, some of the things that I've seen, particularly in our embedded function, is really empowering our team members to adapt and meet the product teams needs where they are at the start of that relationship first. And we're really fortunate in our model where we have both embedded and central that we can meet the teams where they are today, deeply understand their problems and also what strategies they have for growth. And then also be consistently bringing in opportunities to move more towards a centralized program, or repeatable scalable processes and playbooks in that space. But definitely starting with a core understanding and really empowering team members to adapt, I think is critical. It builds early trust as well and helps our team members still really closely connected to those product teams. We want them to feel like that team success is their success and vice versa. So that's something that I've seen be successful as well and leveraging our hybrid model that we have. Well, I think all of us will have our own unique challenges based on what the company is or how you're building that connected to your trust teams. And I would say a framework that I just keep coming back to again and again is first solve the problem. Find a problem that's worth spending time and investing in solve the problem. Then improve your solution over time. And just get better. Like show that there's progress be thoughtful about how you prioritize how to get better and finally prepare for scale. I think that framework's kind of helpful, especially given the theme of this kind of season and push of like how do you prepare for scale. You know, it's kind of that like old startup moniker of do things that don't scale. Like I really kind of believe that in companies you kind of find the problem, solve it in a way that you truly understand it and are really close to it. Then try to improve that finds some little inefficiencies or raise the tooling or kind of processes can help you. And again, finally, then prepare for scale. And I think I think that's really kind of never let me down and thinking about like how am I planning or come going to do the next quarter. Or even as I get feedback to my team as they're taking on a new challenge. I can reason about well, where are they in this evolution? Are they like still trying to solve the problem or have they actually solved the problem and now they're looking for ways to make it a little bit better. Or are we actually out of place where we've kind of reached internal product market fit. And it's actually now like about making this more sustainable for the medium to long term. And so I find myself kind of coming back to that framework and thinking through kind of how do I prioritize what problems to take on. But also kind of how do you climb that ladder over time and feel comfortable with where you are where you don't need to scale this to get until you actually understand what problem you're solving. Awesome. That's great advice. And yeah, I think I mean, I plus one to do everything that you guys have said to. Yeah, thank you so much for joining us on the podcast and sharing your insights with us. And if any of the guests want to get in touch with you, what is the best way for them to do that? First of all, I'd just say if this type of work excites you, we are hiring for a number of different roles. So check out the type of jobs site, different roles in different different places all over the world. To get a hold of me personally or to connect, you can find me on Twitter @BlakeSamick, just my first name and last name and also LinkedIn. Same places are probably the two best places for me. Definitely plus one on the hiring. We are always growing our team and looking for folks who are passionate about product apps. You can find me also on LinkedIn. My name is a little long so bear with me, but it's Alexandra Lipinski Wilson. And I think in the podcast, there'll be something you can click into that shows my full name. So just type that into LinkedIn. You should be able to find me. Yeah. Well, first of all, thanks so much for having us, Teresa. We really appreciate it. And again, thanks for building community across this product ops function across companies. I think I've personally found really great niche here and hope others do as well. If anyone wants to get in touch with me or kind of talk more about product feedback loops or central program teams and how they've solved similar shape problems. You can find me at Dan Barber at Stripe.com. Cool. Thanks again for being with us on the podcast. Thank you. Thanks so much, Teresa. Dan mentioned it, but just wanted to echo. It's really awesome to see what you're doing for building this community across so many companies and folks that are working in this role. And it's really inspiring and super high quality and awesome. It's been a great resource for us to kind of hear some of this other stuff too. So really appreciate the work you're doing. That's great. Thanks, Blake. That's really good to hear. I mean, the reason for starting it was to share more on what people are doing in product ops and help others learn and build a sense of community. So that's really cool to hear. Awesome. Thank you everybody for joining us and listening in today. Excited to be back for season two. If you've enjoyed the podcast, please remember to like, share, subscribe and all of those good things. Take care.