00:00:02

Hello everyone. Uh, my name is John Cutler. I'm super, super, super excited to be here. First DevOps enterprise summit. Um, I actually kind of feel this is my tribe and I've just found them, which is really good. Um, just a little bit about me before we get started. I think it's helpful to get context about where someone's coming from. I have a background in product management, UX research, um, some business analyst, uh, roles, some music and some startup stuff. And I worked in a PowerPoint factory in New York and investment bank, Morgan Stanley, uh, where you were counted by the keystrokes, um, building road shows. Uh, so yeah, I've done. I got kind of a late start to this. Um, one thing that I'm fortunate to have experienced, I think is that I sort of swim between a couple of these communities and I'm not sure exactly how that happened, but you know, I'm, I'm, I'm, I make fun of people just equally.

00:01:01

So it doesn't matter whether it's through the agile folks or the lean folks or the product management folks or the design folks, the dev ops folks, the service design folks, and now I'm on a marketing team. So of course I can make fun of marketing a lot. Uh, so I do work at a company called amplitude. I'm a full-time employee, amplitude amplitude does, uh, product intelligence, product analytics. Um, we have a couple of fortune 10 customers and massive long tail of startups. Uh, and the, the product is focused on helping, uh, cross-functional product development teams, uh, get insights to improve customer lifetime value. So it's very much the reason why I like the role. I don't actually sell the product. I'm not an evangelist in that sense, but I'm evangelizing the surrounding environment, which makes a product like that. Just something that you would do if you don't have a choice at that point, whether it's us or someone else, you're gonna need something like that.

00:01:51

Um, interestingly, we have two personas at amplitude. One is called the pioneer, no relation to Simon Wardley pioneer settler town planner. And that's this idea of this passionate product manager who wants to get insights. But then the second persona is what we call the architect. And I would actually say you are all the architects. So these are kind of early adopting, uh, engineering leaders who don't want to build that. And they see that there's a good product out there and they actually become our advocates internally. They've got more important things to worry about. So, um, I'm speaking to you today because of that, they let me out for two days to come to talk to the weird community of the second persona. Um, I write a fair amount on medium and I do use Twitter a little bit where it now with a child. So that's Julian, that's my, um, baby. Uh, of course the second I left the car broke down. Uh, they shut down the power in Santa Barbara because of fires and the daycare closed. So the second I get back, cause I'm going to leave early. I will be handed the baby. And so I'm looking forward to that cause I'm missing. Great. Let's see. So the phone thing advance, but that did not.

00:02:59

So we'll just use the thing. Um, so back to this, I'm a huge, I'm, I'm an obsessive watcher of the DevOps enterprise summit videos. And so Matt Skelton, who always jokes that every month, I recommend his same talk over and over and over again on, I feel like I'm an early adopter of Matt skeleton cause I was there really early and I kept pushing it. Um, but, but I always found these talks to be the most interesting because they're really fascinating. And these are large companies doing really big, bold things. And um, that's where the really interesting stuff seemed to be happening. You know, you can build an app to deliver burrito fairly easily, but certain things, um, like helping countries or banking and stuff is actually pretty complex. So I felt that this was an interesting community and I've been supporting it. I met with Jean on, we did, I did a preread of his book and I got to talk to gene and he said, you should, what's your ask everyone hasn't asked, so I want to be here.

00:03:56

So that's why I'm here. Um, so I have a couple of questions just so that I know a little bit more about you so we can kind of get going, um, who has a title of product manager, product owner or technical product manager at TPM. Okay. So maybe seven, 6.7%, uh, who doesn't have that title, but who thinks that they totally do it anyway and actually they don't even want that title, but they do it anyway. Ah, all right. The accidental product, not the accidental, but the sort of rogue. You don't want that title. Cause I'll be your curse after that, but you're still you're doing it. Um, who collaborates with product managers POS or TPMS every day, day. There you go. So I don't even need to do week and month and quarter because about 80% of people said they were collaborating with some product manager daily.

00:04:48

That's really, really, really amazing. And I get to get to skip that whole part of the question. Um, thinking over your careers, what was a defining trait of the best product manager you have ever worked with? You can just shout it out the way clear, thorough. Any others go? Just shout it because the people next to you, I've heard these so that people can hear them cool, more and more enlightened. That's hard. And it's like, we're all on the Siddharth. I didn't hear you on the quest. That would be a great talk by the way, the Siddharth of thing to product managing. Um, so we heard some things they're, they're, they're thorough, they're diligent. Um, they, you know, maybe connect with customers. There's different things, um, who has been told you need more product thinking in your organization. Okay. Uh, who's told that you need to call everything a product.

