Episode 128: Scaling Product Operations with Blake Samic, Former Global Head of Product Operations at Stripe and Uber

In this episode of Product Thinking, Blake Samic, Former Global Head of Product Operations at Stripe, joins Melissa Perri to discuss the evolution and importance of product operations, the role of product ops in supporting product management teams, and the strategies employed to build successful teams and improve the product experience.

Blake played a significant role in establishing and expanding Stripe's Product Operations, leading a global team of over fifty professionals. Under his guidance, the team successfully orchestrated and assisted in over 200 beta tests and product launches annually. Before his tenure at Stripe, Blake held influential positions at Uber for three years as the Global Head of Product Operations and Global Program Manager for Driver Devices.

His accomplishments extend beyond Uber, as he previously served as the Director of Product Management at Shoutlet. Blake is channeling his wealth of experience and expertise toward establishing Product Operations at OpenA.

If you enjoyed this episode, make sure to subscribe, rate, and review it on Apple Podcasts, Spotify and Google Podcasts; instructions on how to do this are here.

You’ll hear Blake talk about:

[04:23] - Initially, Blake noticed that product operations at Uber were internally focused, lacking an external perspective. The company's structure involved city teams running individual cities like startups, which worked well when they were all nearby. However, as Uber expanded to thousands of cities, communication and collaboration became a nightmare. So Uber decided to fully embed operations personnel within product teams. They hired internally, bringing experienced individuals from different cities worldwide to San Francisco. This allowed a better understanding of ground-level operations and resolved communication gaps between city and product teams. The embedded representatives ensured that city teams' voices were heard and addressed in the product development process.

[12:21] - In the early days at Uber, the company recruited exceptional operators worldwide to co-build the company in San Francisco. The first step was clarifying the mission and pillars, ensuring stakeholders understood the role of product ops. Initial hires focused on defining the team's scope and role, building credibility. Within a year, they achieved product-market fit and improved communication within teams. Uber expanded by embedding product ops in different teams. By year two, they invested in central programs like "First Class" for user feedback. Over time, they hired dedicated staff for central programs. The team grew to fifty-plus people, considering Uber's vast number of product teams.

[21:18] - When Stripe initially contacted Blake, he wasn't sure if product ops would be a good fit. However, as he learned more about their setup, market approach, and feedback management, he discovered several similarities to the scaling challenges of Uber, like the need to improve coordination between product and go-to-market teams, handle increasing feedback, and streamline operations.

[30:46] - Blake uses various metrics to measure the success of product operations and gain leadership buy-in for team expansion. The setup involves a central group building foundational systems for all product teams to plug into, focusing on the framework rather than specific features. One program example was a launch calendar that streamlined releases and beta tests, adding value to multiple teams. Metrics for these programs included usage, impact, adoption, and feedback. For embedded product ops, efficiency in betas and launches was key, along with solving quantifiable user problems.

[43:24] - When taking on the role of product operations, it's crucial to conduct thorough research to understand the organization's challenges. Next, be specific about the core focus to avoid confusion and ambiguity. Then, align funding with the business unit's budget to enhance accountability, and engage in open discussions to assess the true need and value of the role. Also, make informed trade-offs to maximize the impact of product operations.

Episode Resources:

Blake Samic - 00:00:00:

I'd say the main thing would just be, let's find this line between chaos and bureaucracy where the company actually moves as fast as possible from what we can tell. And it's like a theoretical line, but it's somewhere on that continuum where like they actually move fastest. It's not the edges of that. How do we think about that? And how do we be really super mindful about our internal users for any of these things?

Melissa Perri - 00:00:22:

Creating great products isn't just about product managers and their day-to-day interactions with developers. It's about how an organization supports products as a whole. The systems, the processes, and cultures in place that help companies deliver value to their customers. With the help of some boundary-pushing guests and inspiration from your most pressing product questions, we'll dive into this system from every angle and help you think like a great product leader. This is the Product Thinking Podcast. Here's your host, Melissa Perri. Hello and welcome to another episode of the Product Thinking Podcast. Today we Are talking to Blake Samic. All about product operations. Blake was a former Global Head of Product Operations at Stripe, and then before that the Global Head of Product Operations at Uber. Welcome Blake.

Blake Samic - 00:01:15:

Thank you, Melissa. Good to be here.

Melissa Perri - 00:01:17:

So you've had a nice long career in product management and then now more recently product operations. What made you jump into product operations? What attracted you there?

Blake Samic - 00:01:27:

I was in product management in a startup actually for a number of years. And eventually I made the jump to Uber for a totally different role. And I won't go into it too much. It's an interesting story, but I know we want to spend time on product operations. But I jumped over to Uber because I was very interested in what the company was doing. And as I joined, I started to hear some of the problems emerging of what eventually became the things that we wanted to solve with product operations. But I remember as we were discussing kind of the initial idea for product operations and what it could be at a very high level, I was very energized by that. And we could talk about that in more detail. But that's what got me excited about it. And I think some of the things that I really loved about previous roles that I've had in product management were things that I saw product ops well suited to kind of focus in more on and kind of be more of an enabler for all the product teams.

Melissa Perri - 00:02:19:

So how did that discussion start where they said, hey, here's an opportunity for you to jump over into this thing we call product operations. How did that come about?

Blake Samic - 00:02:28:

Yeah, so I was in a role at first that was all about the driver devices at Uber. Like people don't realize this, but for a really long time, Uber would give a physical phone to every single driver. There was no options really. Use your own phone. And that was a massive problem for the company as it was growing with the number of drivers that were coming on. It was a huge number on the balance sheet. Big gnarly problem. I was hired in to kind of rein that problem in in the first place. And part of that was kind of right place, right time, where I was able to have a big impact in only a few months at the company, but in a role that was sufficiently connecting with so many different departments. So I was working with operations city teams around the world that had closets full of phones and were locally negotiating contracts with carriers. I was working with the finance team that cared a lot about it, certainly with product and engineering that were developing new versions of the app for those phones. Certain executive team members as well. And I think I just kind of was in the right place, right time when they realized. They had this massive other growing problem where the company as it scaled to more and more cities, we were just shy of about 100, I think at that time, but that was on the exponential curve. We had cities growing and we also had product teams growing. And we just had this disconnect that was really growing between those groups at the company that was causing lots of problems. And so the executives in the operations side of the house and the product side of the house really knew that at a very high level, they wanted to connect those groups in a high bandwidth kind of way. And so they wanted to create a product operations team to do that. That's really all the definition they had for it. So I was tapped to lead that new team and really build it out from there and kind of really go into details of, OK, how are we going to do that? And what should that really look like? But I'd say it was in the right place at the right time. But it was also a problem set that was emerging based on the scale of Uber.

