 Hi, and welcome to B2B enterprise product leadership. My name is Kirsten Vandetta, and I'm a senior product manager at LinkedIn. I have worked in B2B for the last 11 to 12 years as a project manager, business analyst, and for the last seven as a product manager. I'm excited to talk to you today about these different B2B topics. There's a lot of information here. So it might seem like I'm going a little fast and a little high level, but that's just because all five of these could be their own webinar. So a little lofty. So let's get started with the first one. We're going to talk about the four key differences of B2B versus B2C. Product focus. That's the first key difference. Who are you solving for? A B2C product is consumer. B2B is the business, and a B2B to C is a business plus their consumer, so their customer. So a customer's customer. You can have lots of variations of B2B to C, B2B to B. It just depends on what type of customer your customer's customer is. The second part is our buyers and users. In B2C, your buyer and your user are generally the same. I bought a pack of gum. I ate the gum. I'm a consumer. In B2B, you usually have approved buyers. Those that have the approval to get the funding, their influencers, their decision makers, they're signing the contracts to buy products for other users. So for other people at the company, so they'll buy for their employees. In the B2B to C space, right, they're still buying for the business. But they're also buying a product that you're supplying that has a UI or an interface for their customers. So whether their customers are consumers or businesses, it's still the business buying your customer is still buying. So there's a difference there. When we get into the sales cycle link. So this is our third key difference. The sales cycle link is important to you as a product manager and a product leader for two reasons. One, because it's longer than a consumer, a consumer sales cycle, I walk into a grocery store and I pick up a package of cookies that maybe took me minutes, buying a house might take me months. But I can normally make those decisions by myself. In B2B, there's a lot more that can go into deciding what product to use depending on how complex the processes that a business is trying to solve. Or the complex solution that they need, whether or not it includes an interface for their customer. And so the average time for that is about three to four months. And it can include activities like request for proposals, where they put exactly what they want in a product. And so you get to learn during the sales cycle if you are the friend of sales, you will learn what people are looking for. I'll also highly recommend you sit in on a sales pitch now and then just to hear what other people say the value of your product is. And then also you can hear what people are asking for which can help inform your product right now. The last thing that's important for our differences in B2B is churn. Now obviously there could be other things but I picked these four for a reason. One, we need to know who we're solving for. Two, we need to know that actually it's more than just our users. When we solve for a business we solve for buyers and we solve for our users. Three, our sales cycle helps us learn what people need before they actually sign a deal. And lastly churn, which is when people leave us and stop using our product is is helpful for us to understand in some cases if our customer tells us before they leave. If they tell us before they leave why they're leaving, we have an opportunity to make good on that. We can't fix everything but if there's a key thing in there and we start to learn that a lot of people are leaving for the same reason. A lot of times our contract cycles are long enough that we might have enough time to actually make good on that. So that's why those four I picked those four is important. And just as a quick recap for this section, as we go through the other sections I just want you to keep in mind there are a lot of different categories of B2B products. B2B is not really a category it's sort of an overarching umbrella. So to give you the examples in these next sections, keep in mind, there are highly complex products like supply chain management systems. There are products that enable collaboration, like Slack or teams, and you can have all the way to other complex products like reporting tools. So keep those in mind as we move through these. So let's go to our next one. Now this is a B2B product leadership. So we need to talk a little bit about the difference between product management and product leadership. All product people are leaders so let's be very clear about that when we talk about leadership and the rest of this session whether or not you leave with authority or without authority. So you're thinking at this high 50,000 foot view, as you're evaluating product requests, where to take your product aligning with a vision and all sorts of things. But whether you have authority or not that's important for everybody to do. So when we're talking about it here, if you are here as a product leader in leadership, meaning you have authority to make decisions and you have a responsibility to your team. To who you report to, all of this applies to you as well. Just take, as we go through this, just think about how you would apply this and help your teams think this way. And if you're here as a product manager and aspiring product manager, you're going to learn how to think like a leader. And when we think like a leader what we really mean is in product management we do read but a lot of it is really about implementing so in the book product leadership, it talks about doing things right versus doing the right thing so when we're wearing our product management hat, trying to make sure that we're aligning cross functionally we're pushing things through the right way, and we're working in a with our leadership to make sure that we're getting things out the right way. When we put on our product leadership hat. Now we're thinking about doing the right things, we're making sure we're prioritizing in the right way and doing that requires that we come way way way up in the way that we think about things, and how we approach our work. And so that's what we mean with product leadership here, but it can apply to you whether you have authority, or you don't. So let's take in to evaluating future requests in the B2B space. So there are three things that it's important to think about when you put on your product leader hat when you're evaluating future requests. So we know as product managers we think of valuable usable and feasible, but this takes you a step further and really thinking about the full ecosystem as you go in to evaluating product requests. So let's start with where they come from, and the types of requests you get. So the first thing is is you're going to get requests from literally everywhere, everywhere, everyone has something, whether there is a technical security issue that you have to fix from your engineering or IT teams, whether legal needs you to make sure that you're, you're compliant on something. You might have senior leaders who have new initiatives, users who need workflows fixed stakeholders who have new impactful things in their system that help them align with maybe their corporate social responsibility goals, or what they need to accomplish as a business, they come from everywhere. And when you're looking at these it's really easy to think in a knee jerk reaction that if it's from a senior leader, it's a priority over everything else. So the one thing I would say to you is you're looking at where your requests come from. And if you're wondering, yes, it did make sales a cash register. It just felt right. If you're wondering how do I prioritize all these sources and types we're going to get into that how we evaluate the impact, but you don't have to assume that if it comes from a senior leader. It is a top priority. You do have to assume that if it comes from a senior leader, finding out what the trade offs are and communicating those appropriately is a priority. So if your senior leader asks for a new initiative, a net new feature or a net new product that's going to take a lot of your resource in your roadmap, and you have something equally important. Say we go back in the time machine to 2018 when GDPR became a thing. You need to say, I've looked at this. Here's my recommendation. Here's the data I have. I think it would be wise if we deferred your ask to make sure we get GDPR compliance in. And then we can revisit this and I anticipate we can get you a full scope and yeah, whatever that might be in a new timeline. At the end of the day it's their decision that trade off is their decision and not yours but you have the data you own the problem said, and you can have the what and why explain to them so they can make an adequate trade off. That's really important. So that's my tip there. Also just one more side tip. If we have any engineering friends on this session. I highly recommend you avoid endless tech debt, avoid endlessly deferring it. It's important to prioritize that sometimes and I'm telling you if you do not. You're going to tie your hands when you try to scale, because eventually it's going to be such a wide knot with all of the sort short term solutions in there that it's become that it will become a problem. So that's really important. And the next thing you have to do as a product leader is ensure you're actually defining the problem. And that also as a product manager. I'm not going to ask, but let me be very clear that in B2B it's very easy to get solution requests. Someone is using your product for their job. They do it on a day to day basis. If something is a problem, they see what the problem is, they have a solution in mind and they're going to ask you for it. There is nothing wrong with people wanting to solve their own problems. There is something wrong with taking that request to engineering and say, how can we do this and how long will it be. What you have as a product leader is to understand that problem better than anyone. You own the what and the why. You don't own the how, and you certainly could pitch the win. But you really need to know who you're solving for, what you're solving and why you're solving it. So if somebody says, hey, you know what, I'm in form A all the time I have to get to form M. It's really annoying. It's so many clicks. Can you put a link on form A? Well, if you take that to engineering, they're going to ask you all the questions on the screen anyway. So it's really important that you get down to what the actual problem is. And maybe what it turns out is the actual problem is the reason they have to get to form M is to fill out data. So if you fill that up for A, in form A, and you could just auto populate that for them, no link needed. So really understanding the problem, and when they have a large problem or an end-to-end problem, or a problem that requires an end-to-end solution, make sure when you're defining that problem that you're looking at the must-haves. And we'll talk more about that in a minute, but not every problem is a top problem worth solving. The next thing you need to do from your 50,000-foot view is think about your customers' businesses. In B2B, if you're solving a business problem, then you are impacting businesses. You could impact their competitive advantage, their process. You could impact all sorts of things for those businesses. So they should be top of mind as a product leader when you're thinking through what you should be solving. So we're not even to solutions yet. We're not to solution impact. We're to problem-solving impact. How would solving this problem affect my customers' businesses? How many of them are going to be affected or percentage? Is it a specific market? How many of them have this problem? And so an example of that might be a user's ask for a data export option. It's not in their system now, so that's why they're asking for it in case you're wondering. And they want to use that to export contact data and import that into a marketing system. Well, that might violate GDPR regulations that your stakeholder businesses are trying to comply with. And so you really have to understand their business, their industry. You have to be up with their trends. You have to understand how these businesses operate and what's really going to affect them. And so that's where being a product leader and not just a product manager is important. 50,000-foot view. The next one is evaluating business impact, and that means your business. So when you're looking at your business, how does this impact? And you might be thinking, well, some of these requests are so small, why would I go through this entire exercise? The fact of the matter is the smallest request can have the biggest impact. So when you think about a business impact, you think, does it align with who we are as a business? Is it aligned with our mission and our values? Does it create value for us, whether that's monetary or impact to your corporate social responsibility initiatives or good faith value to customers? It still should create some sort of value. If not, why do it? You also want to look at the impact to your internal stakeholders and partners. If you're going to do something that grinds operations to a halt, that's a huge business impact. It's costly. It can be a problem, especially if it's not fixed in the long term. And then lastly, you want to make sure you're not cannibalizing your own products, right? So let's take an example. A user asked to have an opt-out checkbox put on your contact record in your CRM system. They want to do this because they want to manage opt-outs in CRM and in their marketing tool. The users act or sorry, their customers or the people receiving newsletters actually use an interface with this marketing tool and not your CRM. The marketing tool, another product team owns. If you add that email checkbox, you have now violated GDPR compliance because you're not tracking when somebody opted in and opted out. So you've affected your stakeholder, you've affected your business because that's a problem and stakeholders will have a problem with it. And you've affected the product where people might think that email checkbox lets them get out of buying that marketing tool. So things to think about when you're evaluating product features is your business impact. The third part of this is impact to your product and ecosystem. Now, we kind of touched on that already in the last slide, but it's really important to align with your product's purpose. And if you don't know what that is, it's a good idea to really think about it. In the whole ecosystem of the products that your customers use, where does your product fall in its purpose? And if it's trying to do everything, that's a whole different webinar, but I'd abdicate against trying to do everything. But if it doesn't align with your product goals and your product's purpose, if you really feel strongly about it, you should surface it to other leadership to see if the business wants to go that direction with your product. But otherwise, it really doesn't fit. And so if it doesn't fit, it's impacting other products, it's not a good business fit, and or it's negatively impacting stakeholders, you won't want to do it. Now obviously, in the opposite of those, all of that is fabulous, and the answer would be yes. Now you might be asking yourself, how about users? Well, I have users last and the reason being is when you're thinking as a product leader, you have to go through those first three first. You have to. If you think you go through the whole process to see if something is feasible, valuable, and usable for users, but it breaks down when you get to their businesses as a whole, then you wasted your time. Now, obviously that looks like a lot. I just blazed through that really fast, but when you become a subject matter expert on your customers businesses, your customers industry, your industry being tech. And how your users operate, what their work streams are, it's really easy and really fast to get through those previous three slides and all of those questions. Now when we get to users, it's important, again, to think about percent impacted. I'm going to give you one tip on this. We often go, well, there are only one customer asked. Well, usually there are more customers that haven't asked that have that problem. So it's important not to push back and say, I've never heard that before. It's the first time I've heard that none of my other customers have this problem. You don't actually know. You only know what you've memorized from your backlog or your most recent conversations. So I highly recommend that you take the feedback first and you dig. When you come back, you say, wow, either I found that we actually already have a way for you to do this. And then you put basic training and support on them. If they are actually being innovative, consider it and look at it and start to do focus groups with other customers to see if it's useful. I mean, obviously not with everything, but be really careful about sort of customer shaming, making them feel like they're the only ones that do a thing in a specific way. Because the fact of the matter is they're probably not. You probably just haven't heard from the other ones and it could be useful if it fits within the scope and purpose of your product. It fits with your business impact and your stakeholder impact. The other thing you want to make sure you ask without fail is what are you doing now to solve this problem. Are they using another tool, that's going to help you a lot if they're using another tool you don't currently own in your product portfolio or even at your business. That's a great way to say how many customers are using this maybe it's an integration. If they're doing a weird work around in the system that's causing really bad data that can escalate priority. So you really have to look at the full ecosystem across the board but when you dig into user impact there are obviously far more questions than what I have on this slide. When you dig into user impact it's really important to understand. Do you know how many, what's that number that you actually have. The next solution we're solving doesn't really belong in your product. And if they're doing something now, is it causing issues in your product do you need them to essentially stop their temporary work around. Or are they using another product that might lend itself to the next logical integration your tool might have. And lastly when you're talking about user impact with these problems, again we're still talking about problems and not solutions. So really make sure you know which problems are the highest priority to solve. They all can't be all the things all the time. So, let's go on to the next, our example. So our example is an internet survey tool request, and this is for a business that builds Internet, and the purpose and vision of this company is to allow employees and businesses to collaborate and interact freely across all levels of an organization access resources see company updates. So, an internet. The request is to add surveys, they want to be able to gauge employee sentiment and they want to do it directly from this interim internet. When an employee logs in they get prompted to fill out a survey, they fill it out within the Internet, and the response is logged, anonymously. Now if we walk through our impact evaluation, like we just did. Let's start with our external stakeholders. Hey external stakeholders. We're going to build a survey tool. How much is it and or is it included right that they probably won't have a significant impact. If they're using a survey tool you might have some switching costs, you know what's going to be in this new one but other than that. They're fine. Let's pretend they're fine. You go into business impact. We don't have a survey tool at our business today. This would be adding it or a third party integration so our build by partner conversation which we're not going to go in a deep dive. We're going to build it in house it's going to affect our internal stakeholders. We're going to need a team to understand survey science because that is one. We're going to need people to support it, people to build it, people to sell it. And we're going to essentially be extending our product line out into a new space that we didn't own before. We have to consider what that looks like is a large initiative so that's our business impact so more discovery needed there because it's a lot. And product impact. We're extending our product into essentially a whole new product line is that our team that's going to do that is it another product team that should own that. Where is that going to come from do we have the resources for it, etc, etc, right. Then we get to user impact user impact. Are they going to use it well they already log in right, but wait, they already log in. We're not going to believe that that survey is anonymous most likely. So what does that mean for user adoption, not just building the survey but actually getting employees to fill them out, honestly, right. So those are the things that you would, if you had started at the, at the user or employee and work backwards either way, if you don't have all of those sort of aligned you either have more discovery to do or you have your answer. So let's move into keeping an agile mindset. Keeping an agile mindset and B2B was sort of elusive for me when I first started B2B can be really complicated it just depends on what your solution is. But when you're in an agile place of mind, you're thinking in incremental value. And so I want to talk about what that looks like, not just when you're solutioning, but when you're doing releases, and when you're partnering with training and support. So first you've probably seen this, let's just talk through it in case anybody hasn't. This is what agile and MVP right this is what agile supposed to look like your customer comes and says, I need to move from point A to point B faster. They might even say I need a car they might already know the solution. If they decide if you decide yeah you're right you need a car. And we'll give that to you within the timeframe and resources we have. They end up with this top line. You give them a wheel. Can they do anything with that. No value. What about a wheel and a chassis. No value. Right, I get to a car with no steering wheel, no value you get the point. This is iterative development, instead of incremental value. And so this is kind of how you would break down a really large project, maybe in waterfall, there's nothing wrong with waterfall waterfall has its place, but it's not agile. When you get down to the bottom row. That is where somebody says I want to get from point A to point B faster. And you say, Well, how far is it. How far is it taking you now, dig into the problem statement figure out the real problem and say, we can start with a skateboard. That would help you go this much faster. Would you find value in that. Hopefully they say yes, sometimes I'm like no the car but anyways. And in B2B I just want to be very clear when you're talking about agile, you might look at this and go. Mike, you're talking skateboard like I can't get my users to buy into that. And so sometimes it looks like you're always starting with the bike. That's okay. Sometimes you really your most agile smallest incremental value is still a large project, because it has to include compliance and API is an integration. And the only value you're delivering at that point is one field is thinking was a lot of work, but you still started with the smallest increment still provided value and that's the most important part. So let's dig into solution design with agile mindset. So first of all, when people come to you it's usually about a business process. Unless it's an external stakeholder than it could be about something far wider, you know, security privacy reporting things like that. Do they have a temporary work around for users. What are they using now are they using existing tools and features if not can you devise a way that they can do that in a more manual way until you can figure out what the lowest incremental value is that you can give them. Thank you very very much. If you have a problem we're solving, and you give a user a temporary work around. Don't go off and not revisit this problem to solve. Eventually this just becomes best practices this temporary work around and you realize that people are pretty frustrated with your product in some cases. So make sure you revisit if you can right camera visit everything. The next thing is a short term solution. The short term solution I consider personally that there was actually development. I made a decision to go after a short term solution where we developed something much smaller. I see a short term solution is more of a band aid. We were unable to commit to resources for long term. Be careful with short term solutions normally it's a compromise where users still aren't happy. You've spent development resources on it to sort of hack your way to yes, because you didn't want to say no to the full thing and or maybe you couldn't because it was that critical and you had to put a band aid in with the resources you have. But I caution you on short term solutions when you know there is a better long term solution that can wait. If you can defer wasting development resources on a short term solution to build what you really need to take you into the future and support you in the long run you can scale do that instead have those hard conversations as a product leader to say I hear you, but I think you could continue the temporary work around until we can slate this for two quarters from now. Make sure people don't confuse long term solution with everything I asked for, or everything they asked for long term solution isn't, I can't get you everything you asked for now so I'm going to do this partial. Now we're sort of confusing MVP incremental value and sort of hacking our way to yes right we don't want to do that. If we know for security and stability engineering needs to do x, in order for long term solution. Don't get to that yet. Don't do a short term solution just defer and move it out. Not everything has to be immediate. The last sort of differentiation I'm trying to make for you here is that MVP is a term use a lot and there's a lot of misinterpretation and confusion around it. So MVP and agile are both experimentation tools and mindsets. You're starting with the lowest incremental value that you can and building from there, but that lowest incremental value isn't a long list of all the things they want and you're just doing the top three because that's what you can get to because again that short term solution. Right. And then we conflate that or confuse that with. The rest of what I asked for. So when you're in solution design think to yourself. Again, like the last slide incremental value what is the lowest incremental value I can provide it isn't. What is my smallest amount of work I can do necessarily sometimes it is and that's great when it's that way, but it's not always that way. You're committing to the car at that point. You're committing to helping them go faster between point A and point B, and you're going to learn from how that works for them before you move in to building more of a solution for them. The other thing that I just want to note real quick is be really careful about using terms like MVP with your users and your stakeholders. Essentially what it starts to mean to them and what they translate it as is what they can get to in the time and resource they have a lot of now before they can get to the rest of my ask. Or they can fuse it with sort of like just something that's not super valuable but you guys are trying to give me something they confuse it was a short term solution. So be careful about, excuse me how you use MVP. It's much better to get into the habit when you're talking to users and stakeholders of using words like problem, most important problem and steering clear of MVP. How can I provide value to you to start is a better conversation than well this is all we can do for MVP. That would be my recommendation. Okay, so next is release cadence. How do we stay agile and release cadences for one let's just be clear cadence, the cadence of your releases is up to engineering not you. So, but you can influence it with an agile mindset but but agile mindset and release cadence for me to be is very different. Right, you can release an entirely new UI to Facebook users, and they'll be grumpy for a day but they'll figure it out. If you release an entire new workflow process. For, let's say reporting at the end of the month when everyone's reporting in some tax software. And you didn't tell anyone first, then you've disrupted their workflow, you, you want to avoid disruption as much as possible. So these are the four areas that I look at to help me avoid disruption of my customers businesses when we do releases. So whether you release, excuse me every day. So twice a week, monthly, whatever that might be that works best for your engineering team whatever framework they use doesn't have any really any bearing. But what does have a bearing is your type of release. It's a bigger small, the major or minor. Did you implement a net new feature that changes the way somebody could do something. If they go into their workflow in the morning will it be changed. I consider that major, if they won't know what to do with it intuitively. Whether it might be bug fixes or you added something that's pretty clear or you, you added, you know, a walkthrough that people can learn about right in there, because it's pretty minor. But those you can do those, your release kids can be a lot more for those right they see this incremental value coming in all the time bug fixes are coming in. So those can be really important. The other thing is if it's a major release, like it goes across multiple sprints or it's high impact. You need to consider that requires training or documentation, because you're going to have to partner with the teams that do that, or if you do that yourself because you're the startup. You need to give yourself time to do that before it's released and causes a disruption. The next thing is work streams and personas. And the reason you want to understand these about the release is if it is a major release and it there is going to be disruption, you need to know who it's going to disrupt which personas which work streams so you can communicate to them beforehand what's coming. You might even if it's large enough give people training before it starts through your your development server or excuse me instance. If they do need to be informed prior to you might be working with your marketing team or whoever's responsible for those updates. So keep those in mind. The other thing is you can really kind of. You can really decide when these major updates to go out so maybe you only do major updates updates quarterly, and you do minors monthly and you do bug fixes weekly like whatever that looks like for value for your product. So consider the seasonality. You don't want to do a major update for a higher ed online school solution that helps them take tests better right before testing starts because you really don't want to deploy that out and find out all the bugs are the in the middle of people taking exams for midterms or finals. The seasonality and key dates are a big deal. The last one is frequency. We get in this agile mindset and we say release early and often release early and often we don't want code to set we don't want to sit and wait for all this comprehensive documentation, but I will say the law of diminishing returns applies. Eventually your customers are either going to mute you and not care the release notes what like they won't care until something changed drastically and then they'll go check them. Or it might be too much if you're doing major updates every month it might look like you're doing like a lot of great stuff. But if you are not in a cadence of also informing and training and having everything ready for them. It can just be too much. So take those into consideration for your release cases. And then how you partner cross functionally and to make sure that these go out smoothly. That is more of a product management, but when you come out as a product leader and look across all the work streams that are required to launch something successfully. It really is your leader hat because you're trying to get everybody aligned. So how are we agile and training and support well agile manifesto says working software over comprehensive documentation so everybody to say everybody a lot of people interpret that as no documentation. We're agile no documentation. It's lies. It's not true. The only way to be is you can't sell and support a product. If you don't have anything that tells people how to use it, or all of the value that it might be, or how to support it. So it's not no documentation it's concise over comprehensive documentation. So think about a release. If we go into a release, your technical documentation that's on engineering so I'm actually not going to talk about that there's tools for that and stuff like that right over here. But for user training content internal support content your release notes. If you're sending out a bunch of bug fixes concise is released multiple bug fixes. Right, unless there was a bug everybody knew about and they were losing data or something like that there's no reason to go through all the bugs, you released bug fixes people are pretty used to that, even for their consumer technology. If you really something that is changing the way they have to report maybe you deprecated fields and you added new ones. That's a big deal. Do that at, you know, mid month, and then make sure there's documentation that shows them how to fix all of their reports. But again if you can fix them for them but usually that's. And then your release notes do not have to contain everything. Like I said, if it's bug fixes minor updates, a one line is fine. You can now fill out fields called blah blah blah on the lead form to track yada yada yada you know it doesn't impact and it's something that's, you know, an optional offering it's fine. But if they're forced now to do something different when they log in, make sure you have the right content ready. And that content again, let's say the update is, you've changed the way you create an event, a whole form changed. Well, when I go into creative event my release notes should say event form has changed impact statement value statement right because hey we change stuff on you is not good right. And then when they click into that they can see a very concise here are your new steps and training and support can save time and their roadmap later for doing the more comprehensive stuff. When they have interactive user guides or things like that that doesn't have to be when you release they should also be thinking in incremental value. What is the smallest thing I can put out that is valuable to our users that I can iterate on and add more value to as we go. It's really hard for training and support teams in an agile environment until they really get their cadence as well, because they're supporting this living breathing software that changes all the time so it's like chasing a moving target. The best thing you can do is be besties with them early on with each of your updates. Make sure they know what's going on explain it to them walk them through help them with their first phase of their outline until they really get into the cadence. And one of the best things you can do is really have one point of contact for your product, or at least for work streams on the training support side because then you guys really get into the group together. The last thing I'll say is if you're a training and support person or if you're a product leader that can influence your training and support folks when you're doing release notes or user training guides or anything like that. Make it easy for the people who carry your message to other users to carry that message. So don't put it in a place where they can't copy paste, you know, it, or if you do at least link out to where they can grab some information. There's a lot of admin users and product champions that do like weekly meetings where they talk through all the new features and how they want people to start using them. Because ultimately, if you push out optional features, it's on those businesses to decide if they want to work that into their process. So that's the really important thing about training and support. And so here's the last thing I want to cover. Thank you so much for staying with me. I know we're going over the 30 minute mark. There was just so much to cover. The last one is just going to be very high level. I am not going to tell you what metrics to use in your B2B product. You cannot copy and lift from other B2B products metrics. You can however be influenced like there are some, you know, if you have a SaaS product, you're looking at things like monthly recurring revenue and, and, you know, maybe monthly active users. Those are pretty, pretty standard things. We're not here to define metrics. So I wanted to find the four things you have to think about when either you're creating what metrics you want or you're interpreting the data coming back in your metrics as you use those towards your KPIs or your KPIs or whatever, whatever your, your company is using. And so these four things, one, your customer's industry can matter. It doesn't always, your product might actually support all sorts of industries. If you're a messaging application like Slack or Teams, the industry might not matter as much as if you run a CRM system that's specific to a niche industry. The second thing that's really important is your product. What type of product do you have? You know, do you have a product that businesses have to use every day? Do they not have to use every day? Is it really, really seasonal? What type of product do you have? You want to think about personas and work streams, and that's mostly for your behavioral metrics. You know, if you're trying to see if users can actually complete tasks with the features you've implemented, if you need to enhance a feature, if you need to sunset something nobody is using. That's where personas and work streams can kind of come into place. But it also could be an important part of how you interpret things like daily or monthly active users, especially if those personas and work streams align with seasonality and key date swings. Your seasonality and key dates also depend on your customers' industry generally. So if I say higher ed, again, seasonality and key dates, I might see a huge uptick in my education software during finals week and midterms. I might see a huge drop. That doesn't mean my product's not cool. It means people don't need all your products. No, I'm just kidding. It doesn't mean that your product is not being used. It just means that they're using it more when everyone is forced to be in there versus a self-paced class, let's say. So when we look at that, let's take an example and walk through this really quick. So the first thing is, let's pretend we're looking at the metric for product usage, so we'll use monthly active users. Our industry, we really operate mostly in meetings and conventions because we sell an events management system. That's really complex. It helps do really large events, which require things like not just creating the event in your system. So it could be invites and attendance building. It could be invoicing and refunds and payments. It could be services and scheduling volunteers. It could have post-event follow-up and surveys and invites for other events. And the seasonality and key dates for the meetings and conventions industry, again, I'm just making all this stuff up, but let's say based on the data that we have, most of our customers tend to create their events in the spring that take place in the fall. It's about a six-month cycle from create to post-event. And so we see really light usage, say, from December to February. So when you're interpreting a monthly active user and you're comparing it between December and October when all the events are happening, or September when all the events are happening. And you're even looking at the attendance building. You know, maybe through June and July, you're seeing a lot of marketing persona, a lot of invite and attendance building, work-stream work, not as much for the payment and refunds that might really, really pummel towards when an event is about to happen or afterwards as somebody didn't show. And so you can see an ebb and flow in monthly active users. And if you just looked at December to leadership, our monthly active users are down significantly. That's incorrect. That's an incorrect story about the metric that you're looking at. So in B2B, you really have to think about the industry you're serving, the product that they're using, the work-streams and the personas and how that ebb and flow works in the business process, and their seasonality and key dates. And that's really going to help you tell a better story with the data you're getting out of the metrics you do choose to use. So with that being said, that's the last part. I know it was a lot. I appreciate you hanging in there. In summary, there's a lot here. I know there's a lot here and the reason is because product leaders do a lot. So whether you're a product manager trying to, you know, climb a little bit higher in the way that you think about things into the 50,000 foot view or you're a product leader with authority trying to help your team get there with you. Being a product leader in B2B means all of these things. You know your company's vision. You're aligning what you're doing in your product with that because you're trying to get your business somewhere, not just your product somewhere, right? You understand a vision for your product. If you don't create one, start to really understand your product's purpose and how it sits in your customer's business ecosystem. Understand your own product ecosystem where your lane is versus another product team's lane. You need to have a deep knowledge of your customer's industry, their business processes, their trends. You need to keep up on all the things about them to really truly excel as a product leader in the B2B space. And when you're evaluating things, think cross-functionally and across all the impacts that you can, that you would have internally, externally, and again on the business. And the last thing I would say is you really want to make sure that you task yourself, your team, your cross-functional partners, your users, your external stakeholders, everybody you're working with to think in terms of problems and incremental value. Not iterative development. It's really hard sometimes. It's a very thin line sometimes. But you will get more value out in the long run. If you focus on that incremental value, you keep that agile mindset and you stay way, way, way up here and really make sure that we're leading in product. Thank you so much for joining me. I really appreciate your time. Thank you.