00:05:44

That's how you can get a budget. All right. Got that thing. Uh, whose, so anyway, I could go on with these questions. I'm getting a good idea. Actually. I was surprised that some of the things I can change some of the topics, um, the one thing that you find you're collaborating with anyone cross-functionally and I really like Amy Edmondson's description of it as she calls it professional culture, clash, not necessarily culture clash or not, you know, I'm thinking style clash. I mean, she really zeros in on professional culture, clash, different values. We have, uh, different, uh, timeframes we're used to working in different language. So there's definitely a professional culture clash situation with a lot of product folks. And, uh, it does cause a lot of confusion question for you. Um, what, what is one word that seems to just confuse everyone that everyone uses?

00:06:37

You can shout that out to dev ops value value stream. Yeah. So there's lots of words. One that I like, um, is NVP. So now we can play the secret decoder game. So let me use my secret decoder key for you. Success, you have now solved the problem. You can look that up. Like I, I'm not up on these, but that is the thing. Yeah. That's so these words are very, very difficult. You know, those product people are at another conference right now and they're hearing about how they should do this and that. And they're using these words like minimally viable product. And every part of that is assaulting your being about what's happening. Like what does viable mean? What does product mean? What does minimally mean? Why are they telling me this? Why are they beating me over the head with this? So there's a lot of language that gets tossed between these folks moving on.

00:07:37

So, uh, one thing I need to convey to you is just like in dev ops, there is a massive spectrum in the product community. So product thinking to some organizations means the product managers do the thinking and in other organizations, it means that there's customer facing teams and then there's other people. And then still other organizations that actually means sustainable viable. The whole company is the product a more of a service ecology discussions, value networks. So the reason I'm bringing this up is the things that you're talking about actually at this conference represent some of the more cutting edge advanced topics that are happening in the product community, just from a different side. And it's really, really important to remember that when you think that there is this other thing that you're not doing, and somehow you need to learn that and adapt your whole career to that because there's a good chance just by being here. You're already, you know, other than bits of language and other things, you're already sort of 50% of the way there. It should be really empowering actually. And I've seen this and I know this to be true. There are terrible product orgs that are doing product thinking that beat people over the head. And there's highly advanced places where you'd feel instantly at home coming from this conference, even if you'd never worked with folks.

00:08:57

So I, in my day job, I talk to lots of teams every day. So this is just to point out that there are, you know, in any given day, I'll talk to these three different models of product teams. The first one is like the shit umbrella. So the shit umbrella takes the ideas, features and tasks and, and is like the auctioneer of capacity for the organization and the shit umbrella takes all those things and then funnels them in the past to them, to the team. Great. Now the next one is a little bit like the PM is idea person, idea, woman. Uh, so they get some goals and objectives in the company and then they dream up the ideas in the features and then they pass it onto the team a little better, you know, a little better. You're getting some it's, there's no shit umbrella.

00:09:39

Um, but it's, you know, it's things. So the third thing is the, where this is moving right where the product manager is a member of the team. They might be conveying goals and context from the rest of the organization, but they are an equal member of the team providing context to help better decisions to happen. They're not making the decisions necessarily. They're creating an environment where the best decisions can happen. The reason why I'm showing this to you is that there is no one product thinking there is no one destination it's just like this community. You could draw almost a similar map for dev ops and being their shit umbrella, dev ops people, and then this full collaboration thing. So keep that in mind. It's a lot closer than you think. The reason why I know that to be sure is I wrote this post called 12 signs.

00:10:26

You're working in the feature factory. Uh, I wrote the post I get, and most of the feedback comes from, uh, developers and designers. They are the ones that feel the most anxiety about working in the feature factory. In fact, product managers, I hear a lot less of. So I'm just indicating there that the impetus for change in the product commuting might actually be coming from developers and designers, um, moving the needle. And it's very, very, very interesting there's I would say there's a growing resentment of product in a way, because product is not moving as fast. They're still in the belly of the beast of the organization. That time flies crap. Um, I will skip some things cause I don't want to hold anyone up for lunch and we should go. Basically, my, my customers, when I was doing consulting were saying, I need to figure out how to product manage the product manager.

00:11:17