Melissa Perri - 00:04:23:

So when you started this at Uber to, what was your thesis? You looked at, here's, we got to connect these teams over here with the drivers. We got to do this over here. How did you kind of set the scope and the responsibilities for what your team was going to do?

Blake Samic - 00:04:37:

Yeah. So the first thing I would say is that product ops at the time, there was nothing that we were looking at externally. We were totally inward focused about what should this be like, how Are we going to solve that problem? And one of the first things that the company tried was to have, well, first, just for context, operations at Uber at that time, were talking about city operations teams, individual city teams on the ground running each city. And so you had a general manager and a number of people in a city that were running that city, owning the P&L and operating it like a startup and picture like a hundred of those teams growing into many more. For context today, there's 10,000 plus cities that the company's in. And in the very beginning of Uber, it was super easy for the product team and the operations teams to be really in lockstep because they were all literally at the same table in the same city. But as you had many more cities coming up, hiring brand new people into those cities and then many product teams coming up, it was just this wires were getting crossed and there was a collaboration. And communication nightmare. So one thing that the company tried was to have basically one person from one of those operations teams be kind of like a part-time member of a product team. And they would phone in and talk to that product team once a week and say, you know, here's what we think from the operations perspective, what it's really like about what you're building. Here's what we're hearing from our users in this one city, et cetera. And we found that that didn't work very well, actually, because, as you know, there's just so many decisions that get made and little conversations that happen inside a product team all the time. And it just doesn't have as much weight if you're not part of it. And so we ended up trying a model where it was fully embedded with a product team. And we actually hired folks from those city teams. So I think one thing that was unique about how I did this at Uber was almost everyone we hired was at Uber at least a year before they came on the product ops. It was almost entirely internal hires, but I was able to look across the cities that we had around the world and look for these people that met a certain profile that we were looking for. And then we would bring them and we'd embed them in San Francisco with the product team, because most of the product was being built, or all of it was being built there at the time. And so part of our thesis was, if we can just embed the knowledge of like how the business actually works on the ground and the realities of really the pain of poor communication coming out of a particular product team into the city teams. So, you know, not a lot of times city teams would complain that they don't know what's on the roadmap, or they were blindsided by something that got automated and they just hired somebody to do that. Or they felt like their voice was not heard, it would go into just this black hole that they had no idea when it was going to get fixed. Or, you know, maybe things were being built kind of from a bit of an Ivory Tower in San Francisco where the phones were all working great and the mapping was great and all that stuff where you had teams in emerging markets that were like, hey, basic stuff is just broken. Like, why Are we not fixing this? So you had a lot of that stuff that was there. I think bringing someone into that team full time that could represent that voice was part of our thesis.

Melissa Perri - 00:07:39:

So on a day-to-day basis, what did those people typically do?

Blake Samic - 00:07:42:

So I'd say like, you know, in the beginning, if we want to like talk about like how that evolved, first of all, I'd say a few decisions, I think were pretty critical to kind of making this, setting it up for success, at least early on. It was not a foregone conclusion, but I think one of them was the decision to hire people from inside Uber that like really understood the business. I think also not to hire junior people. Like we had very like senior operators that would come into this role. And in the very beginning, I'd say like the first month or two of this being a thing, and I found five or so of these people around the world that were amazing and brought them to San Francisco. But really we approached it, I always tried to set a culture where they felt like co-founders of what we were trying to do. And it felt like a startup inside Uber. And so that they, even though they were going to be embedded with a particular product team, which is super exciting and interesting for them, I wanted them to feel like we're building up product ops at Uber and like, what is this? What is the mission? What Are we going to do? And so long way of saying in their very early days, it was very open. It was like, we're going to put these very smart people with high agency into these teams. We're going to give them broad strokes of what we're trying to do, but we're going to see what is resonating with those teams. And we're going to come back and we're going to then crystallize it and be like, okay, here's our actual new mission statement. And here's generally what we do within these teams. Now that was, we've been through that for a number of months but it was great because I could talk to the leaders that were in product to get their perspective on it and work with that team to do it as well. But where we landed was kind of like three pillars of the role at that time. One was about surfacing and prioritizing global business insights. And so in the context of Uber, again, they had these city teams all over the world that were really close to riders, drivers, even what city regulators wanted and things like that. And so they were surfacing that up through the product operations person who would aggregate all that stuff and really help the product team make sense of the nuances of different regions and what was similar. So that was one big part of the role. Another was really thinking about the global viability of what we were building. This was a constant voice within the team to really push for not just thinking about shipping this feature to the US cities, but how is this going to work in the next city, in the next city? And how Are we really thinking about the steps beyond this initial beta? How do we get this to general availability across the world where it's going to have truly the biggest impact? Because you would, oftentimes product teams would ship something amazing and the team in Europe would hear about it and they'd say, when is this coming? This is going to be so great for our business. Cause they have a P&L they're trying to optimize for and there would be no answer, it'd be cricket. So that kind of thing would be a part of their role as well. And then a lot around managing product rollout and making sure that the other teams at Uber, the cross-functional folks felt like they were enabled and supported as much as possible. Now there's a lot of partnerships across all of these different dimensions with different teams that had to be in place to kind of make this work. But I'd say those Are the three pillars that each of those folks would focus on and they would focus on that for their product area. So you would have, an example would be, there was one product team that was very focused on the pickup experience exclusively. Like how do you make it just way better at the moment of pickup with someone? How do you get it even closer to where they put the pin on the map, et cetera? And so there's actually a lot of nuance to that based on the different cities and how they're set up and then how they're regulated and airports and things like that. And so you'd have one person who got really deep on that but they'd be thinking the whole time, how do I surface the insights from cities that Are about this? How do I ensure what we're building is going to go to as many cities as possible? And how then am I gonna actually manage this rollout in a way that's smart with these operations city teams around the world?

Melissa Perri - 00:11:32:

Well, so did they own part of the go-to-Market too when you did it in Uber? Was like that their GTM team in that case.

Blake Samic - 00:11:39:

Yeah, I mean, I think this was before there was more of a product marketing function and one did develop up as we went on through the top my time there. And so I think more of that like positioning and things like that. Certainly product marketers are better suited to do those kinds of things. And I think the product ops. would work through these city teams to do that kind of thing in the absence of someone that was more focused on that because it was happening anyway without this more focused effort on it. It would just be engineers directly with city teams and things like that. And so it was a helpful in between to really help that land better. And so, yes, I think like in our go-to-market motion product ops was really critical at that time.

Melissa Perri - 00:12:21:

Cool. And then how did product ops kind of involve at Uber from where you left it?

Blake Samic - 00:12:27:

Yeah, so I sat at Uber to talk about how it evolved. You know, really, you know, I mentioned how those early days we just found some really amazing operators from around the world to come join in San Francisco and to really co-build this thing together. So I think the first evolution was just getting really crisp on our mission and those pillars of what we were gonna do, getting crisp with our stakeholders on that as well so that they had a better idea of what to expect from product ops. And one thing that I did similarly at Stripe at Uber was to kind of focus on some initial foundations first before you really scale out the team and hire a bunch of people. And one super important part of that is just being as clear as you can about what is the focus area of the team and the role. And you can build some of that as you go. Like you don't necessarily need the full career ladders all in place and all that stuff yet. We didn't have that part yet, but we did have those pillars in place and we could go and start to hire folks out. But within the first year, I think we had, you've heard me talk about this before, but we really had this product market fit inside the company. Once we had this role. inside a few of those teams, and we had it more crisply defined, you had certainly those operations leaders that were saying, hey, it feels like communication's way better from these teams, and we know what's going on. And those product teams, critically, were also very enthusiastic about their partners that were there. So I think one Super important part, again, was just to have really great initial hires that could build credibility for the function. But when we had that, it was pretty easy, frankly, at that point to get some more budget to go and expand it to a certain degree. At the time, we were just focused on embedding product ops people inside different product teams. There wasn't much of a central effort yet. And so we expanded that. And by the end of the year, I think we had about 14 people total on the team. One expectation that I always set with them along the lines of this founder mentality, and we're building this together, was there was always gonna be a percentage of their time, we said 20% at the time, that was gonna be expected to be building product ops, the org stuff, or having impact beyond their individual product team. That let us do a number of early versions of what I'll talk about as central programs and systems with a portion of someone's time. That then, at my time at Uber, we went deeper into this, but certainly at my time at Stripe, it went a lot deeper into this, where you can have a lot of leverage if you do think centrally. So we started that stuff off in the first year, but towards the end of the first year, all those 14 people for a time reported to me, which is not sustainable, of course. And I remember thinking a lot about how do the best way to set up a management structure there. And I remember hearing stories, probably from people on the team already, or a little bit like horror stories from city teams at Uber, where they were like, oh, this new person got hired in, and then everybody hated them. They didn't have any of the context. And so I was a little bit spooked of like bringing somebody new in, and that probably wasn't the right thing to do anyway, but I did have to figure out which of the two people on the team should I elevate to managers across all their peers. And luckily, those two people, I think, were really emerging in their peers' eyes too. And so finding that first set of leaders was super important. That was a big transition that we made. And then I'd say going into year two, some of the bigger things that happened, we continued to grow the team in terms of the embedded folks, but we did start to lean more into some of those like central programs. One that really comes to mind, we called it first class. And the idea was, it was all about user feedback. And I mentioned kind of this black hole earlier, the feedback coming into product teams. And there was this idea that during planning, at least, we wanted to give first class treatment to the most important asks from our users, from riders, from drivers, et cetera, from all the different places around the world. And so we ran a way to really organize that input from all these different cities and regions. And so that was an example of a central program that we started to organize. But again, this was just with 20% time of people, but we were starting to like build out the credibility in those programs. And so we started to think about, should we invest more into this? It wasn't until year three, actually, that we had our first full-time hires into a central programs capacity. And I was there just about four years total. And even when we got done, when I got done there, there was, I think, only two people full-time in central programs there at Uber. And the team itself at that point was over 50 people. And that sounds huge, it is big, but I think the thing that people don't realize is really how many product teams there were at Uber. There were over 100 different ones running in parallel on different things, which sounds crazy when you're like, it's a simple app, but there were many different product teams. So those were some key turning points. And one other I'll just call out is the, we established a role called regional product ops at one point too, which was different from all the normal embedded product ops in that it was someone who embedded in a region. So there was a LATAM, Latin America. Product ops person and an India product ops person. And they would have a little bit of the flip side while they were working with it, there was an engineering team that was exclusively focused on that region. So they would work with them on the products that they were shipping. But then they were also thinking on behalf of that region, There's a lot of other products from a bunch of these teams that are building, that Are gonna end up in that region. How can they help that region be ready for that? And how can they help the voice of the region be heard? And so doing a number of those things from that angle was happening then too.

Melissa Perri - 00:17:50:

So when you left Uber, it kind of sounds like when you came into Uber, a lot of the focus was how do we get kind of these product ops people that represent almost each region or each area to go into the teams with the city teams? And then you started to standardize things a little bit more. You had central programs, and then you had these other people that were more global, regional people. When you left, were things a lot more specialized? Did you have a leader overseeing the city teams and somebody over central programs? How did that kind of evolve into those places?

Blake Samic - 00:18:23:

Yeah, so the city teams were more of a source for our team. And so we would find really amazing operators in city teams and then they would come to HQ, in most cases in San Francisco, and be a part of a product team. That person, you can think about them as being a part of that product team and then needing to represent all of operations, not just the city team they came from, everywhere, as it was relating to that product team. And then the regional part was folks that later on we said, let's have some tailored stuff for a particular region. And that was based on how engineering teams were changing and stuff too. But yes, in terms of our management structure, we definitely had a setup that eventually we got to a world where we wanted to align as much as possible to how product and engineering aligned, basically. There was, in the case of Uber, there was one senior product leader, one senior engineering leader across all of what was called rider. There was another one across all of driver, and then another one across all of Marketplace and some other things. We would try to have a manager from product operations that would align to those leaders as much as possible so that they could really think even more deeply about what does the rider team need from product operations, what does the driver team need from product operations, and then bring that back to the central organization.

Melissa Perri - 00:19:44:

Cool. So now I'm getting it. So it's like, we don't have a representative from each city team. It's like, we pulled a bunch of people that were really smart out of the city teams and they would go out to all the city teams and then bring back that collective feedback and customer research and what our people were doing, what our drivers were doing and what they needed in each city.

