There's some really great threads I'm seeing here. We crossed over earlier that you've got competing priorities, but you want to align on a goal. But the process to getting to that one goal, so the process of basically debating, how do you stack rank those priorities to get to that common goal? I wonder if there's anybody on the panel who has a framework or frameworks that they've used to manage that. Having a very strict framework may not be the best way to go about it. I really like to approach these problems on a case-by-case basis and with the special characteristics of what you're trying to solve. I think that the larger framework here is descriptions of what everyone does in siloed jobs, but having these very open communication about what is important about the customer. I think that one key pitfall that we usually fall in, is that we separate the teams according to their organizational job descriptions, so you're an SDE, so you need to go write code, I'm a PM, I talk to the customer. The way that I like to push the team to kind of think on a common perspective of how do we prioritize what's important, what's not, is that we involve each other in each other's work. For example, as the engineers are involved in customer conversations and PM's are involved in technical designs, and it doesn't have to be actively involved, but at least you're there, that makes the engineering team think more about what the customer wants and makes also the PM think a little bit more about what does that mean for the next day of my product if I make this tradeoff, we use the certain type of database versus another. By doing that, I have found that in many cases, you find that, for example, engineers have very strong PM instinct, and even though they don't spend as much time thinking about customer problems, they can make up with their empathy, their intelligence, their foresight. So involving them in these conversations can actually help PMs as well. A lot of times PMs in our areas come from technical backgrounds, so they can have serious opinions on the trade offs and choices we make on the engineering. So when you do that, then you have a common framework of how we prioritize or how do we score, what's important, or what's more important than something else, so everyone is part of that conversation. I love to kind of piggyback on a couple of things I heard from George there and, and one of them was questions. That you ask that they kind of tease out some of these answers. There isn't this one framework, but there are questions maybe that you've used to get the outcomes you looking for, or get the information that you're looking for. Do you have any that you can share with us? Piggybacking off of the items that George mentioned. Getting PMs involved in engineering design reviews or getting engineers involved in PRFAQ or PRD as they're called in other parts of the world, reviews or sign-offs, is a great way to, again, introduce empathy on both sides. Some of the common questions or just maybe mechanisms that we use is for every customer call, not that every engineer needs to be present, but we do provide that option, right? Engineers can join this optional, just sitting in, listening to customer feedback. Typically, during the questions and the PRFAQ, even though it's really focused on customer experience, is, is this a one-way door, right? A lot of that translates into some of the technical designs decisions that are made for products. For example, if we build it this way, does that mean then into introduce, let's say V2 or V3, we need to duplicate this work or we need to, for example, maintain a product or a version that customers no longer find useful? It's a lot of these questions make sure that you are making the right decision, or at least you can back up the decisions that you're making. Yeah, I think that decisions are being made throughout the scope of defining, but then also building and then maintaining the product, right? When you're building something, it's not like you're going to sit down ahead of time, make every decision. At the end of the day, those folks that are actually typing the keys and writing up the code are the folks that are making the decision of what the product does look like. If you ensure that the framework is that those folks are involved in the product decision-making and with the customer, you are ensuring that that vision gets implemented throughout that cycle and it's not just in one or early decision that doesn't carry through. Thanks for that, George and Nancy. I especially want to actually go the Sharmeen because you sit in this role where you touch on both sides at switch. The question I have for you is, how have you seen engineering teams react, like what type of language, what type of approach do engineering teams react well in this process? Then the same question for product teams. I'm making an assumption here that the way you would communicate, the way you would approach it might be different for each discipline. You would think that, but I've actually been super impressed, like they tend to speak a similar language on our teams. I think maybe it's unique to us because we're the community org, so we're super focused on community and our customers and our user base, but I find that everyone has a lot of customer empathy, and when you come from that, it tends to help solve all of your tension that might come up, right? If we're ever having a debate about something, we always ask the question, "What's best for the customer?" We're not arguing over my opinion versus your opinion, it's about what's right for them, and then it completely re-frames the conversation and dissolves the tension between everybody. Having that common language and that focus on the customers is what helps brings us all together. Awesome and thank you Sharmeen. I'm the founder of a Ccmmunity, so you're like my favorite on the panel. Unapologetically, I will just share that. I love the words are using, "belonging" and "thinking about the customer," I love that.