Uh they're they are sick of these people. They knew something was better, but they hadn't gone to the conferences they hadn't learned. So they just guessed something was better. So what I want you to do to imagine this as consider a spectrum from a, to I, this is a helpful tool and you can use this in your companies next week. And so a is built exactly this to a predetermined specification. And imagine B is build something that does this C build something that lets a segment of customers do this Diaz solve an open-ended problem is explore the challenges for some set of customers F has increased or decreased a known metric. Um, G is do much more exploratory H is generate a short-term business outcome and I's generate longterm business outcome. The really important thing, when you look at this is that if you can get the fingerprint of your organization and I'm showing you this to show again, product is a huge spectrum.

00:12:07

Even within organizations, this is an organization, UX developers and product, all sort of self assigned some of their efforts to those individual levels. And it created this huge diagram. This is my Franken chart. My Franken chart shows that product, you know, like, yes, there's a hump around F and design is more around D or E. And developers were sort of taking that a little bit more prescriptive stuff. But importantly, if you map organizations like I have over and over and over, you see highly hierarchal organizations where every single one of those layers is owned by a person. And you see other organizations, which I would say product led and more sort of forward thinking organizations in this where there's a much there's, it's very nebulous. The PM is just slightly closer to the GM in that particular setting. So we'll share the deck and you can do this.

00:12:57

But one way to start to understand even what you're collaborating with is to understand how people make decisions and how they're making them in your organization. This whole talk is about collaborations, by the way, we're going to set up the three traps in a bit. So the first trap we, I know you guys have been hearing this for a long time, but I I'm. Here's my theory. My theory is you've heard about working progress. I used some other terms like promises and progress, change in progress, elephants in progress and elephants of the number of elephants in the room that are in progress. And the work actually only represents a tiny percentage of all this stuff. It's crazy much more. You onboard someone and you say, you're going to, you're going to be a good manager for them and take care of them through their career.

00:13:40

You've made a promise. You make a promise to a customer to continue to be a valuable service to them and a partner to them. You have made a promise. All these are promises. There's, there's this thing called promise theory. I'm not going to go that deep in this particular thing, but I know you have the best intentions to keep whip, blow. I'm presenting these other ideas. I know that you have the best intentions, uh, when it's not that way you blame other people or you blame scrum or you blame safe or they made you do it. That's why the high whip is there. But I'm going to propose for a second that you also have a role in this. There are perverse incentives that encourage you to actually keep whip. Hi this, I will just take one round through this cause I can do this all day.

00:14:24

So as whip goes up, throughput goes down. Time to deliver goes up time to realize benefits goes up. Outcomes goes down. Morale goes down a passage. He grows up. Lack of competence. That team is doing its best goes up. Just trust goes up. Outcomes goes down, uh, lose key players. High new players rapidly throughput goes down pressure for short term results, need silver bullets, context switching, which goes up, whip goes up dependencies, go up. You have to hire human load balancers, AK project. Those are coordinators. Then you have to do more upfront planning because you have coordinators. Then you have to do, you know, oh, we reward output over outcomes. You're going to reward business. You're going to reward utilization, upfront planning, local agendas, back to focus. So the whole point here you can go round and round around in the circle. I guarantee that if you were to zoom in on any of these parts locally, you actually have perverse incentives in your particular area that are encouraging this.

00:15:16

The important part is the morale problem or your retention problem is a high whip problem. And you're part of the problem because you're looking locally in one of these settings. Oh, you know, I don't mind people have really low morale. I don't really quite get it. You're going to start blaming them and you have to step back and look at the system. And whip has a sort of multiplicative effect. It's not just your Kanban board, your promises in progress. You're elephants in progress. You're changing progress. All these things are really important. So I like to do these. Here's the actual team. So lunch two hours, uh, diagnosing production issues, status checks, estimating, future work meetings about future work, waiting for CII and loading issues delayed by technical debt. Not working through it, hiring new people, response to going slow value project, a value project, B context switching.

00:16:07

So the team at, you know, a fortune 50 company that 40 hours a week, there's six hours a week that are actually going to creating value. No, but what happens when you see this, right? What's the next step. Everyone know what the next step is. Yes, you get on the train. So you start to get Soylent. You don't even do lunch anymore. Everyone can just, you know, use the Camelback and you, you productivity. You're going to jam stuff into that sprint. You're going to do 10% tech debt work down. The trains are leaving the station. Everything is value. Add, this is great going gangbusters. But what happens after that? Oh, oh no. It's tech debt month or what I call reduced drag month. Shit. Everyone needs to work 60 hours and you, you buy. So I call it personal pizza size teams because everyone has one story themselves.