Blake Samic - 00:20:02:

Yeah, I'd say feedback and launching products, helping make sure that I was smooth. But then there were also some interesting cases where you really saw how having them there really increased kind of the leverage of everybody. Like one example I really love was, Uber Pool, which was the ride sharing product that we had where you had multiple people in a car, pre-COVID kind of thing. Maybe it'll come back one day. There were a lot of experiments that team wanted to run to really optimize that product and it was a super competitive market. That product team had a certain number of data scientists that could work really closely with them to really run these very tuned experiments. But they had this huge list of things They would love to try. Because the product ops person was there and was so well coordinated with city teams, they were able to run a bunch of other experiments locally with the city teams just running it on their own because we were confident in them being analytical enough and having background enough. Many of those city team people came from consulting or investment banking and again, really high caliber folks.

Melissa Perri - 00:21:03:

Nice. So it really enabled them to run these experimentations a lot better too.

Blake Samic - 00:21:07:

Yeah, so it helped that product team learn that much faster and not have to rely only on these one or two data scientists that They had sitting in San Francisco.

Melissa Perri - 00:21:16:

That's awesome. Cool. So Uber is kind of an interesting structure because we've got so many people all over the place. We've got riders, we've got customers getting in there, you're global. When you came to Stripe, were there similarities that you saw that you could pull from Uber? Did you kind of approach it in a different way? Because now we're more in a B2B platform. We're in almost a banking platform. So how did you kind of approach product ops when you started at Stripe?

Blake Samic - 00:21:43:

When Stripe first called me, my initial mind was like, I don't know if product ops makes sense there. It's not exactly how I've been thinking about it in the Uber days, but then, as I got to talking with them and just understanding where they were, how they were set up and how they product to market, how they dealt with feedback, I was like, oh, actually, there are a lot of similarities to the problems that they're seeing as it relates to just scaling tech companies types of problems. I think it just naturally puts pressure on the connection between your product teams and your kind of more go to market or compliance teams as you're shipping more things in parallel, you're hiring more employees, you have more of this feedback coming back through weird channels that no one is kind of streamlining and standardizing. And that all just sounded very similar. And the company was expanding globally. They didn't have presence in every city like Uber did, but certainly in many different countries, many HQs in different regions and things like that. another similarity I'd say is that they really were and still are both companies, super ambitious like product engineering. culture and say like what they want to ship a lot. They want to ship a high quality product. Stripe in particular, I think just like has a huge high quality bar and all this. So a lot of similarities. And I think there are many similarities to how I thought about setting up product ops and some differences for sure. I could talk to both or would you prefer just the differences?

Melissa Perri - 00:23:07:

Yeah. Let's talk about where did you start at Stripe? Tell us about when you got in there. You've got buy-in to do product ops. Obviously, they brought you in. What did you do to look around and figure out what they needed?

Blake Samic - 00:23:19:

Well, first of all, I think when we were talking even in the interview process, I thought that they were thinking too small about it first, frankly. I think they thought they wanted to have just this connection with their customer support organization and make sure that they were ready when things were launching when clearly there was opportunity to make it much bigger, much more impactful to connect in with sales and account management and customer support and legal and all these connections. So that was one thing early in the process that we talked about, but they were bought into that as we started talking about it. I was the first hire in product ops there. And luckily, there was this really great person, Amy Mente, who was doing effectively product ops, pretty close to what I would say is product ops in an embedded function with one of our major product areas. And she came onto my team pretty quickly into my time there. And so I got to work with her. She was a very long time Stripe too, which there's a lot of benefit in just understanding the organization. And we got to work pretty closely early on on that. I remember. actually going pretty slow on purpose in the early days of my time there. The first couple months, I was really having a lot of conversations with the different adjacent functions like product management, product marketing for sure, and customer support. I was kind of surprised. I thought product management function there was not as advanced as I expected it to be. At that point, it was certainly when I left for sure, but like the early days, there wasn't even a PM across all these teams. I thought we should have a PM and they were already starting to think about product ops. So I was like digging into that and then worked really closely with a partner in products marketing who was really great too. But I think it forced a lot of good discussions about what are the core responsibilities of these different roles. And even this new role being created at product ops, I think forced those other ones to define their own roles a little bit better than they had. And that's one of the things I think product operations can do even outside of its own role is like to help the organization just be clearer about like, okay, who should do when and that kind of thing. But early days having those conversations, really trying to figure out what was the same about Uber, what was different, how would I do the similar playbook, but just like what were the biggest burning needs. So really established a charter documents and got a Stripe as a major writing, reading culture, which was cool to be a part of, but like really wanted to get that in front of a bunch of people and get some feedback. So I remember just being feeling kind of slow. And even my boss at the time was like, are we going to ramp this soon? And I was like, just hold on, I've got a plan here. But by getting that charter in place, by really nailing down, like this is the JD job description of the type of person we're gonna look for, here's the type of team that we're gonna build. doing a bit of a road show internally, that really paid dividends to go super fast after that actually. It felt slow at first, but even at Stripe, we grew even faster. We were about 18 people after the year one. We were just like two people for like two months, but then we really scaled fast. One of the key differences there in terms of my hiring strategy was to not do the exclusive thing of only internal employees, but to have a mix. And I think one key difference that I just recognized was now we're about four years later than when I did this at Uber, and product ops is more of a thing in the industry. People know what that is. There is actually people with experience of things like this in different places. So we could really bring in really awesome folks from Airbnb and Google and Apple and some former product ops person, people and some former PMs actually that wanted to kind of move into this type of role. But those were kind of like the initial starting point. It's like find someone that could start to get credibility for the organization that could be embedded. Luckily we had so many greats that was there in place, build out this central charter so that you could communicate, here's what we're gonna do and kind of get that going. And then the one other big change that I made that's different from Uber was investing much more soon in the central programs aspect of it. So even after that first year, we had a lot of embedded people, but we also had the person who would be our first program manager essentially who then led that organization, Dan Barber. He was fantastic and got him on board. And then even by that first year, we had the first couple managers emerge from the IC role. So we had Rohit and Alexandra move into those roles and really felt pretty set up actually to kind of go fast after that with a really good solid team.

Melissa Perri - 00:27:35:

So with this too, you just mentioned that you had 18 people by the end of the first year. And it sounds like when you came in, they were thinking about this kind of like more narrowly, a little smaller. How did you get the buy-in and convince people that you need to actually scale this team and get additional headcount?