00:17:00

It's not two pizza teams. It's you go? You buy this vending machine and everyone gets the personal pizza. So they do that. Right. Okay. So then what happens after this? Oh my God, you do that for a month. Uh, we all have some innovation. We all know what, just kind of goes back to what it was before. Just worse. There's only two, there's only a and B the company sort of settles into its vibe. It doesn't really, it's gone through this through hell and back. It's just going to resort back to her. And there's decisions that you make that play a part in this and there's decisions you make in terms of your collaboration with product that impact this. This seems very sort of technical. It's not the sort of human human collaboration side, but it's important because you're making these decisions that impact these relationships.

00:17:39

So Larry has something. He calls the trust formula. You may have seen it already, but I've found it to be incredibly useful. And it says, trust is a function of credibility, reliability, and empathy divided by a parent. Self-interest some explaining this as we looked at the whip diagram, because you could start to see all these examples where either you are losing credibility or your product counterparts were losing credibility. You were starting to assume that there was a parent self-interest there's morale drop trust is dropping. Every time this happens. It's really important. Examples, product manager. They don't want to admit that anything went wrong. Engineers want to product thinks engineering wants to hog the interesting work ScrumMasters aren't developers that doesn't go really that far, um, apparent kingdom building promises. You know, there's a technical roadmap, no one sees it. So you can imagine all these opportunities at this point to lose trust.

00:18:35

So what is the alternative to this? If you lower whip, you can start to work together. You can start your efforts together and you can finish together. You can start together, work together and finish together. And when you can do that, you can build the face-to-face connections in the experience that allow you to build trust and not play Tetris. That's why you lower whip to create trust, to create better relationships with product. And this is why your quarterly roadmap Tetris is also impacting that, which impacts this and this works. So this is a whole cross functional team. Uh, you know, dev ops designers and people were doing a design exercise here. We are at a customer onsite, watching them do their work here. We are all doing a design activity. We're all starting together. Only made possible by lowering whip and thinking more holistically. So some of you were running sort of platform teams where, what does starting together look like?

00:19:26

You will have someone present in that kickoff because something might bubble up. You got to kind of keep an eye on where that thing is going. You have to, it's not just, you know, you know, I understand embedding is like the way to do it. And people say, yeah, but that's the ideal. There is an ideal time. Some 80% of our efforts success sometimes is determined in that kickoff when you're starting to get the shape of the work. So you need to have the person there. I'm going to run out of time. Cause I love this stuff. Um, yes. Keep small promises regularly. That's the whole point. So the trap number two is velocity becomes greater than cadence and moving around becomes greater than the true work. If you're familiar with Taiichi Ohno, he says, there's a difference between moving around and the true work. I also call this the, make the product manager eat the humble pie by having insights that show that they're not quite as smart as they thought they were approach, but that's a, this is a voodoo move. You know, like you're going to work behind the scenes to make this happen, but you're going to, you're going to try to work with them on this. So I want you to ponder for a second. You ship faster than you learn, or do you learn faster than you ship? Who believes that they ship faster than they learn?

00:20:37

Who believes that they learn faster than they ship? Okay. It's a hard question. That's why everyone isn't raising their hands for one or the other. You have to think about theory of constraints and the feedback loop. We're actually trying to balance those things. If one gets out of balance, the system gets out of balance. Now what tends to start is we ship faster than we can learn. In the beginning, we had so much, non-value adding complexity to our products that eventually the problem is that we can't build as fast as we learned. There's learning inventories piled to the ceiling, but we can't actually execute on. But the root cause was at one point, we ship faster than we could learn. It's a very, very interesting model. You could ask this question next week and have a conversation about it. And it'd be interesting. Another way to think about this is, uh, I worked with a team recently.

00:21:22

We know when something's working, when we spend longer on it, huh? Because the feedback loop is so tight that they know that it's working, that they continue working on it. So add that to your flow metrics, right? Like pick the resolution of the work you're thinking about. Maybe it's the rapidity of experiments and actually the mission level work, the, uh, the opportunity level work. You're not worrying. So you think about lead time, but you, you have to accommodate for the fact that when something's working, you actually want to double down on it, which means you keep working on it. That's what you can do when you're learning as fast as you ship and ship as fast as you can learn.

00:22:01

Uh, this is the one that I think I have it wrote. This is my, I was really tired doing this. And I was looking at, you know, the circumference of the circle and trying to time it in keynote to get them to the right things. But essentially the balls are moving at the exact same speed. One company is learning a lot faster, but they are moving at exactly the same speed to any observer locally. When those are going around, you think they were moving at the same speed, but one is actually learning faster. In fact, the one on the right could slow down and still outperform the company on the left and have more sustainable thing. So this goes to product. I'm trying to orient your thinking around this stuff because when it comes to collaborating with product, if you sort of understand these concepts, they may not understand these things yet.

00:22:45

But if you understand them, you can be thinking ahead about how you could help them. How could your platforms help them? How could infer help them? How could you be focusing on the learning loops versus the shipping loops? It's really, really important. Um, no one wants to top one is just chaos. Nothing's valuable all red. The second one's a well-oiled feature factory, some fives and fours, maybe a seven out of 10, like I'm saying scale of one to 10 of valuable. There's some duds. What we want is the rapid feedback loops that start out crappy like 3, 6, 7, 8, you hit a thing. You start the next thing to 6, 10, 9, Netflix and Gibson Biddle talks about 10 years at Netflix. They sort of understood their batting average for strategic efforts, not AB experiments with strategic efforts. And they're batting about 300 at Netflix, which is pretty good at some of this stuff.

00:23:34

So when you think that means three out of 10 of their strategic initiatives actually kind of met the, the, they weren't just mediocre. They really did well, but like, sorry. The one out 10 did really well. And three out of 10 actually did decently. So you have to think about these things. When you think about your feedback loops. So in my work, so this is really funny. Just two weeks ago, I'm talking to someone they've got 10 new recs out in the bay area for 3 million to $5 million a year. Can you identify one customer facing outcome for the last quarter? No. What have you been working on? We have a massive five-year data warehousing effort. I swear it's going to be done soon. Um, it takes three to five weeks to get a report. They're losing people. The PA, oh, well, I don't know. But the passionate people are leaving.

00:24:20

There's a reason why they're leaving because no one knows the work has impact. And just coincidentally for our, I was like, well, how about our product was like three quarters, a million dollars. You're like a fortune big company. It might be a lot. Oh, well that's way too much. So again, back to the incentives that you create within your departments, when someone gets the budget and someone wants to hire on a lot of people, you have to be thinking about these learning loops. Are you making decisions that are allowing you to learn as fast as you should and ship as fast as you learn, because you could hire these engineers and they would be great, but you still have a problem. You, if Netflix is batting 300, you're battling, you're batting 10 or five out of those. I've lost so much time. So I'm gonna, so the critical point is consider the distance.

00:25:04

And I think this community is super well positioned to think about this, the distance from the team and their users, each other, the customers support success, sales, marketing, the budget. How close are you to your budget? The data, the insights, the strategy, the deployment prod, prod like environments, hiring all these things. That is where you get your step changes is to figure out how to you think it's about getting developers to move faster. But increasingly that's not actually the differentiator. The differentiator is to get to shorten these distances within your company. When you can think about that, then you become an advocate for product and design and they start understanding outcomes. Instead of it being often, I meet product managers to say, oh, of course outcomes over output, but we like, we can't measure any of that stuff. You know, we've got, we've got observability.

00:25:54

Like we can tell when something's wrong in the world, we're chaos engineering, but we don't understand whether anyone's using this feature to start with. And so that's kind of a, you know, a dichotomy. So the final thing that I want to get into is to technical backlogs. And this is an anti-pattern that can, if you can solve this, you can really improve your collaboration with product. And this is these sort of separate technical backlogs. It's it's engineering feeling like they don't want to go head to head with product in an apples to apples prioritization. So they run their whole world off of some capacity percentage. Well, we'll just take 30%. We're not even tell you about it. Now the big challenge of this imagine that every company you're at is a value creation system. It is a restaurant. The cutting board is as valuable. You've got meat coming in.

00:26:39

You've got chefs, you've got everyone. Your, you are a service business. Forget about product. You're second. You're there to make people your product is this great experience. The maitre D is the product. The chef is the product. The person who makes your kitchen is the product. You're all the product. You're all the value creation system. Great. So you're making money. January, make $5 million in February, make $10 million in March. You make $15 million, but now imagine all sorts of drag in the system. You're kind of starting. There's all this pressure. There's all this headwinds, your kitchen. You start to get, you know, um, the health inspectors start to show up and your best chef leaves, your cutting boards have salmonella on them. It's disgusting. You know, customers are leaving, you buoy it up with a, you know, a coupon, but the coupon sucks. And so, so that's all sorts of stuff.