Blake Samic - 00:27:52:

So I think the way that I would communicate that and make the case for it is a bit different when you're just starting it up and then it's a bit different as you're a little bit later on. I think just starting it up, frankly, I'm really heavy on the storytelling and the qualitative, here's what we could do, here's a bunch of examples of things that I've seen work in the past. Really identifying pain points of the product organization and kind of those adjacent functions as well. So a lot of those early conversations made for great fodder for that. So I would be talking with them, but taking very detailed notes and really understanding what are these major pain points that they're having, what seems like it's more of an operational thing, what seems like it's just a streamlined communication thing and just getting a really good inventory of that stuff. And then I would really match up some of those examples from the past with those things and be able to tell a story of, this is where I see some initial value that we can have here. Hopefully, even during those conversations, there's some quick wins that you can point to as well. Sell a vision of what this could be, to be honest, probably not a vision of as big as what it was. Sometimes the organization, the org would reject it if you're saying, I wanna build a really huge team, which really wasn't my intention necessarily there. But describing how I had done this in the past, describing how I saw this being something that could unlock a lot of impact for Stripe and then starting small. So starting small by embedding with this one team, showing results from that one team, doing enough of the research to say, here Are the next four teams that I would embed in based on how much product they're shipping, the complexity of those. lease schedules, like how much feedback they have coming in from different angles. There's a number of signals that we could look at to say like, this is where we think the highest need is for embedding. And then on the central program side, at that point in the startup, we didn't quite have it yet, but really kind of planning to bootstrap a lot of those programs and be really scrappy in the early days of that. But I think we could talk about how that works, but I think that's really important in the early days. The, you know, when you go and you're trying to get more head count later, I think the conversation is a bit different at that point. It's like, okay, like how, what's real talk, how big is this team going to be? How does it scale with, with what thing are we looking at and how does it scale? You know, is this scaling with the number of products that we're shipping, with the number of PMs that we have, number of engineers, like rightly so, the, whoever's writing that check wants to know how does this scale and is it going to be above or below that curve for the money coming into the business and are you getting efficiency? So they're really looking for that and showing how you are getting efficiencies, being super crisp on the roles and responsibilities and showing the examples that are there, talking about how you are already putting metrics in place to know what's working and what's not. And that could be for the central programs aspect as well as the embedded aspect, but those are really important aspects that you're going to ask for more head count.

Melissa Perri - 00:30:46:

So with that too, what were the kind of metrics that you were using to measure success of product operations and get buy-in from leadership to get more people?

Blake Samic - 00:30:56:

Yeah, so I kind of split up my mental model of always how we were set up was we had this one central group that was really building things. central systems, if you will, for really all product teams to plug into. So it's not about any particular product or feature. It's more rails of how that works. And I'll talk about the, how we thought about measures of that kind of thing. And then we also had people that were very embedded thinking about one particular product. Like how do I take Stripe terminal to market and beta test it and things like that. And so those measures were a bit different. On the central program side, the shape of the programs that we were talking about, in some examples would be that we built the launch calendar for the company to see what all is launching when, what's going into beta when, what's live where, these kinds of things, and be able to really filter through the noise and see the most important stuff that was coming. That was one system that we stood up. And we ran a program around that to ensure that the information was up to date and that teams were getting what they need out of it. And so there was a number of examples that were kind of like this, where it's something that adds a lot of value to lots of teams, product teams, but also the go-to-market partners that are there to see what's happening. And it would be way less valuable if you had any product team just kind of do their own version of that, because that was what was happening. You have one version of that in Google Sheets and another one in Google Slides and paper docs and different places to centralizing. It was really important. But for metrics of that type of program, we really think about those programs as almost like hygiene. Like they're not meant to end. Like once you put that in, you want them to be operating at a quality level that you set out to get to. Some of them do get sunset at some point, but it's not like a program that starts here and ends here and then you're done. Typically it's like, okay, well, we have a launch calendar and we're gonna continue to have a launch calendar. And so you're looking at things like, if that was a product, we thought about like an internal product really. How many people Are using it? From what different functions, how often are they using it? When you ask them if this is gonna go away tomorrow, how upset would you be? Like these kinds of like things. So almost like typical product things that you would look at to measure success of those programs. And with those, you wouldn't always have like product market fit in every part of the organization at one time. You might have that like really working and resonating well with one major product area, but another one is not using it at all yet. And you have to constantly be thinking about strategies to be like, okay, how are we gonna get them excited about this? What view of the data can we give that leader to see this so that they don't feel the need to go do this on their own spreadsheet. But it's those kinds of metrics, like how well is this working, but really focused in on the particular programs that we're talking about. I mean, it would be a similar shape metrics for each of the programs. So there'd be a metric around usage, a metric around impact, adoption, these kinds of things for those programs. And then for embedded product ops, it's a different mental model a little bit, but really that group is really thinking about taking individual products to market and really synthesizing the feedback for individual products and product teams. We would look at things like the efficiency of running betas and launches. We really wanted across the board to get more efficient on that. We could tell if someone was leveraging the playbooks that had already been set up or if they were just starting from scratch on these types of things. They shouldn't be big creative exercises. Those should be things that are standard operations that we are moving towards. And so trying to figure out how efficient are we getting on those things. We would look at quantifiable problems that were being solved for users. And so a very quantifiable thing would be, did that product operations person influence a solution that got on the roadmap that maybe solved a problem that was causing a large support volume over and over, which costs a lot of money, it costs a lot of user pain, these kinds of things. And then, of course, we had feedback measures regularly from their key partners in product management, engineering management. But PM was like kind of their key partner, for sure.

Melissa Perri - 00:34:51:

Cool. So with this too, at Stripe, you just mentioned that you did start with centralized programs. So you started with that. How did you figure out what to centralize? Like what should be a centralized program, let's say? And maybe how did that differ or was similar to some of the central programs at Uber?

Blake Samic - 00:35:11:

I'd say, well, one thing is we just, I didn't go nearly as deep into this at Uber. There was like one or two central programs that we did there. Like the top user asks, the first class thing I mentioned was one of those that a comparable program at Stripe, but really just went a lot deeper into it at Stripe. And one thing I would just say is that it was always super important at Stripe in particular, as we were going and setting up some of these programs, that we were very mindful about. what benefits are there at centralizing something and telling people how to do anything really. And like, for example, we would never tell a team like how to run sprints or even should they do sprints? I don't know, like you do your thing. You know, like it wasn't that, but it was more like the situations where clearly many teams were going to be interacting with each other. Like, you know, all these product teams were building something that sales team would need to go sell. And it was probably the same sales people that would need to sell stuff from each of these product teams. And so they should probably communicate that the same way into sales. And so setting up those types of systems was a bit more of the type of thing that we would really lean hard into. We would think about what are the things that really are applicable to all product teams? It would really try to think about, does this help this product team feel like if they put a dollar into this system, they're going to get a dollar 10 back? Like they're going to get something for this. It's not just the machine asking them for more information, but it'll unlock certain things. And so an example with the launch calendar would be if you use that, it could auto trigger certain types of meetings that you would need based on the shape of your project with the legal team and the security team and other teams that you wouldn't have to go into some separate intake process to get. So it would actually save you some time. And like we would be looking for those types of opportunities a lot, but just I'd say the main thing would just be let's find this line between chaos and bureaucracy where the company actually moves as fast as possible from what we can tell. And it's like a theoretical line, but it's somewhere on that continuum where like they actually move fastest. It's not at the edges of that. How do we think about that? And how do we be really Super mindful about our internal users for any of these things? We would sunset some of the programs that we would set up. Oftentimes if we were even standing up a program in the first place, it would replace three or four things that people were doing differently that we're kind of trying to get at that, but they weren't really thought about and designed centrally from a group that was trying to think across all of us. And so those Are the types of things that we would think about as we were setting up central programs.

Melissa Perri - 00:37:46:

So I've heard some detractors in the past kind of talk about. Why do you have to standardize things? Why can't product managers just do them themselves? Why do you need a product operations team? Can't we just be doing this ourselves? I mean, you've been at two very large organizations running this. What's your response to that? Why do you think it's not something that just product management can take on and it needs somebody else?

Blake Samic - 00:38:11:

I'll take one of these examples, right? If we say, hey, everyone here agrees that it would be great to just see one place where everything is launching. And then it's like, okay, well, who's gonna take that on and really think deeply about that? It could be, I mean, the CPO cares about that. If they feel that as a problem themself, or if they hear from their leaders and go to market that it's just a major pain point, they feel that as a problem. And so maybe they're like thinking across all this. Maybe they tap their more senior products leaders to think about it as well. And maybe someone even goes so far as to write a proposal document about how this should work and like starts to get people on board with it. And that's kind of as far as I've seen that go without like much more of a focus on it. And frankly, being able to like do a lot of like really scrappy stuff to like one, get it started and to keep it going. I think it's like, you're not gonna have that very certain senior product leader that is combing through all the disparate types of roadmap docs that exist today and like doing a bunch of work to put it in one place and then just take a first pass at normalizing that. But sometimes like that kind of activity can be super illuminating if you can just get it into one place and have everyone and see it. So I think if it's like these types of things that people agree are important, the very senior leadership agree are very important. They would give a lot of leverage but it always falls a little bit down the priority list of certainly a product leader who is ultimately just trying to make sure that product market fit is landing and that business customer needs are aligning. And like, they don't wanna be so concerned with some of these rails and things like that to be set up much more than like a quick sprint conversation but it takes more than that to kind of do it really well and keep it going really well and have that active focus on it. So I'd say that's one way that I think about it. another is just like these situations again, where it's like when you're in a company like that, you're not only shipping more products, you're shipping a lot of information and it is like, you're shipping it internally to your company, you're shipping it to users and it can be quite randomizing if you're not full about how to not just make it transparent but like make it accessible in a way that's coherent and the same and again, I think having somebody think across that, partner with people, get a lot of feedback on it but kind of run it and make sure that it lands in a good place is really important. I've seen some of the other like detractor arguments for sure and like agree with a number of them. You and I have chatted about, like I don't think product ops is at all taking the place of like good coaching for product managers. Maybe they have the inventory of the playbooks that are really helpful and like the systems and tools and things like that but certainly more senior product people should be doing that with their people and that's like a people management leadership thing for sure. So I don't think that makes sense. I don't think that in setting up those kinds of rails central programs either that the product ops people should be gatekeepers for this kind of thing. It should be more, they're ensuring the system is flowing the information as it should but they're not saying everything needs to come through me. maybe they're working with folks to say, here's the right way to submit feedback and things like that, but it's still all going into place that's very accessible to the product managers and others, and actually way more accessible than what they had before. By doing that a bit of extra work, it's almost, if you're familiar with cooking, it's almost like mise en place with all the stuff that the product manager might need to know. It's like, how can you get it into a place that's much more easy to look at? But I don't think they're taking the place of product managers in a lot of these cases. I think, at least the way that I've set it up, that the product managers are very appreciative, and that they really like having this partner do these things. But I also get some of the criticism of the different setups. I think you're referring to Marty Cagan's post, which first of all, I'll just say I have a ton of respect for Marty. I had one of the books that I read probably 15 years ago was his inspired book that got me very excited about coming into product and was so cool. And it was interesting to hear him take a bit of his take on product ops and have a good follow up on it. But as I've read his initial blog post and his follow up take, a lot of it I agree with, frankly. A lot that's there and my thinking has even evolved on the role as we've gone forward.

Melissa Perri - 00:42:25:

Yeah, I agree. We were just talking about this before we were recording, but I think everybody, people still come up to me and they're like, well, what do you think of Marty's thing with product ops? And I'm like, well, his follow-up was right. Like it's not just about a bunch of process people or this role doesn't take the place of bad product management, right? It's not stopgap for bad product management supposed to enable better product management. Totally agree with him with that. I think he's just seen a couple of instances in companies where they're not doing it right, like you're describing.

Blake Samic - 00:42:53:

Yeah, I think so. Just good. There are a lot of flavors out there for sure. And like people have different ways of setting it up. And I think there is a certain condition of the rest of the company that makes it work really well too. Like if you are working in a company that isn't taking, you know, is like a feature factory kind of product management type of place, then like this probably won't work super well there. But if you are a place that is like really trying to build super innovative stuff and recognizing that you need to solve problems along the way and your roadmap needs to evolve, then this can be a super helpful role to really empower products.

Melissa Perri - 00:43:24:

For sure. So you've built this function now up from the ground twice, right? Like you've been the person in there leading the charge. What's one thing you'd advise somebody in an organization who's taking on this role for the first time? They're like, I have to set up product ops. looking back at everything you've looked at, what's one piece of advice you give them?