00:27:27

That's headwinds coming into your thing. Cause you, you, you could somewhat, yeah. You called like John smart is the Gordon Ramsey of, um, of this. He's not, he's too nice for that. We're in her hands. He's kind of a jerk if I remember correctly. So anyway, so you imagine that this, this slope goes down the value creation system. You're not feeding enough people, you know, it is going down. So the interesting thing here, what I'm trying to leave you with is when people talk about money and how to prioritize infrastructure and tooling, one solution is to just hide your roadmap. It's going to be okay. Don't worry about it. The other way is to find out how the organization is creating value and how your tooling can improve the value creation capabilities of the whole system. Then you've hijacked their value. In some ways you're able to piggyback off of whatever value they're creating the system, which then improves your relationship with product.

00:28:23

Once you get over the hump, because the hump is they don't, you don't want to show too much. You want to keep it opaque turns into micromanagement after a while, if you're too opaque, it turns into micromanager. So I want to finish on a couple of thoughts. That's a one minute 20, this is a four minutes, but I think we're in good shape. I want us to go back to Larry's, uh, trust diagram and the drawing that I did with. So, you know, the obvious in the beginning, sort of, you know, if you have trust, just do it. Thanks. And if you don't, you go through this incredible quagmire process and stuff, and, and think, I want to ask you one question, how many of your processes and systems internally are trust proxies? You've all Harari says that humans create robust stories to transact business.

00:29:08

So what are the stories you tell internally to proxy trust? What's the process you create and the systems you create. And if you look at those things, and if you look at opportunities to improve that trust with your blood product counterparts, the people you're collaborating, or if you're a product manager that can have a very, like, can have a dramatic effect in your company. Um, I someone said, well, how do you prioritize this? I just remember, I, my prioritization is really simple either. There's two only two things you need in your company. The highest opportunity thing. That's experimentation friendly one and two, any big opportunity. That's guaranteed very small, forget about estimation, really like you estimate the highest opportunity. And if it's really valuable, it doesn't matter if you're Netflix and it takes you three out of 10 times to be able to get the value out of it.

00:29:54

It's the most valuable thing. And if something's guaranteed very small, but really valuable while you, when there two guaranteed very small is easier to know about the medium when were small. So there's a form of prioritization here. Um, I want to wrap up in the review. I have to run and get, I have to go home early because of all this mess, but, um, there's three opportunities you have to, and this seems distant from the idea of the human to human collaboration that you have with product, but it all builds trust. And if you can build trust and if you can keep small promises, then you can build trust more and more, more one is really low or work in progress, promises and progress, change in progress. The elephants in progress, elephants are hard. I mean, how do you limit? Cause the elephant's already in the room.

00:30:39

That's the bummer about the elephants in progress? There's like a thing on the bottom of the Kanban board that just has elephants in it. There's no, you know, to elephant doing elephant or thing. They're just there. The second thing is, uh, this, this balance between shipping and learning. I think this community's actually the best position community to attack that problem of feedback loops, which will then unlock these sort of, you know, this, a lot of your companies are chasing this tiny little, 1% gain on some product and some per C-suite person has been talking about the big thing that you could only do if you could just figure out experimentation. And like the innovation lab in North Carolina could send their people somewhere, right? And they're just waiting for that asymmetric outcome to happen, but they aren't seeing it. So really the root of a lot of those outcomes are in feedback loops and being able to learn quickly.

00:31:30

And then that's where you can actually create not just tiny cost savings that you're doing or sort of reductions, but you can explore, you know, cap, CapEx increases and things like that. So it's really, really important. And then finally is this apples to apples prioritization. If you can partner with product and start talking, find what their value streams are, then it becomes infinitely easier to prioritize what you need to do to be able to help their value creation through the system and then call the kettle black. If you're doing one thing, that's worth a million dollars a month. And the other person's thing is not worth anything. You should not have to do both of those things. You should always maximize for value throughput and you should pick the million dollar a month thing if that's what you're doing. So that's my talk. Uh, I can't hang out a lot, but I do office hours as part of amplitude. You don't need to be a customer. We don't really expect people to buy it through these, but you can just reach out and just schedule, you know, an hour and through LinkedIn or Twitter and we can do it. I'll do all the questions there.