Blake Samic - 00:43:46:

One piece, I'll give. I'll give two quick ones. So one would be, I think just be, do your research, like understand the problems in the organization, and then be very specific about what you want the core of product ops to be. I think you can end up hiring people who are generalist, jack-of-all-trades people, which is an amazing profile and maybe one that you want, but it's just going to cause you headaches when you go to talk to other teams or explain what this does. If you just have a situation where someone can just kind of come in and do anything, like they'll do that sometimes, but you need like two or three things that you can point to to be like, this is what we do, these places just to help with that internal messaging. That's one thing I would say. another would be one thing that worked quite well, I think it's Stripe. was that we eventually we made a change to align the funding model for the role much more closely with the called the business lead function or the general management function across a business unit. So that person would have a number of functions reporting to them, but they would really have a P&L that they were owning about a particular product. And for a long time, product ops were embedding there and we had the budget for product ops set centrally. It was a really good change, I think, when we switched it to say, actually, if you want a product operations person embedded, it has to come from your budget. And here's how to reason about that. And it was an interesting transition for us, because it was almost like you're kind of going from a free product to a paid product with these different teams, if you think about yourself as an internal startup. And we didn't know, were they going to continue to pay for it? Because if they're getting it for free, of course, everyone's like, I want more product ops people. They're just like, they're saving all kinds of time for my PMs. They love it. I want more. And we wanted to put that to them. But it makes them really think about it hard to say. Okay, how much do I need this role as I do a trade off, kind of open eyes with another PM or engineers even, and like really think about that. But I think once They do have to think about that, it makes them even more aligned to the success of the role.

Melissa Perri - 00:45:57:

This was something kind of, you said this before and it made me start thinking about it as you were talking about aligning back to that budget. You said that we have to think about how do we scale product ops and how is it going to scale. Is it going to scale by like engineering headcount or is it going to scale by product manager headcount or whatever? What's your advice on making sure that you're not hiring the world? Or if you have too few people, it could go either way. How do you think it should scale? What are the things that you look for?

Blake Samic - 00:46:24:

So I think my intuition, I mean, again, there's lots of different nuances with different companies, but just my experience will jump me right to central programs first. So the first thing I would almost always recommend is that you really think about how can one person, maybe two people, one person to start, think about streamlining these central information flows. and things that you just need to do to kind of like connect your different functions and your product teams. And like, how can that help the day-to-day of product teams be better without focusing in on one particular product yet? And so I would focus on that first. That's inherently much more scalable if you can like make improvements that improve all the product teams' livelihood or improve much of stuff for go-to-market. So I would focus on that first. And then I think as you're considering having embedded product operations people, I would think a lot about just like, okay, what are the other roles that you have and what are the core responsibilities of those roles and what is it gonna do if you introduce this new one? Because again, you don't wanna create a situation where it's like a product ops person comes in and really a PM should be doing that thing that they're doing or some other role should. And so you wanna go into that open eyes and think about that. But as you think about, ratios and things like that that make sense for this. I have not found it to be that helpful to say there should be a clear ratio with product managers. Some people say one to one or something like that. I think it is more about, really taking a hard look at it. You're putting a framework together to say, these are the signals that we look for that help us bubble up certain things over other things that might need an embedded product operations person to accelerate. And so it could be your framework might include things like, how complex is the rollout for this product that we're doing? Or how many things is this product team shipping in this six months? How many users are using those products, and how often are they submitting feedback? How confusing is it for the engineering teams right now, because the feedback comes in via Slack and email and Twitter and all these places. Those types of things can help something bubble up. And I think you always want to stay lean, too. I think you want to always be lagging the need on this and just be really thoughtful about the priorities of these different things. And the smaller you stay, the leaner you can be, and the more flexibility you can have there. Once you get to the point where you have managers and lots of people underneath them, there are benefits to that. Like you can, if you get to that point, you can have that person be super focused on one particular product area or business unit, be a very clear partner with that person and have clear delivery there. But it also gets harder to move those people around to other product areas if you need it. I think that's a trade-off. But I would say I look at those types of signals more than just saying one-to-one to PMs. Now, on a very complex product launch, that's Super high critical thing for the company, one-to-one probably makes sense. Like having a product operations person, one-to-one makes sense. If it's things that Are less complex that could use this kind of support, I think you could have someone that's supporting many different product initiatives at once, but you do lose some of that context. Like if you need somebody to be really deep on the product and be able to represent user voice on it, that breaks down if you have them do that with more than two or three different products basically.

Melissa Perri - 00:49:45:

Yeah, definitely good advice. So like when you left Stripe, too, speaking of scaling, you said you got to 18 in year one. How many people were there when you left?

Blake Samic - 00:49:54:

Yeah. So that team grew considerably as well. And so overall the team, which comprised the central group and then embedded as well, I'll just kind of talk about them together, which is kind of the full picture of my time there. That was about 40 plus at the point, like just over 40 total. And the mix was a lot different from Uber. So like Uber, you know, was a slightly larger group, but it only had like two people that were on that central programs side at Stripe. It was around seven or eight that were on that central program side of the 40 plus. And so you had more of a mix there as well. So I think that was one difference, but still quite a large team.

Melissa Perri - 00:50:30:

Yeah, definitely a large team. That's great. So you've been in product ops now at Uber since 2015, then you moved on to Stripe. You've seen it everywhere. I know you talk a lot about product operations too. What have you seen change in the product ops community and product ops in general since then?

Blake Samic - 00:50:49:

Yeah, it's a good question. I think just thinking about that timeframe, one thing that I've noticed that's different that I've seen in my time at Uber and Stripe is that not everyone on the team wants to be a product manager. It's like one thing that I've noticed, I think. And the Uber days, it was like most people saw it as a bit of a stepping stone into being a product manager, which is great too. I mean, you can do that. And we had 20 plus people make that transition, which was a cool path. But I remember that just being like a constant conversation about, okay, how do I get there? What is different about, you know, that kind of thing was just different. So I'd say I was kind of surprised, but as the industry has evolved and like as people have seen this as an interesting opportunity, more people really want to build a career in product operations. And so people were interested more so to know how do I get promoted within product operations? How do I become a manager of product operations folks? I still think it was super important to have career paths that could go outside the team and be a producer for other spots, but that was one big difference. I'd say there are many more examples of product ops as we've talked about at different companies now, and you really have a range of flavors of that definition. And so that's a good and a bad thing. I think you have more people who are doing exactly what you're looking for or adjacent to it at these different places from a hiring perspective, but then you also have some potential confusion in the Market. I think, you know, Marty had great posts about this, about just different types of ways that it's being set up. And so that's not exactly perfect now. I think you're doing great work out there talking about it way more than I am about what it could look like and how to set it up to be like a superpower for product teams, which I think is awesome. But I'd say those are like two things that I've seen change a lot in those years.

Melissa Perri - 00:52:31:

Cool. And where do you think it's going to be? What do you see for the future of product operations?

Blake Samic - 00:52:38:

You know, it's a fantastic question. And I'm really curious what you think about this, but you and I had chatted a little bit about this ahead of time and thinking about all the companies that have something called product operations now. And if we said that's 20% of companies have something called that, we'll just say, I don't know if that's the number, but like, it's that number. What would that look like in like 2025? Is that percentage growing? I think if you just talk about larger companies first and you say, okay, these are companies that are building multiple products in parallel and they have kind of more complicated stakeholder relationships internally, I think the percentage is definitely gonna grow for those types of companies. I think if that's 20% now, I could see it doubling potentially in five years. I could see that growing a lot as people see the benefits of that. I also think that there's going to be many more small companies in general. If we take the total mix of companies that exist in the world, I think many more are gonna be small. A larger mix will be small than today. And I think there's a number of like enabling disruptive technologies that Are making that something that's gonna be a thing. Generative AI is a major one that I've been thinking a lot about since my time now. And some of the autonomous agents and things like that that can be a part of that. But also the no code tools and things like that that have evolved. These kinds of things I think Are just gonna really arm one, two, very people, small groups to really deliver a lot of value for their users with a really small group. So I think that's gonna happen. And I don't think that kind of company will ever have something called product ops in title. Certainly there are things that they could learn from some of the ways that things have been set up there. And then we also talked about what does product ops look like? If we think about those larger companies as an example, I think more of them will have something called product ops. But I do think it'll look quite different. I think it'll skew more into the Central Rails stuff. I think it'll be really helping to set up systems for your company. And oftentimes using some of those tools I just mentioned to kind of do that in very efficient ways. They're gonna have more automation for those systems, better observability on these things, but they're really gonna still be helping products managers, product teams have more leverage, but I don't think they're gonna have to be as hands on themselves running that particular product through those things, but more. ensuring the systems are streamlined and working really diligently with those tools at their fingertips to set that up, but also put those tools into other people's hands. So I see more of that, but Still like to focus on information flow being a major accelerator for a company. If you can like get that right, make it accessible, make it transparent and be really thoughtful, almost like a librarian or a map maker or something like that, just like those kinds of skillsets I think will be important in that type of role.

Melissa Perri - 00:55:31:

Yeah, I totally agree. I think we're gonna see a lot more of the centralized areas in the scaling companies. I believe like a bunch of tools will come out for those embedded pieces. Like we embed data and insights into a bunch of companies, into a bunch of the product teams as well when I've done it in the past. And honestly, it's because the data and insights they have is just so poor, right? Like we need somebody on it to help like pull out that information, create those reports, be able to track our OKRs, all that stuff. It's like if you did actually have a tool that did that, you wouldn't need that person there full-time doing this all the time. So I do see some of these parts where if we approach it though from a global standpoint, like you're talking about with those global programs, then we would say, hey, let's actually get a tool in here and we can have these people embedded until we like figure out how to help people do themselves. So I feel like there's a lot of power in those global areas. The other thing that I've been thinking about lately too with product ops is like, I think I agree with you. Like I think it's always gonna be something at a company of some scale. And I do think that scale can happen at like mid-sized companies as well. It's just probably don't, you don't need it at a startup. Like I think that's what we say. But the more that I talk to bigger companies, and especially ones that are like going through transformations, like we've talked a lot about Uber and we've talked a lot about Stripe in this episode, which has been great. And I think those are good companies to look at as like a good gold standard of disruptive technologies that a lot of people want to aspire to. But you've got a lot of the companies that have been around for a long time that are transforming more into software companies, let's say like your banks. And what I'm seeing is that they're realizing that the business part of the bank and the product part of the bank are starting to merge, right? Like they're starting to become one thing. And that's how Stripe operates, right? Like that's how a lot of places that started software first operates. And now these companies are catching up. So you have to think about it. Like, would you ever like poo poo operations for running your business? No, right? Like I think we'd all agree that it's good to have that, those foundations and those global programs and the stuff we're talking about to help people run their business better. And I think that business is gonna look a lot like software product management in the future with a lot of that subject matter expertise baked in. So I don't see product operations. going out of style anytime soon, I think it's just going to become more and more important as those mergers come together.

Blake Samic - 00:57:53:

Yeah, I think so too. It'll be at a different scale at a company like that, but it's like, it's a similar set of like evergreen problems that you're kind of thinking about. And just kind of rereading some of the posts from Marty that we were talking about, he mentions in there some of the stuff that in some of the flavors of product ops, these are problems that have been there for decades and people have been working on it. It's been called different names. And like, I don't doubt that. I think it's true. And it's, you know, sometimes you can package and like more efficiently attack them and like more efficiently think about them for an organization. And I still think that's gonna be really powerful to have a small set of people, lean group that's like really thinking about that for company. To really think about how is this gonna operate better together, all these different functions in this more like product led world that we're moving towards. But it is true. It's like business and tech together.

Melissa Perri - 00:58:46:

Yeah. I think that's going to be a really interesting future to watch. So I'm pretty excited about that. Well, thanks so much for joining us, Blake. This has been really great to hear all about your experience and your thoughts on product operations. If people want to reach out to you, I know you're doing some consulting and advising right now. Where can they find you?

Blake Samic - 00:59:03:

Yeah, thanks for having me. The best place is just to reach out to me on either Twitter or LinkedIn. I'm just Blake Samic on both of those places, which is my full name. That's the best way to connect and to maybe work together. And I'm excited to meet more folks from your audience.

Melissa Perri - 00:59:18:

Great. Well, thank you all for listening to the Product Thinking Podcast. We will have all those links for Blake in our show notes on our products labs .com website. So definitely go to productthinkingpodcast.com, check out our show notes if you wanna learn more about Blake and we will see you next Wednesday with another Dear Melissa. So this is a reminder to get all your questions in and I will be answering them. We'll see you next Wednesday.

Stephanie RogersJuly 19, 2023